Acceptance Criteria
The precise, testable conditions that define 'done' for a user story.
Why
Acceptance criteria are the only thing that makes 'done' mean the same thing to the PM, the engineer, and QA. Without them, 'done' is a vibe check, and features get marked complete with edge cases untested and performance unmeasured. Written as Given/When/Then, criteria are directly translatable to automated tests, which closes the loop between spec and verification. A story with no acceptance criteria is a story that cannot be estimated, tested, or signed off — it's just a wish.
When
Before estimation, as part of each user story. Takes 10-15 min per story. Never skip — a story without criteria is not ready for the sprint.
How
1. For each user story, list 3-7 criteria that must all be true for "done" 2. Write each as Given/When/Then: - Given [precondition/state] - When [user action] - Then [observable result] 3. Include at least one negative path (what happens on error/invalid input) 4. Include at least one performance criterion if the story is user-facing (e.g. "response < 200ms at 100 concurrent users") 5. Review criteria with QA — they will write tests from these, so ambiguity = bugs 6. Criteria are frozen at sprint planning; changes mid-sprint require a re-plan
Example
Story: As a billing-owner, I want to download an invoice CSV. Acceptance criteria: 1. Given I have 50 invoices, When I click "Export CSV", Then a file downloads within 3s containing all 50 rows. 2. Given I have 0 invoices, When I click "Export CSV", Then I see "No invoices to export" and no file downloads. 3. Given the CSV is generated, Then the columns match the QuickBooks schema exactly (Date, Amount, Status, Description). 4. Given a non-billing-owner user, When they access the export URL, Then they receive a 403 and no file is generated.
Common Problems
- ⚠Writing criteria as capabilities ('the export works') instead of observable conditions — QA cannot test 'works'.
- ⚠Omitting the negative/error paths — 80% of bugs live in the edge cases the happy-path criteria ignore.
Best Practices
- ✓Aim for 3-7 criteria per story — fewer means the story is under-specified, more means it's too big.
- ✓Have QA co-write criteria, not just review them — they think in test cases and catch gaps PMs miss.