"Done" means different things to a developer, a designer, and a stakeholder, and the gap between those meanings gets discovered at the worst possible time: review. Acceptance criteria close the gap in advance. A feature with clear acceptance criteria can fail before it is built, which is exactly when failing is cheap.
In this glossary topic:
What are acceptance criteria?
Acceptance criteria are the specific, testable conditions a feature must satisfy to count as complete. They are written per user story or requirement, agreed before development starts, and checked before work is accepted, by QA, by the product manager, or by an automated test.
Each criterion is binary: it passes or it fails. "The form should be easy to use" is a wish; "the form submits with valid input and shows a field-level error with invalid input" is a criterion.
What do good acceptance criteria look like?
Two formats dominate. Scenario format (given, when, then) describes behavior in context: given a logged-in user, when the session expires, then unsaved input is preserved. Checklist format lists conditions flatly, which suits simpler features. Format matters less than 3 properties: each criterion is testable, is written before the work starts, and describes the outcome rather than the implementation. A criterion that prescribes the how quietly takes a design decision away from the people meant to make it.
How do acceptance criteria differ from a definition of done?
Acceptance criteria are specific to one story: what this feature must do. The definition of done applies to every story: tested, reviewed, documented, deployed. A story can meet all its acceptance criteria and still not be done, and the reverse confusion, treating the definition of done as feature requirements, is how process checklists end up standing in for product thinking.
Why do acceptance criteria matter?
They move the argument to the cheap side of development. Vague requirements produce revision cycles where stakeholders feel the feature missed expectations nobody wrote down. Criteria agreed up front give engineers a testable target, give QA a script, and give stakeholders a moment to catch missing scope while it is still a sentence rather than a sprint. They also anchor scope: a mid-build request that fails no criterion is visibly new work, not a bug fix.
