In 30 seconds
- Acceptance criteria define "done" for one specific story.
- Written as clear, testable statements, often Given-When-Then.
- Agreed before development, not discovered at demo time.
What they do
A user story says who wants what and why. Acceptance criteria say exactly how everyone will know it works. They turn a conversation into something testable.
Two common formats
Checklist:
- User can reset password from the login page.
- Reset link expires after 24 hours.
- Old password stops working after reset.
Given-When-Then:
- Given a registered user, when they request a reset, then they receive an email with a link.
Acceptance criteria vs Definition of Done
| Acceptance criteria | Definition of Done | |
|---|---|---|
| Applies to | One story | Every item |
| Describes | What this feature must do | Quality bar for all work |
| Example | Reset link expires in 24h | Code reviewed, tests pass |
See Definition of Done.
Myth vs reality
Myth · The Product Owner writes them alone.
Reality · They're best written together during refinement.
Myth · More criteria means better stories.
Reality · More than about seven often means the story should be split.
Myth · They describe how to build it.
Reality · They describe what must be true, not the implementation.
The AI angle
When AI or agents build the work, acceptance criteria become instructions as much as checks. Make them precise and executable, ideally as tests written before the code.
FAQ
When should acceptance criteria be written?
During Backlog Refinement, before the story enters a sprint.
Who checks them?
The team tests against them; the Product Owner confirms at or before the Sprint Review.
Can they change mid-sprint?
Only by agreement, and big changes usually mean a new story.