What are acceptance criteria?
Acceptance criteria are the specific, testable conditions a user story must satisfy before it counts as done. The story describes what we are building; acceptance criteria define working. Without them, "done" is opinion.
The two common formats
Bullet list (rule-based). Plain English, one rule per bullet:
- Login fails after 5 incorrect password attempts.
- The user is shown a generic error, not "wrong password" specifically.
- An audit log entry is written.
Given / When / Then (Gherkin / scenario-based). Behaviour-driven, easy to translate into automated tests:
- Given the user has entered the wrong password 4 times, when they enter the wrong password a 5th time, then the account is locked and the audit log records it.
Properties of good acceptance criteria
- Testable — a tester can verify pass/fail without judgment.
- Independent of implementation — describes outcomes, not how the code works.
- Bounded — covers the user story, not adjacent stories.
- Negotiable — written collaboratively, refined during refinement.
- Specific — "fast" is not testable; "responds in under 200 ms at p95" is.
Common mistakes
- Treating them as a wishlist — every "would be nice" gets added until the story is too big to fit a sprint.
- Adding them after development starts — re-scopes mid-sprint.
- Writing them in implementation language — couples the story to a single technical approach.
- Confusing them with the definition of done — acceptance criteria are story-specific; the definition of done applies to all stories.