Acceptance Criteria
Acceptance criteria are the testable conditions a story must satisfy to be accepted, aligning product intent, implementation, and verification before work begins.
Definition
Acceptance criteria describe the observable conditions under which a product increment is considered complete and acceptable to its stakeholders.
Context and scope
Written during backlog refinement and used to drive acceptance tests, demos, and sign-off for stories, features, and releases.
Common misconceptions
- Acceptance criteria are the same as the definition of done
- More criteria always produce a clearer requirement
- Criteria may stay vague as long as the team shares an understanding
Anti-patterns
- Writing implementation steps instead of observable behavior
- Adding criteria after development to match whatever was built
- Producing criteria that neither a person nor an automated check can verify
Related concepts
Authoritative source
https://www.atlassian.com/work-management/project-management/acceptance-criteria
What they are
Acceptance criteria state the observable conditions that make a story acceptable. They are written before implementation, agreed by product and engineering, and used afterward to decide whether the increment is done. A useful criterion is specific, testable, and phrased in terms of behavior a user or system can observe, not internal steps the team intends to take.
Formats that work
Given-When-Then works well for rule-driven behavior: given an account with insufficient funds, when a transfer is requested, then the request is rejected and the balance is unchanged. Checklists suit broader stories with several independent conditions. Examples with concrete values often communicate more than abstract rules. Whatever the format, each criterion should map to at least one automated or manual check.
Criteria versus definition of done
The definition of done is a standing quality bar for every increment: reviewed, tested, documented, deployed. Acceptance criteria are specific to one story. Confusing the two produces either generic criteria that verify nothing or a definition of done that changes per ticket. Keep the shared bar global and the criteria local.
Common failure modes
Criteria that describe implementation (“add a Redis cache”) constrain solutions without stating the outcome. Criteria written after the code merely document what exists. Vague adjectives such as “fast” or “user-friendly” cannot be verified. Missing negative cases are frequent: what happens on invalid input, timeout, or duplicate submission is often the part that breaks.
Beyond the ticket
Acceptance criteria are not a complete test strategy. Exploratory testing finds problems no one thought to write down, and regression suites protect behavior across releases. Use criteria to define the target, then probe around it. For example, a checkout story can pass every criterion while failing under a retried payment.