Acceptance Criterion
Explanation
Section titled “Explanation”A user story (see User Story) is a short description of something a user needs. Acceptance criteria say when that story counts as complete and accepted. Some people use the term “conditions of satisfaction” for nearly the same thing.
Story-level, not team-wide. Criteria belong to one backlog item. The Definition of Done is different. It is an agreed list of things that must be true before any item counts as complete. The developers create that list. The product owner supplies the high-level criteria for a single story.
Where they lead. Quality assurance (QA) can turn the product owner’s high-level criteria into more detailed test cases. This is how criteria feed testing.
When they appear. Detail, including criteria, is added as a story moves toward the top of the backlog. If the story is too large, split it (see Story Splitting).
Format. Given-When-Then is one style for writing them. It describes system behavior as tests, using examples. It was developed within Behavior-Driven Development (BDD). Each criterion then reads as a small example that anyone can check.
A note on naming. One well-known author finds the term “acceptance criteria” confusing and prefers “conditions of satisfaction”. Both names point to nearly the same idea.
Example
Section titled “Example”Story: “As a shopper, I want to reset my password so that I can regain access.”
Criteria written as Given-When-Then:
- Given a registered shopper, when they request a reset, then a reset message goes to their address.
- Given an unknown address, when someone requests a reset, then no message goes out.
The Definition of Done is separate. It might say that every item must be reviewed and tested. It applies to all stories, not just this one.
Trade-offs
Section titled “Trade-offs”Naming varies between teams. “Acceptance criteria” and “conditions of satisfaction” are used almost interchangeably, so a team should agree on one term. Criteria also differ from the Definition of Done: mixing the two blurs what is specific to one story and what applies to all.
Checks
Section titled “Checks”- Each user story lists its own acceptance criteria, separate from the team-wide Definition of Done.
- The product owner supplied or confirmed the high-level criteria for each story.
- Criteria can be turned into detailed test cases.
Related
Section titled “Related”- User Story
- Card, Conversation, Confirmation
- INVEST Criteria
- Frequent Mistakes in Defining Acceptance Criteria
- Story Splitting
- Working with Functional Requirements (method phase)
- Testability
- Epic
Sources
Section titled “Sources”- Relationship between Definition of Done and Conditions of Satisfaction - Mountain Goat Software — mountaingoatsoftware.com, accessed 2026-11-09
- The Two Ways to Add Detail to User Stories - Mountain Goat Software — mountaingoatsoftware.com, accessed 2026-11-09
- Given When Then — martinfowler.com, accessed 2026-11-09