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 toolAcceptance 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.
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. |
Start with the main success scenario in Given-When-Then. This is the spine; everything else hangs off it.
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.
What happens when something fails — bad input, network loss, a permission denied? Define the expected behaviour explicitly, or the build will improvise it.
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.
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 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 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” |
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.
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.
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.
Writing thorough acceptance criteria is exactly the kind of detailed, enumerable work AI speeds up — with careful review.
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.
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.