Acceptance criteria
Acceptance criteria are the conditions a software deliverable must satisfy to be accepted by its stakeholders – typically the product owner, customer, or end user on whose behalf the work was commissioned. They are derived from requirements, both functional and non-functional, and translate an abstract requirement into a set of concrete, checkable statements that a acceptance test can verify.
A set of acceptance criteria answers the question, "what would have to be true for us to consider this done?" They are usually written by the product owner or customer in collaboration with the development team, and are most commonly attached to a user story or use case as part of its definition of done – the shared checklist that distinguishes "finished" from "still in progress".
Qualities of good acceptance criteria
Well-written acceptance criteria share the qualities of good requirements generally. Each one should be:
- Testable. There is a clear procedure that yields a pass or fail result, with no room for subjective interpretation.
- Unambiguous. A reader cannot reasonably reach two different conclusions about what the criterion means.
- Atomic. Each criterion addresses one behavior or condition, so that a single test can exercise it in isolation.
- Independent. The criteria can be evaluated in any order, and one passing or failing does not skew the evaluation of another.
- Written from the user’s perspective. They describe an observable outcome of the system, not an implementation detail.
Consider the criterion "the checkout page must load quickly". "Quickly" has no threshold and "load" is undefined, so two testers could reach opposite verdicts on the same build. Rewriting it as "the checkout page must render its primary content within one second on a 3G connection at the 90th percentile" makes it measurable, names an observable outcome, and draws an objective pass/fail line.
A few pitfalls recur often enough to flag.
- Vague adjectives. Words like "fast", "intuitive", or "robust" carry no shared meaning. Replace them with a measurable threshold or an observable behavior.
- Disguised tasks. "Implement a caching layer" describes work, not an outcome. A criterion should state what the user observes, not what the team builds.
- Conflated behaviors. "The user can log in and view their dashboard" bundles two outcomes into one criterion, so a failure in either leaves the result ambiguous. Split them.
- Implementation coupling. Naming a particular API endpoint, UI widget, or database column freezes the criterion to one solution. Phrase it in terms of observable behavior so it survives a refactor.
Expressing acceptance criteria
Acceptance criteria are most useful when they are concrete enough to drive tests. A common lightweight form is a simple bulleted list of conditions, each phrased as a statement that is either true or false of the delivered system. For the user story "As a returning shopper, I want to save my payment details so that I check out faster", a reasonable set of criteria reads as follows.
- The payment form offers a "save card" checkbox.
- When the box is checked, the card details persist across sessions.
- Saved cards appear pre-selected on the next checkout.
- The user can delete a saved card from their account settings.
A more structured form expresses each criterion as a scenario, using Gherkin's Given/When/Then template. Each scenario states a starting context (Given), an action (When), and an expected outcome (Then). Scenarios written this way double as executable specifications in behavior-driven development (BDD) – they can be fed directly into a BDD framework, automating the acceptance testing that confirms the criteria are met.
Whatever the form, the value of acceptance criteria is that they make the boundary of a piece of work explicit and agreed-upon before the work is built, rather than negotiated after delivery. They give the team a shared, authoritative definition of when a story is complete.