# Acceptance Criterion

**In short:** An acceptance criterion is a condition a user story must meet before the product owner accepts it as complete. Each criterion belongs to one story, and clear ones can feed test cases.

## 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

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

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

- 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

- [User Story](https://arc.fuet.ch/concepts/functional-requirements/user-story.md)
- [Card, Conversation, Confirmation](https://arc.fuet.ch/concepts/functional-requirements/card-conversation-confirmation.md)
- [INVEST Criteria](https://arc.fuet.ch/concepts/functional-requirements/invest-criteria.md)
- [Frequent Mistakes in Defining Acceptance Criteria](https://arc.fuet.ch/concepts/functional-requirements/frequent-mistakes-in-defining-acceptance-criteria.md)
- [Story Splitting](https://arc.fuet.ch/concepts/functional-requirements/story-splitting.md)
- [Working with Functional Requirements (method phase)](https://arc.fuet.ch/concepts/functional-requirements/method-phase-working-with-functional-requirements.md)
- [Testability](https://arc.fuet.ch/concepts/quality-attributes/testability.md)
- [Epic](https://arc.fuet.ch/concepts/functional-requirements/epic.md)

## Sources

- [Relationship between Definition of Done and Conditions of Satisfaction - Mountain Goat Software](https://www.mountaingoatsoftware.com/agile/clarifying-the-relationship-between-definition-of-done-and-conditions-of-sa) — mountaingoatsoftware.com, accessed 2026-11-09
- [The Two Ways to Add Detail to User Stories - Mountain Goat Software](https://www.mountaingoatsoftware.com/agile/the-two-ways-to-add-detail-to-user-stories) — mountaingoatsoftware.com, accessed 2026-11-09
- [Given When Then](https://martinfowler.com/bliki/GivenWhenThen.html) — martinfowler.com, accessed 2026-11-09