Acceptance Criteria
The testable conditions that define “done” — so QA can verify a feature without asking the PM, and edge cases get decided before the sprint, not during it.
▸ Try the interactive toolThe framework
Acceptance Criteria (AC) are specific, testable conditions a feature must satisfy to be considered done. They live alongside user stories and answer the one question every engineer, QA tester, and PM needs settled at sprint start: how will we know when this is finished?
The Given-When-Then format (also called Gherkin) structures each criterion as a scenario: a starting state, an action, and an expected result. Writing AC forces the PM to confront edge cases and error states before the build — which is exactly when those decisions are cheap. Vague AC push those decisions into the sprint, where they're made hastily by whoever hits them first.
Given [a starting context], When [an action occurs], Then [an expected, testable result].
Write the happy path first, then edge cases, then error states — one scenario per condition.
Try it yourself
What it prevents
Most mid-sprint chaos and most QA back-and-forth trace to one root cause: nobody defined “done” precisely before the work started.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| “Done” is subjective | Engineer, QA, and PM each have a different idea of finished. | AC give one objective, testable definition everyone shares. |
| Edge cases decided in panic | “What happens if the list is empty?” gets answered mid-build, badly. | Writing AC forces edge cases into the open before the sprint. |
| QA can't test independently | Without criteria, QA must interrupt the PM to learn what “right” means. | Testable AC let QA verify without asking anyone. |
| Silent product decisions | A skipped edge case is a product decision — made by accident. | AC surface those decisions so the PM makes them deliberately. |
Step by step
Write the happy path first
Start with the main success scenario in Given-When-Then. This is the spine; everything else hangs off it.
Add the edge cases
What about empty states, maximums, simultaneous actions, first-time vs. returning? Each is a scenario. Writing them now is far cheaper than discovering them in QA.
Add the error states
What happens when something fails — bad input, network loss, a permission denied? Define the expected behaviour explicitly, or the build will improvise it.
Make each criterion independently testable
Read each one as QA: could you verify it without asking a question? If “Then” is vague (“it works correctly”), rewrite it to something observable.
Use unanswerable criteria as a discovery signal
If you can't write the “Then” for some case, you've found an undecided product question. Resolve it now — that's the AC doing its most valuable work.
A short illustration
A story to “let users save a draft” shipped with only a happy-path AC. Mid-sprint, QA hit the questions nobody had answered: what if the draft is empty? what if two devices save at once? what if storage is full? Each got a rushed answer, and one shipped as a bug.
Re-run with full AC up front, the same story surfaced all three cases as Given-When-Then scenarios in the planning room. Two were quick decisions; the third revealed an actual product question — conflict resolution — that deserved a real answer before any code was written.
The criteria set
The deliverable is a set of Given-When-Then scenarios attached to the story — happy path, edge cases, error states.
| Layer | Covers | Example Then |
|---|---|---|
| Happy path | The main success case | “…the draft is saved and a confirmation appears” |
| Edge case | Boundaries & unusual states | “…an empty draft is not saved and the user is told why” |
| Error state | Failures | “…on a network error, the draft is queued and retried” |
Why it matters
Every edge case you don't specify is a product decision you've delegated to whoever hits it first, under time pressure, with no context. AC are how the PM keeps those decisions.
The deepest value of writing acceptance criteria is the questions you can't answer. A criterion you can't complete isn't a writing problem — it's an undecided product question hiding in the story. Surfacing it before the sprint, when the team has time to think, is dramatically cheaper than surfacing it mid-build as a bug or a shrug. Good AC don't just define done; they flush out the decisions the story was quietly assuming.
Common mistakes
Edge cases and errors are where the bugs live. Cover all three layers.
“It works correctly” can't be verified. Make every result observable.
AC written post-hoc just describe what was built, including its mistakes. Write them before.
A criterion you can't complete is a flag, not a nuisance. It's an undecided product question — resolve it.
When not to use it
- Trivial, obvious changes. A copy tweak doesn't need Given-When-Then. Reserve AC for anything with real behaviour or edge cases.
- Pure exploration / spikes. A research spike has no “done” to define yet — AC come once you're building a real solution.
- As a substitute for conversation. AC support the story conversation; they don't replace talking through the tricky cases with engineering.
Where this sits in the toolkit
AC deliver the “Testable” that INVEST demands — stories and criteria are always written together.
Clear AC let engineering build and QA verify without round-trips to the PM.
Unanswerable criteria flag undecided questions — a discovery signal feeding back into problem framing.
Definition of Done, spec types, and the PRD all build on the AC discipline.
How AI changes this in practice
Writing thorough acceptance criteria is exactly the kind of detailed, enumerable work AI speeds up — with careful review.
- Draft criteria: give the story and ask for Given/When/Then criteria covering the main path; edit for correctness.
- Find the edge cases: ask 'what edge cases and failure states am I missing?' — AI is strong at surfacing the boundary conditions humans skip.
- Tighten ambiguity: have it flag criteria that aren't objectively testable.
The judgment that stays yours: AI will happily generate plausible-looking criteria that are subtly wrong for your system. Every criterion still needs your review against how the product actually works — it drafts, you verify.
Write AC for a simple feature
Pick a small feature (a search box, a save button). Write the happy-path criterion in Given-When-Then, then force yourself to add three edge cases and two error states.
Try to write the “Then” for each. Notice the one you can't complete cleanly.
That incomplete criterion is a product decision you hadn't realised you were making. Finding it on paper, not in production, is the entire value of the practice.
New tools and AI deep-dives, occasionally.
No spam. Unsubscribe anytime.