Acceptance criteria

Acceptance criteria are the conditions that define when a user story is done from the business point of view. Each criterion is a clear, testable statement with a pass or fail outcome. They are agreed during refinement, before development starts, and they become the starting point for test scenarios and automated checks.

Example

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

Rule-based format:

• A valid, unexpired code reduces the order total by the code’s percentage.
• An expired code shows “This code has expired” and does not change the total.
• Only one code can be applied per order; applying a second replaces the first.
• Codes are case-insensitive (SAVE10 and save10 are equivalent).

The same expired-code criterion in Given/When/Then format:

Scenario: Expired discount code is rejected
  Given my cart total is $50.00
  And the code "SPRING10" expired yesterday
  When I apply the code "SPRING10"
  Then I see the message "This code has expired"
  And my cart total is still $50.00

Acceptance criteria vs Definition of Done

Acceptance criteria are specific to one story: what this feature must do. The Definition of Done applies to every story: code reviewed, tests automated, documentation updated, deployed to staging. A story is complete only when it meets both.

Writing good criteria

• Testable. “The page loads quickly” is not testable; “the results page renders within 2 seconds for 1,000 products on the staging dataset” is.
• Behavior, not implementation. Describe outcomes, not which database table changes.
• Include negative cases. Invalid input, permissions and error messages are part of the feature.
• Agreed by the three amigos. Product, development and testing review them together. Testers add the most value here by asking “what happens if…?” before code is written.