Acceptance criteria for a login, a checkout, a form, a layout, an accessibility need and a design come in two common formats and a third, less common, in the user-story voice. The rule picks the format: a single condition fits a checklist line, an outcome that depends on earlier state fits Given/When/Then, and a permission a role sentence.
Which formats do acceptance criteria take?
Deciding what a criterion should say is a separate job, argued in how to write acceptance criteria, and the line between a story’s criteria and the team’s standing checklist is drawn in acceptance criteria vs definition of done. The format question is narrower: once the rule is known, which shape does it read best in? Two shapes turn up most often, in backlogs and in published examples alike, and a third turns up less often.
A rule-oriented checklist states one condition per line, each true or false of the build: “A discount code is accepted in upper or lower case.” A Given/When/Then scenario sets a starting state, takes one action and names what the user then sees: “Given a saved address outside the delivery area, When the shopper selects it at checkout, Then the delivery step says the address cannot be served and payment stays locked.” The third shape borrows the template of the user story itself, a role and a capability, and writes the criterion in that voice: “As a guest, I can pay without creating an account.” Strictly, the template frames the story and the criteria hang beneath it as conditions, so the borrowed voice is worth its extra words only where the role is what the condition is about.
| Format | Shape of one criterion | Fits when | Strains when |
|---|---|---|---|
| Rule checklist | One condition, true or false of the build | The rule holds whatever came before: a field limit, a label, an accepted input format | The outcome depends on earlier state, and the line grows clauses to say which |
| Given/When/Then | A starting state, one action, an observable outcome | The same action ends differently in different states: a sold-out item, a locked account, an expired session | The rule is a single condition and three steps pad it out |
| User-story voice | A role and what that role can or cannot do | Permissions, guest against signed-in, an action reserved for admins | Nobody’s role changes the outcome, and “As a user, I can” adds words and no information |
The format is picked per criterion, never per team. A checkout story can carry four checklist lines, two scenarios for the states that change the outcome and one role sentence for the guest path, and a tester can work through the mix without trouble, since each line still names one thing to check. Forcing everything into Given/When/Then produces scenarios whose Given is “a user on the page”; forcing everything into a checklist produces lines that begin “if the user had previously”. None of this outranks the point made in how to write acceptance criteria: whether somebody who never saw the design could check a criterion matters more than the shape it is written in.
What do acceptance criteria look like for common features?
Six features follow, with the format chosen rule by rule. Values such as a count of failed sign-ins are placeholders a team replaces with its own; where a value comes from a published standard, the standard is named beside it.
Login
- A registered user who signs in with the correct email and password lands on the page they had requested before being asked to sign in.
- A wrong password and an unregistered email produce the same message, so the form never reveals which addresses hold accounts.
- The password field hides what is typed and offers a control to show it.
- Given an account that has reached the team’s limit of consecutive failed sign-ins (five, in this example), when the correct password is entered, then the sign-in is refused and the message explains how to unlock the account.
Checkout
- As a guest, I can pay without creating an account, and an account is offered only after the order is confirmed.
- The total on the payment step equals the cart subtotal plus the shipping and tax shown on the step before it.
- Pressing the pay button twice creates one order and one charge.
- Given a cart item that sold out after it was added, when the shopper opens checkout, then the item is marked unavailable and the total excludes it before any payment is taken.
Form validation
- Each field in error is identified and the error is described in text, which is what WCAG 2.2 success criterion 3.3.1, Error Identification (Level A), asks of a detected input error. Showing each message beside its field is this team’s choice, since WCAG leaves the placement open.
- Submitting a form with errors keeps every value already entered, apart from the password fields.
- A phone number typed with spaces, dashes or brackets is accepted and stored in one format.
- Given an email address that already belongs to an account, when the sign-up form is submitted, then the form says a confirmation email has been sent, exactly as it does for a new address, and the email that arrives offers links to sign in and to reset the password.
Responsive layout
- At every supported width, no content or function needs horizontal scrolling to reach. WCAG 2.2’s Reflow criterion (1.4.10, Level AA) asks for this at a width equivalent to 320 CSS pixels, with exceptions for content that needs a two-dimensional layout to make sense, such as data tables, maps and diagrams, which makes 320 a common choice for the narrowest supported width.
- Below the tablet breakpoint, the main navigation collapses into a menu that opens by tap and by keyboard.
- Product images keep their proportions at every supported width.
- Given a shopper halfway through the checkout form on a phone, when they rotate it from portrait to landscape, then every value they entered is still there.
Accessibility: a modal dialog
- When the dialog opens, keyboard focus moves into it; Escape closes it; on closing, focus returns to the control that opened it.
- While the dialog is open, Tab moves only among its own controls and never reaches the page behind it.
- A screen reader announces the dialog’s title when it opens.
Visual design: pricing cards
- The pricing cards use the design system’s card component and type scale, and a reviewer comparing the built page with the approved mock-up, version and breakpoint named in the story, finds no difference in spacing, colour or type.
- No plan name or price wraps onto a second line at any supported width.
- The recommended plan is marked by the label and border in the mock-up as well as by colour, since colour alone would fail WCAG’s Use of Color criterion (1.4.1, Level A).
A visual criterion names its reference, because “looks right” has no reference anyone can open. One that has to hold on every release belongs in a visual regression run once it has passed by eye.
How are non-functional criteria written?
Speed, accessibility and security belong to the non-functional requirements, the qualities a working feature can still fall short on. As acceptance criteria they go wrong in one way, by naming the quality with no measure attached, and the repair is a number with its circumstances: the metric, the setting it is taken in, the value that passes, and the name of whoever set that value. A performance target for one page belongs to the story that builds that page. An accessibility level the whole product has committed to is checked on every story, so teams tend to keep it with their standing checklist, and a story carries accessibility rows of its own when it introduces something that checklist has not met, such as a new component.
| Quality | Vague version | Testable criterion | Where the threshold comes from |
|---|---|---|---|
| Performance | “The product page is fast” | On mobile, Largest Contentful Paint for the product page is 2.5 seconds or less at the 75th percentile of page loads | Google’s published “good” threshold for LCP (web.dev), used here as an example target |
| Performance | “Search is quick” | Search returns its first page of results within the agreed time, measured against a production-sized catalogue | The team and the product owner; no standard sets it |
| Accessibility | “The page is accessible” | Body text has a contrast ratio of at least 4.5:1 against its background | WCAG 2.2, 1.4.3 Contrast (Minimum), Level AA |
| Accessibility | “It works on touch screens” | Every tap target is at least 24 by 24 CSS pixels, or meets one of that criterion’s listed exceptions | WCAG 2.2, 2.5.8 Target Size (Minimum), Level AA |
| Accessibility | “Keyboard users can use it” | Every function on the page can be operated from a keyboard alone, apart from any that depends on the path of the pointer, such as freehand drawing | WCAG 2.2, 2.1.1 Keyboard, Level A |
| Security | “Sessions are secure” | After sign-out, a request carrying the old session cookie is refused, and the back button shows no account data | The team’s security requirements; no figure |
| Security | “Users only see their own data” | Requesting another customer’s order by changing its ID in the address bar returns a not-found page | The team’s security requirements; no figure |
| Security | “Passwords are protected” | No password, session token or full card number appears in the application logs after a test sign-in and a test purchase | The team’s security requirements; no figure |
Two kinds of number sit in that table, and they carry different weight. The WCAG figures are that standard’s own success criteria at the level stated, so a team committed to WCAG 2.2 AA inherits them as written. The LCP figure is guidance Google publishes for a good experience; it appears here as an example, and a team may adopt it, tighten it or set its own without breaking any standard. Where no source sets a threshold, the criterion carries the number the team agreed, and the story records who agreed it.
The security rows share a pattern worth copying. “Secure” cannot be observed, and a refused request can, so a security criterion is written as an attack that fails: the old cookie, the edited ID, the search through the logs.
How does a criterion become a UAT test case and a sign-off line?
A criterion in good shape is most of a UAT test case already, and Given/When/Then converts with the least editing. The sold-out checkout scenario from above maps field by field:
| Test case field | Taken from | Sold-out checkout example |
|---|---|---|
| Business scenario | The story and its role | A shopper checks out a cart holding an item that sold out after it was added |
| Preconditions | The Given | A test account with two items in the cart; one item’s stock set to zero in the UAT environment |
| Steps | The When, spelled out as actions | Open the cart; select Checkout |
| Expected result | The Then | The sold-out item is marked unavailable; the total covers only the item in stock; no payment is taken for the sold-out item |
| Actual result, status, tester, date | The run | Filled in during UAT |
| Defect link | A failed run | Raised when the status is fail |
A checklist line converts with one difference: it has no Given or When, so the tester writes the preconditions and steps, and the line itself becomes the expected result. A role sentence supplies the account type in the preconditions. Coverage is then counted criterion by criterion, since a criterion with no case behind it is untested however much else passed, and a requirements traceability matrix is where that gap becomes visible.
At the end of the window, the UAT sign-off names the criteria the build was judged against, so each criterion ends as one line of it: passed, failed with its defect, or accepted on a condition with an owner. The UAT test plan template is where the criteria and the signer are settled before testing opens, and the UAT checklist carries the result of each scenario through to that sign-off record.
Why a failed case’s actual result is so often thin is argued in UAT best practices. Notarus has a part in one field of that table, the defect link: a tester who files the failure from a review session (on Pro and above) sees a receipt card appear on the element with the id the new ticket was given, and that id is what the tester enters as the case’s defect link, so the case, its criterion and the ticket name one another.
What makes an acceptance criterion testable?
INVEST, the story checklist Bill Wake published in 2003, ends in Testable, and a story meets that letter through its criteria. A criterion is testable when its verdict does not depend on who checks it: a tester who never met the author gets a pass or a fail from the build alone. The usual failures are words whose meaning moves with the reader.
| Weak criterion | What is missing | Testable version |
|---|---|---|
| “The page loads quickly” | A measure and a threshold | A load metric, the device class and the agreed threshold, as in the performance rows above |
| “Errors are handled gracefully” | Which error, and what the user sees | When the payment provider times out, the shopper sees a retry option and no order is created |
| “Works on mobile” | Which widths and which browsers | Every checkout step completes on the phone browsers the team supports, at the narrowest supported width |
| “The returns policy is easy to find” | An act somebody can perform | From any page, the returns policy is one click away through the footer, and a search for “returns” lists it first |
| “Same as the current site” | A reference anyone can open | Matches the approved mock-up, with its version and breakpoint named |
| “The user is notified” | The channel and the content | An email naming the order number reaches the address on the account |
Two practices catch these before anyone writes them down. Example mapping, the card workshop Matt Wynne introduced on the Cucumber blog in 2015, puts each rule of a story on a blue card with green example cards beneath it, each titled in a line such as “the one where the code has expired”. When nobody can give an example for a rule or say what should happen, the doubt goes on a red question card while the rule keeps its blue one, and that red card is an untestable criterion caught before it exists. The green titles are expanded into full scenarios later, once the session is over. The Three Amigos conversation sets the business side, the developer’s view and the tester’s view against the story before the sprint, and the tester’s view is the one that asks what a passing build would look like, which puts the testability question before the sprint instead of at acceptance.
Both move the question to refinement, where rewording a criterion is cheap. A team whose definition of ready already asks for agreed criteria can add one line to it: every criterion has at least one example. Drafting the UAT case early is a check of its own, the one requirements validation uses to surface a requirement nobody can test. And a story whose criteria no longer fit one sprint’s testing is usually an epic that needs splitting before anyone puts story points on it.
Related terms and guides
- Acceptance criteria: the definition, and who agrees the conditions
- User story: the role, capability and benefit a story is written in
- Given-When-Then: the three-step scenario and its Gherkin keywords
- INVEST criteria: six questions put to a draft story
- Definition of ready: the checklist an item meets before a sprint takes it
- Epic vs user story: where a body of work splits into stories
- Story points: sizing stories relative to one another
- Example mapping: rules, examples and questions on four colours of card
- Three Amigos: business, development and testing views on one story
- Non-functional requirements: qualities such as speed, security and accessibility
- Requirements validation: checking a specification against the real need
- Requirements traceability matrix: each requirement mapped to the tests that verify it
- UAT test case: a business scenario with steps, an expected result and a status
- UAT sign-off: the recorded decision that accepts a build
- How to write acceptance criteria a build can fail: writing criteria from the user’s situation
- Acceptance criteria vs definition of done: the product owner’s check and the team’s
- How to write test cases worth a second run: the cases that sit beneath a criterion
- UAT best practices end where the finding starts: running the acceptance window itself
