Acceptance Criteria: How to Write Them (with Examples)
Master acceptance criteria: Given/When/Then and checklist formats, concrete examples by story type, who writes them, and the mistakes that ruin them.
By the RoadmapHero team · Updated on · 7 min read
Key takeaways
- Acceptance criteria are the conditions a user story must satisfy to be considered done, written as binary pass/fail checks that product, developers and QA read the same way.
- Two formats work: Given/When/Then scenarios for behavior-heavy stories such as payments or permissions, and a rule-based checklist for simpler stories.
- Most stories need 3 to 7 criteria; more than 8 usually means the story is too big and should be split before it enters a sprint.
- The PM or product owner is accountable, but criteria are best hardened by product, engineering and QA together during refinement and frozen before sprint planning.
Acceptance criteria are where a user story stops being a wish and becomes a contract. They answer one question — "how will we know this is done?" — in terms everyone reads the same way: product, developers, QA, stakeholders. Teams that skip them do not save time; they move the argument about what "done" means from refinement (cheap) to sprint review (expensive).
What acceptance criteria are for
A story like "As a subscriber, I want to update my payment method, so that my service is not interrupted" is intentionally short. Acceptance criteria fill the gap between intent and implementation. They serve four purposes at once:
A shared definition of done — the developer, the PM and the tester agree on the finish line before the race starts.
A scope fence — anything not in the criteria is explicitly out, which is your best defense against silent scope creep.
A test blueprint — each criterion translates almost directly into a test case, manual or automated.
An estimation aid — teams estimate far better when the edge cases are written down instead of discovered mid-sprint.
Note the distinction with the Definition of Done: the DoD is global (code reviewed, tests green, deployed to staging) and applies to every story; acceptance criteria are local to one story. A story ships when it satisfies both.
The two formats that work
Format 1: Given / When / Then
Borrowed from Behavior-Driven Development (BDD), this format frames each criterion as a scenario:
Given [an initial context], When [an action happens], Then [an observable outcome].
Its strength is precision: it forces you to state the starting conditions and the expected result, which is exactly where ambiguity hides. Use it for behavior-heavy stories — payments, permissions, workflows — and whenever QA wants to automate the scenarios (tools like Cucumber execute this syntax directly).
Format 2: rule-based checklist
A plain verifiable list: "The export contains the columns X, Y, Z", "The file downloads in under 5 seconds for 10,000 rows", "Dates use the workspace timezone". Faster to write and to read, ideal for simple stories where full scenarios would be ceremony. Many teams mix both: checklist by default, Given/When/Then for the tricky flows.
Concrete examples by story type
A form story (checklist works well)
Story: "As a new user, I want to sign up with my email, so that I can try the product."
Email format is validated on blur, with an inline error message.
Password must be 12+ characters; a strength indicator updates live.
An account activation email is sent within 1 minute.
Submitting an already-registered email shows "This email is already in use" without revealing account details.
A payment story (Given/When/Then earns its keep)
Given a subscriber with a valid card, when they confirm the upgrade, then the plan changes immediately and a prorated invoice is issued.
Given a card declined by the provider, when the user confirms payment, then no plan change occurs and the exact decline reason is displayed.
Given a payment pending 3-D Secure validation, when the user closes the window, then the subscription remains unchanged and the attempt is logged.
A reporting story (mixed)
The CSV export includes one row per ticket with status, assignee, story points and dates.
Given a filter on "last quarter", when the user exports, then only matching tickets appear in the file.
Export of 50,000 rows completes in under 30 seconds or runs asynchronously with an email link.
Notice what these examples share: every line is binary. A reviewer can answer pass or fail without interpretation. "The form should be user-friendly" is not a criterion; "all errors are announced to screen readers" is.
Who writes them, and when
The PM or product owner is accountable for acceptance criteria, but writing them solo is a known failure mode. The proven approach is the three amigos: product brings the intent, engineering brings feasibility and edge cases, QA brings the "what could break" instinct. Thirty minutes per batch of stories during backlog refinement is enough.
Timing matters as much as authorship:
At story creation — a rough draft of 2–3 obvious criteria captures the intent while it is fresh.
During refinement — the three amigos harden the list, add edge cases, delete duplicates. This is where most of the value is created.
Before sprint planning — criteria are frozen. A story without final criteria is not sprint-ready, full stop. This is a core element of a good user story lifecycle.
During the sprint — criteria only change through an explicit conversation with the PM, never by silent reinterpretation.
Acceptance criteria, QA and testing
Well-written criteria collapse the distance between specification and verification:
Manual QA reads criteria as its test charter — no need to reverse-engineer intent from the UI.
Automated tests map one-to-one to Given/When/Then scenarios; BDD frameworks execute them as living documentation.
Demo scripts at sprint review follow the criteria list, which keeps stakeholder feedback focused on outcomes rather than pixels.
A practical rule: if QA files a bug that no acceptance criterion covers, ask whether the criterion was missing (fix the refinement habit) or the requirement was genuinely new (make it a new story). This feedback loop steadily improves the team's criteria-writing — and its sprint planning accuracy along with it.
Mistakes that ruin acceptance criteria
Technical criteria — "uses Redis for caching" describes the how, not the what. Keep implementation choices in the task, not the acceptance list. Criteria must stay observable from the outside.
Chasing exhaustiveness — you cannot enumerate every possible state, and trying produces 25-line lists nobody reads. Cover the nominal path, the risky edges and the failure modes; trust the Definition of Done and the team's judgment for the rest.
Subjective wording — "fast", "intuitive", "clean" are opinions. Replace with numbers or observable behavior.
Criteria as UI spec — pinning button colors and pixel positions freezes design too early. Link the mockup instead.
Copy-pasted boilerplate — "works on all browsers" pasted on every story is Definition of Done material, not a story criterion.
Writing them after development — criteria written to match what was built verify nothing. If this happens regularly, your stories enter sprints unready.
Acceptance criteria in RoadmapHero
RoadmapHero's tickets are built for this workflow: write acceptance criteria as checklists directly on each story, alongside story points, dependencies, custom fields and the customer feedback linked through Customer Voice — so the criteria trace back to what users actually asked for. Ticket health flags stories that entered a sprint without criteria, and the Jira, Linear and GitHub integrations carry your tickets into delivery without retyping. When a story ships, AI-generated release notes turn the completed work into a changelog your customers can read. Free trial, transparent pricing in euros, no commitment.
Frequently asked questions
What are acceptance criteria in agile?
Acceptance criteria are the conditions a user story must satisfy to be considered done. They turn the story's intent into verifiable statements — pass/fail checks that product, developers and QA all read the same way.
How many acceptance criteria should a user story have?
Between 3 and 7 for most stories. Fewer than 3 usually means the behavior is underspecified; more than 8 suggests the story is too big and should be split before entering a sprint.
What is the Given/When/Then format?
Given/When/Then (from Behavior-Driven Development) structures a criterion as context, action and outcome: "Given an expired card, When the user confirms payment, Then an explicit error is shown and no charge is made". It forces precision on state and expected result.
Who is responsible for writing acceptance criteria?
The product owner or PM is accountable for them, but the best criteria come out of a three-amigos conversation between product, engineering and QA during refinement. Criteria written solo systematically miss edge cases.
Are acceptance criteria the same as the Definition of Done?
No. Acceptance criteria are specific to one story (what this feature must do). The Definition of Done applies to every story — code review passed, tests written, deployed to staging. A story is done when it meets both.