Acceptance Criteria

Acceptance criteria are the specific, testable conditions a user story, feature or other deliverable must meet to be accepted as complete and correct. They describe expected behavior from the user's or stakeholder's point of view, including important edge cases and exact messages, so product, design, engineering and QA share one definition of "working".

How Acceptance Criteria Work

The BABOK Guide defines acceptance criteria as the criteria associated with requirements, products or the delivery cycle that must be met to achieve stakeholder acceptance. Mike Cohn calls them conditions of satisfaction. In Ron Jeffries' card, conversation and confirmation model of a user story, they are the confirmation: how the customer will know the work is done.

Two formats are common:

• Rule-oriented: a checklist of statements, such as "Passwords must contain at least 12 characters."
• Scenario-oriented: the Given/When/Then structure from behavior-driven development (BDD), introduced by Dan North. Given some context, when an event occurs, then certain outcomes follow. North put it simply: a story's behavior is its acceptance criteria.

Criteria are written during backlog refinement, before development starts, and agreed between the product owner and the team. They then become the basis for test cases, many of them automated.

Good criteria are pass or fail, describe outcomes rather than implementation, and cover the main path plus the edge cases that matter. If a criterion cannot be verified, it is not a criterion yet.

Why Acceptance Criteria Matter

Acceptance criteria remove ambiguity at the point where it is most expensive. Without them, a story can be "done" by the developer's reading and wrong by the product manager's. They also set the boundary of a story, which limits scope creep within a sprint, and they give testers a ready-made starting point.

For AI coding agents, criteria act as the check the output must pass. An agent given clear Given/When/Then scenarios can write tests first and verify its own work against them. For how criteria fit into well-formed tickets, see how to turn OKRs into sprint-ready tickets with clear acceptance criteria.

Acceptance Criteria Example

Story: "As a shopper, I want to apply a discount code at checkout, so that I pay the promoted price."

• Given a valid code, when I apply it, then the order total drops by the discount and the code appears on a discount line.
• Given an expired code, when I apply it, then I see "This code has expired" and the total does not change.
• Given a code is already applied, when I apply a second code, then the second code replaces the first.

The third criterion records a product decision that would otherwise be left to whoever writes the code.

Acceptance Criteria vs. Definition of Done

A story is complete only when it meets both its own acceptance criteria and the team's Definition of Done.