Acceptance Criteria Examples: Given/When/Then and Checklists

Acceptance criteria are the conditions a piece of work must meet to be accepted, and there are two common ways to write them. A checklist states rules, each one true or false: “Reorder adds every item still on sale to the cart.” A scenario walks through one example in three steps: Given some starting situation, When something happens, Then a particular result can be seen. Checklists are quicker to write and read; scenarios are better when the order of events or the starting state matters. Most teams use both, and the examples below show each.

The stories these criteria belong to are covered in the user story template, and twenty full stories with checklist criteria are in user story examples. Acceptance criteria belong to one item; a team-wide definition of done applies to every item, and is a separate list, as acceptance criteria vs definition of done explains.

Format 1: the checklist of rules

The GOV.UK Service Manual’s guide to writing user stories↗ (opens in a new tab) describes acceptance criteria as a list of outcomes used as a checklist, and suggests starting them with “it’s done when…”. That phrase is a good test: if a line does not finish the sentence sensibly, it is not a criterion.

It's done when:
  - A saved card can be removed from the Payment methods page
  - Removing the default card asks which card becomes the default
  - A card used by an active subscription cannot be removed,
    and the message names the subscription
  - Existing payment tests pass unchanged

Format 2: Given/When/Then scenarios

The Agile Alliance glossary describes Given-When-Then↗ (opens in a new tab) as a template for acceptance tests: given some context, when some action is carried out, then a particular set of observable consequences should follow. Cucumber’s Gherkin reference↗ (opens in a new tab) defines the same keywords for scenarios that can be run as tests: Given is the initial context, usually something that happened in the past; When is an event or action; Then is an expected outcome that can be observed. And and But join several steps of the same kind.

Scenario: Removing the card an active subscription uses
  Given I have two saved cards
  And my monthly plan is paid with the card ending 4242
  When I try to remove the card ending 4242
  Then I see "This card pays for your Monthly plan"
  And the card is still saved

The same reference gives three pieces of advice worth keeping even if you never automate a scenario: keep each one to three to five steps, describe behaviour without assuming a particular screen or technology, and make Then something a user or caller could observe, not a row in a database. When one rule needs several rows of data, a Scenario Outline with an Examples table runs the same steps once per row, and the Rule keyword groups the scenarios that illustrate one business rule.

When to use each

• Use a checklist when each condition stands on its own: fields on a form, columns in an export, what a page must show. Most criteria are like this.
• Use a scenario when the starting state or the order of events changes the answer: permissions, money, retries, anything with a before and after.
• Use a Scenario Outline with an Examples table when one rule has many cases: validation, pricing bands, date boundaries.
• Use scenarios when the team will automate them with Cucumber or a similar tool. Otherwise a mixed list is fine: rules first, then a scenario for the one tricky case.

Twenty examples by feature type

Forms and validation

• 1. Sign-up form: the email field rejects an address without an @ and says why; a password shorter than 12 characters is rejected before submit; submitting with an email already registered offers a sign-in link instead of an error code.
• 2. Address form: the postcode is checked against the country chosen; changing the country clears the postcode; a failed check keeps everything else the person typed.

Scenario Outline: Sign-up needs an age of 18 or over
  Given today is 2026-09-28
  When I enter a date of birth of <dob>
  Then sign-up is <result>

  Examples:
    | dob        | result  |
    | 2008-09-28 | allowed |
    | 2008-09-29 | refused |
    | 1950-01-01 | allowed |

Sign-in and accounts

Scenario: Five wrong passwords lock the account for 15 minutes
  Given I have entered a wrong password 4 times in the last 10 minutes
  When I enter a wrong password again
  Then I see "Too many attempts. Try again in 15 minutes."
  And the correct password is also refused until then

• 5. Password reset: the reset link works once and expires after one hour; requesting a reset for an unknown address shows the same message as for a known one; a successful reset signs out every other session.
• 6. Removing a member: after removal, their next request is refused even in a tab left open; their past work still shows their name; the removal is recorded with who did it and when.

Search and lists

• 7. Search: an exact product name returns that product first; a one-letter typo still finds it; no results suggests the nearest match instead of an empty page.
• 8. Filters: filters combine with AND; the chosen filters survive a page reload; clearing all filters returns the unfiltered count shown before.
• 9. Pagination: 50 rows per page; the last page shows the remainder; changing a filter returns to page one.

