Acceptance Criteria

Why they settle arguments before they happen

Most disputes about whether something is finished are really disputes about what finished meant, discovered at the point where it is most expensive to resolve. Acceptance criteria move that conversation to the beginning, when changing the answer costs a sentence rather than a sprint.

Two formats worth knowing

Both work. Which one fits depends on whether the behaviour is conditional.

Checklist

A list of statements that must all be true: "the export includes archived records", "a failed export shows the reason". Best for straightforward behaviour.

Given / when / then

One scenario per criterion: given some state, when something happens, then something is true. Best where behaviour depends on context, and it maps directly onto automated tests.

What makes them useless

Criteria fail in predictable ways, and all of them are recognisable on sight.

Unmeasurable

"The page loads quickly" cannot be checked. "The page renders within 500ms at the 95th percentile" can.

Restating the title

A criterion that repeats the story in different words adds nothing and hides the absence of thought.

Describing implementation

"Use a cursor-paginated query" is a design decision, not a condition of acceptance. It removes the engineer's judgement without adding certainty.

Missing the failure cases

Most of the cost of a feature is in what happens when things go wrong. Criteria that only describe the happy path guarantee a second round.

Acceptance criteria versus definition of done

Acceptance criteria are specific to one story. A definition of done applies to every story - tests written, reviewed, documented, deployed. A story needs both: its own criteria, and the team's standing bar.