Acceptance criteria are the conditions a feature must satisfy to be considered done — the testable definition of "done" that turns a vague story into something QA, engineering, and the PM can all agree was or wasn't met. This page covers what they are, the two formats that actually get used (Given/When/Then and the checklist), examples, and a template. Then the honest part: criteria are written against a spec, the spec moves, and a criterion copied into a ticket silently disagrees with the spec it came from.
Acceptance criteria are the specific, testable conditions under which a user story or requirement is accepted as complete. They turn "build search" into something checkable: what counts as working, what the edge cases are, what happens when it fails. Their job is to remove ambiguity before code is written, so "is it done?" has an answer everyone agreed on in advance instead of a debate in review.
They're distinct from a definition of done (which is a team-wide bar that applies to every story — tests pass, docs updated) and from the requirement itself (which says what to build; criteria say how you'll know it's built right). Good criteria are written before development, testable, and focused on outcomes, not implementation.
Most acceptance criteria take one of two shapes. Pick by whether behavior is conditional (scenario) or a flat list of must-haves (checklist).
Given [context], When [action], Then [outcome]. E.g. "Given a thread with 3 cards, When I export to PDF, Then all 3 cards appear in order." Best when behavior depends on state — it forces you to name the context, which is where bugs hide. This is the BDD format.
A bulleted list of conditions that must all be true: "Search returns results in under 500ms", "Empty query shows a hint", "Results are paginated at 20." Best for a set of independent must-haves where there's no conditional flow to model.
The conditions everyone forgets: empty states, failures, permissions, limits. A criterion set that only covers the happy path is half a spec — the missing half is exactly what generates the bug report. Name what happens when it goes wrong.
A good set: 3–7 criteria, each independently testable, covering the happy path and the obvious failures. More than that usually means the story is too big.
Acceptance criteria are written against a spec at one moment. The spec then changes — a decision reverses, a requirement is re-cut — and the criteria, copied into a ticket, keep testing the old version. Draftlize links the criteria to the spec they came from.
In Draftlize a criterion isn't text pasted into a ticket — it's tied to the spec card it verifies. The "done when" references the requirement instead of restating it, so the two can't silently diverge into a ticket that says one thing and a spec that says another.
Re-cut the requirement and the criteria that tested the old one auto-flag stale — so QA isn't the place you discover the acceptance test no longer matches the spec. The mismatch surfaces when the spec moves, not three days into the sprint.
When Claude Code or Cursor implements or writes tests over MCP, it reads the criteria and the linked spec together — so what it builds and checks against is the current definition of done, not a Given/When/Then that fossilized two decisions ago.
Acceptance criteria are only as true as the spec they were copied from. The trouble is the spec doesn't tell the copy when it changed.Keep Given/When/Then. Link the criteria to the spec instead of copying it.
Acceptance criteria are specific to one story — the conditions that make that particular feature complete. Definition of done is a team-wide checklist that applies to every story (tests written, code reviewed, docs updated). Criteria say "is this feature right"; definition of done says "is any story shippable."
A way of writing a criterion as a scenario: Given some context, When an action happens, Then an outcome is expected. It comes from behavior-driven development and is strongest when behavior depends on state, because it forces you to name the context the behavior occurs in.
Usually the product manager or product owner drafts them, refined with engineering and QA before development starts. Writing them with the people who will build and test the feature is what catches the missing edge cases early, while they are still cheap.
Typically three to seven, each independently testable, covering the happy path and the obvious failure and edge cases. If you need many more, the story is probably too big and should be split.
Write criteria in the format above, or as cards in Draftlize linked to the spec they verify — so when the spec moves, the acceptance test flags stale instead of passing against a definition of done that no longer holds.
Start free with $5