defining-done-and-acceptance-criteria

Defining Done and Acceptance Criteria

Two different tools solve two different problems. Confusing them is the single most common cause of "done" meaning different things to different people on the same team.

• Definition of Done (DoD) — one checklist, owned by the whole Scrum team, applied to every Product Backlog Item and Increment. It answers "is this shippable, full stop" (code reviewed, tests passing, deployed to staging, docs updated, no known regressions). It rarely mentions the feature itself.
• Acceptance Criteria (AC) — specific to one story, written during refinement, before or as work starts. It answers "does this particular story do the thing the user needs" (e.g. "search returns results in under 500ms for a 3-word query"). It says nothing about code review or deployment — that's the DoD's job.

A story can satisfy its acceptance criteria and still not be Done (it wasn't code-reviewed). A story can pass every DoD checklist item and still be wrong (it was reviewed, tested, and deployed — against the wrong requirement). Both checks are required; neither substitutes for the other.

Procedure: writing acceptance criteria for a story

1. Restate the story as a user need, not a task list. If the story reads like a technical to-do ("add Redis cache to search endpoint"), push back and ask what observable behavior changes for the user — AC are written against behavior, not implementation.
2. Apply INVEST to the story first (Bill Wake's heuristic for a good user story — AC quality is capped by story quality):
   • Independent — can be built and shipped without waiting on another unfinished story. If AC keep referencing "after story X is done," the stories should probably be split differently or merged.
   • Negotiable — a placeholder for a conversation, not a frozen spec. If the AC already dictate the database schema or the exact button copy, the story has quietly become a technical spec, not a story.
   • Valuable — delivers something a user or the business actually cares about, not just a technical stepping stone. "Refactor the auth module" has no user-facing AC because it isn't a user story.
   • Estimable — the team can size it. If AC are so vague the team can't agree on small/medium/large, the story needs more detail or a spike first.
   • Small — fits in a sprint, ideally a few days. If AC run past 5-6 Given/When/Then blocks, the story is probably two stories.
   • Testable — every AC has an observable pass/fail. If an AC can't be checked by a test or a manual QA step, rewrite it or cut it.
3. Write each criterion as Given/When/Then (Gherkin-style, from Dan North's Behavior-Driven Development): Given the starting state, When the user or system does something, Then the observable outcome. This format forces precondition, action, and expected result to be separated instead of blurred into one vague sentence.

   Given a logged-in user with 0 saved searches
   When they submit a search query of 3+ characters
   Then results appear within 500ms
   And a "no results" state is shown if nothing matches
   

4. Write the negative and edge cases explicitly, not just the happy path. "Search returns results" has no AC for empty query, query with only special characters, or the backend timing out — each of those is a separate Given/When/Then, and each is where bugs actually hide.
5. Read every criterion back and ask "could two people disagree on pass/fail after reading this?" If yes, it's not actually testable — replace subjective language ("fast", "intuitive", "handles errors gracefully") with a number, a specific error message, or a named state.
6. Check the criteria don't smuggle in implementation. "Then a Redis cache entry is created" is an implementation detail masquerading as an acceptance criterion — nobody outside engineering can verify it, and it locks in a technical approach the team may want to change later. Rewrite as the user-observable effect: "Then the second identical search returns in under 50ms."