What is the Given/When/Then format for acceptance criteria?

Given/When/Then (also called Gherkin format) structures acceptance criteria as: Given [the specific precondition or context], When [the specific action or event], Then [the specific, observable outcome]. The outcome must be verifiable by a QA engineer without asking the PM for clarification. 'The user is happy' is not observable. 'The user sees a success message within 2 seconds' is observable.

How many acceptance criteria does a user story need?

Three to five acceptance criteria per user story. Fewer than 3 means the story is underspecified and QA will have to invent test cases, which leads to inconsistent coverage. More than 7 usually means the story is too large and should be split. Each criterion must be independently testable — if passing one criterion automatically proves another, consolidate them.

What is the difference between acceptance criteria and test cases?

Acceptance criteria are written by the PM and define what 'done' looks like for a feature from a product perspective. Test cases are written by QA and define the specific test inputs, steps, and expected results to verify the acceptance criteria. One acceptance criterion typically maps to multiple test cases. ACs are written before development; test cases are written during or after development.

Can AI generate acceptance criteria?

Yes. Scriptonia generates acceptance criteria as part of every PRD — each user story gets 3–5 Given/When/Then criteria automatically. The generated criteria cover the happy path and the most common edge cases. The PM review pass (15–20 minutes) verifies that the criteria reflect actual product decisions and adds any domain-specific cases the AI missed. AI-generated ACs cover 80% of what manual writing produces at 1% of the time.

What makes acceptance criteria bad?

The most common failures: criteria that can't be verified without PM clarification ('the feature works as expected'), criteria that describe implementation rather than behavior ('the database stores the value'), criteria that are too vague to test ('the page loads quickly'), and missing criteria for error states (what happens when the network fails, when input is invalid, when permissions are missing). The test: hand the criteria to a QA engineer who knows nothing about the feature. If they ask questions, the criteria are incomplete.

Acceptance Criteria Template: 25 Patterns From Production

Acceptance criteria follow a single format: "Given [context], when [action], then [observable outcome]." This template provides 25 real acceptance criteria patterns across five feature categories. Each pattern is written so a QA engineer can test it without asking the PM for clarification — the only standard that matters for acceptance criteria.

29%

of PRDs contain acceptance criteria that QA cannot verify without PM clarification

2.1×

higher bug escape rate for features with non-specific acceptance criteria

The acceptance criteria format

Given [the specific context or precondition],

When [the specific action or event],

Then [the specific, observable outcome].

The word "observable" is the critical constraint. The outcome must be something a QA engineer can verify without asking anyone. "The user is happy" is not observable. "The user sees a success toast notification with the text 'PRD saved' within 2 seconds" is observable.

25 acceptance criteria patterns

Authentication (5 patterns)

1. Given a user enters a valid email and password, when they click Login, then they are redirected to their dashboard within 3 seconds and their name appears in the top navigation.

2. Given a user enters an invalid password, when they click Login, then they see the error message "Incorrect email or password" and the password field is cleared. The email field retains its value.

3. Given a user enters an invalid password 5 consecutive times, when they attempt the 5th login, then their account is locked for 15 minutes and they receive an email notification of the lockout.

4. Given a logged-in user clicks Log Out, when the logout action completes, then their session token is invalidated server-side and they are redirected to the login page. The back button does not restore the authenticated session.

5. Given a user's session token expires, when they attempt any authenticated action, then they are redirected to the login page with the message "Your session has expired. Please log in again." Their current URL is preserved so they are returned to it after login.

Forms and data entry (5 patterns)

6. Given a required field is left empty, when a user submits the form, then the form does not submit, the empty field is highlighted with a red border, and an inline error message "This field is required" appears below it.

7. Given a user enters an email address without an @ symbol, when they move focus to the next field, then an inline error message "Please enter a valid email address" appears below the email field immediately.

8. Given a text input has a 280-character limit, when a user types and reaches 260 characters, then a character counter "20 characters remaining" appears below the field. At 0 characters, the counter shows "0 characters remaining" and further input is prevented.

9. Given a user is filling out a multi-step form and navigates to a previous step, when they return to the current step, then all previously entered data is retained.

10. Given a user submits a form and the API returns a server error, when the error response is received, then the form does not clear and the user sees a notification "Something went wrong. Your data has been saved — please try again."

Search and filtering (5 patterns)

11. Given a user types a search query, when they have typed 3 or more characters, then search results appear within 400ms without the user pressing Enter or clicking a Search button.

12. Given a search returns no results, when the empty state is displayed, then the user sees the message "No results for '[query]'" and 3 suggested alternative queries or browse categories.

13. Given a user applies a filter, when the filter is active, then the results list updates without a full page reload and the active filter is visually indicated (e.g., a filled filter icon and a count badge).

14. Given a user clears all filters, when they click "Clear all," then all filters are removed, the results list resets to the unfiltered state, and the URL no longer contains filter parameters.

15. Given a user applies multiple filters simultaneously, when the results list updates, then the list shows only items that match ALL active filters (AND logic, not OR logic).

Payment and checkout (5 patterns)

16. Given a user completes checkout with a valid credit card, when the payment is processed, then they are redirected to an order confirmation page showing order number, items ordered, delivery estimate, and a confirmation email is sent within 60 seconds.

17. Given a user's card is soft-declined, when the decline response is received, then the checkout page shows "Your card was declined. Please check your card details or try a different payment method." The order is not created.

18. Given an item in a user's cart goes out of stock between cart and checkout, when the user attempts to complete checkout, then they see an inline error identifying the out-of-stock item with options to remove it or save it to their wishlist.

19. Given a user applies a discount code, when they click Apply, then the discount is calculated and shown as a line item in the order summary. If the code is invalid, they see "This code is not valid or has expired" without clearing the code field.

20. Given a user abandons checkout on the payment step, when they return to the checkout within 24 hours, then their cart contents and shipping address are preserved.

Notifications and email (5 patterns)

21. Given a user's action triggers a notification, when the notification is created, then it appears in the in-app notification center within 5 seconds and the notification badge count increments by 1.

22. Given a user clicks a notification, when the notification is opened, then it is marked as read (badge count decrements) and the user is navigated to the relevant resource.

23. Given a user has unread notifications, when they mark all as read, then all notifications are marked read, the badge count becomes 0, and the change persists after page refresh.

24. Given a transactional email is triggered, when the user's email client receives it, then the email renders correctly in: Gmail (desktop and mobile), Apple Mail (iOS), and Outlook 2021. No images are broken. No links return 404.

25. Given a user unsubscribes from marketing emails, when they click the unsubscribe link, then they are removed from the marketing list within 10 business days (CAN-SPAM requirement) and receive a confirmation page. They continue to receive transactional emails (order confirmations, security alerts).