Payments and money

Scenario: The same payment request sent twice
  Given a payment request with idempotency key "ord-1042"
  And it succeeded
  When the same request is sent again with key "ord-1042"
  Then no new charge is made
  And the response is the original payment's result

• 11. Refunds: a partial refund cannot exceed the amount still unrefunded; the customer receives an email naming the amount; the order shows each refund with its date.
• 12. Discount codes: an expired code says it has expired, not that it is invalid; one code per order; the discount appears as its own line on the receipt.

Notifications and email

• 13. Low-stock alert: one email when stock falls below the threshold; no second email until stock has risen above it again; the email names the product and the current count.
• 14. Unsubscribe: the link works without signing in; it turns off that type of email only; account and security emails still arrive.

Reports, exports and files

• 15. CSV export: includes rows added today; column order is unchanged from the current export; commas inside a field do not split the column.
• 16. File upload: accepts PDF, JPG and PNG up to 10 MB; a larger file is refused before upload starts, with the limit stated; an upload interrupted by a lost connection can be retried without choosing the file again.

Non-functional

• 17. Performance: the dashboard loads in under two seconds on the staging data set over the agreed test connection, measured three times.
• 18. Accessibility: every form field has a visible label; the whole checkout can be completed with a keyboard alone; error messages are announced by a screen reader.

An API

• 19. Expired token: returns 401 with an error code for expiry that differs from the one for an invalid token; the body says when it expired; other error responses are unchanged.

Not software

• 20. Handing over a finished room: every snag on the list has a before and an after photo; the client has signed the list; spare tiles and paint are labelled and left in the room.

Common mistakes

• Words nobody can check: fast, intuitive, user-friendly, robust. Replace each with a number or something you can observe.
• Describing the build instead of the result: “add an index to the orders table” is a plan, not a criterion. “The orders page loads in under a second” is the criterion.
• Only the happy path. Name the edge cases you care about: empty, too large, no permission, twice in a row, lost connection.
• Forgetting what must not change. “Existing tests pass” and “the export columns stay in the same order” catch the regressions nobody asked for.
• Scenarios full of clicks. “When I click the blue button in the top right” breaks the day the button moves. Describe the action: “When I remove the card.”
• Too many. More than seven or so usually means the story should be split rather than the list lengthened.
• Written after the work. Criteria agreed at review are a description of what was built, not a check of it.

Who writes them, and when

Whoever owns the need drafts them, usually a product owner or the person who asked, and the people who will do and test the work sharpen them before it starts. The Scrum Guide calls this preparation Product Backlog refinement↗ (opens in a new tab): breaking items down and defining them more precisely. It does not prescribe a format for acceptance criteria, so any of the above is compatible with it.

One structured way to do it is Example Mapping↗ (opens in a new tab), described in the Cucumber docs: the story goes on a yellow card, each rule or acceptance criterion on a blue card, the examples that illustrate each rule on green cards, and questions nobody can answer yet on red ones. A story that ends the session covered in red is not ready to start. A story with a few blue cards and a green example under each has its criteria, and the examples can become scenarios.

The timing matters more than the format. Criteria are written before work starts and agreed by the person who will accept the result. If they change during the work, say so on the card, so nobody reviews against a list that no longer applies.

Criteria an AI assistant can work to

Checkable criteria matter more when an AI assistant does the work, because it will not ask what “fast” means; it will decide. Each criterion should be something it can show evidence for: a test name, a timing, a screenshot, a response body. Say which criteria only a person can confirm, such as a real payment or an email arriving in an inbox. The rest of what an assistant needs on the card, where to work, what not to touch and when to stop, is covered in how to write a task for an AI agent, and checking what comes back in verifying AI-generated work.

On a fenbs board the criteria go in the task’s Problem box (note over MCP) alongside the story, and the approach goes in the Plan box (plan). When the work is checked, the Testing field records the result against those criteria: Tested, Partly tested, Failed, or Needs owner check for what only a person can confirm, with notes saying what was checked and what was not. An assistant sets these with testStatus and testNotes; a person reads them and moves the task to Completed. fenbs has no sprints, story points or due dates, so the criteria and the test record are what say a task is done.