The Software Wiki

Acceptance criteria

Properties2
tagsprocess, artifact
aliasesAC, Conditions of satisfaction, Acceptance conditions

3 min read

Acceptance criteria

By Allen Jay Bercero

Acceptance criteria (AC) are the specific, testable conditions a User story (or feature) must satisfy for the customer or Product Owner to accept it as done. They turn a deliberately short story into an unambiguous, checkable agreement: if these conditions pass, everyone agrees the story is finished.

Acceptance criteria are where “done” stops being a matter of opinion. Written before development and agreed by the whole team, they state exactly what the feature must do, so nobody discovers a disagreement at demo time.

Also known as

AC · conditions of satisfaction · acceptance conditions

Don't confuse with

  • Definition of Done (DoD): acceptance criteria are per story (does this feature meet what was asked?); the Definition of Done is team-wide (is any work releasable: tested, reviewed, documented?). A story can pass its acceptance criteria and still not be “done” if it fails the DoD.
  • Acceptance tests: the criteria are the conditions; acceptance tests are the checks (often automated) that verify them. ATDD and BDD are about turning acceptance criteria into automated acceptance tests.
  • The requirement itself: a requirement says what to build; acceptance criteria pin down precisely how you will know it was built correctly.

How to write them: two common formats

1. Scenario style (Given / When / Then). Best for behavior and flows; it reads as plain English and maps directly to BDD.

Example

Given I have items in my cart, when I apply a valid coupon, then the order total drops by the coupon amount. Given an expired coupon, when I apply it, then I see “This coupon has expired” and the total is unchanged.

2. Rule / checklist style. Best for a set of discrete conditions or constraints: a simple list of pass/fail rules.

Example

For “reset my password”:

  • A reset link is emailed within one minute of the request.
  • The link expires after 24 hours.
  • The new password must meet the password policy.
  • A previously used password is rejected.

Pick whichever makes the story clearest; many teams mix both.

What makes them good

  • Testable: each criterion is unambiguously pass or fail.
  • From the user’s perspective: they describe what, not how (no implementation detail).
  • Cover the edges: the happy path and the negative or error cases (expired coupon, bad input).
  • Agreed up front: written and discussed before the story is built, not reverse-engineered after.
  • Concise: enough to remove ambiguity, not a full specification.

Where they fit

Acceptance criteria are attached to a User story in the Product backlog and are usually fleshed out during Backlog refinement, often in a “three amigos” conversation (business, developer, tester). They become the basis for acceptance testing, and in ATDD and BDD they are written as executable tests before coding begins.

See also

References

Graph View

Backlinks