Skip to content

SOP-069 — Write & accept acceptance criteria (the product definition of done)

Guide

<!-- last-reviewed: 2026-06-01 · owner: Product (Product Manager) -->

SOP-069 — Write & accept acceptance criteria (the product definition of done)

SOP · owner: Product (Product Manager). Layer: SOP/Runbook (docs/canon.md). Defines the product feature “definition of done” — distinct from the document DoD (SOP-002). No story enters an Engineering sprint without acceptance criteria signed off here. Links to canon; does not restate it.

Interface Contract

  • Inputs: draft user story ← from self (SOP-068) · trigger: draft complete
  • Inputs: research findings ← from <Design Research Director> · trigger: research findings issued
  • Inputs: four-test verdict ← from <Quality & Risk> · trigger: review passed
  • Outputs: acceptance-criteria-complete story → to Engineering Director · trigger: story set accepted
  • Outputs: acceptance criteria for independent review → to Quality & Risk · trigger: review requested
  • Handoff trigger (in): a user story is drafted (SOP-068 step 3) and needs acceptance criteria before it can enter a sprint
  • Handoff trigger (out): the story’s acceptance criteria are complete and testable — the story is now sprint-eligible and joins the story set handed to Engineering
  • Definition of Done before handoff:
    • [ ] criteria cover the happy path
    • [ ] criteria cover the primary edge cases
    • [ ] criteria state the explicit non-goals (what this story does NOT include)
    • [ ] each criterion is testable — Engineering can judge pass/fail without a judgment call
    • [ ] no technical approach is prescribed (Engineering owns how)
    • [ ] criteria trace to the story’s source (provenance carried from SOP-068)
    • [ ] where evidence is insufficient to define “done”, the gap is flagged to Design Research, not guessed
    • [ ] learnings captured to docs/knowledge/ if any (SOP-024)

Trigger status: research findings issued, story set accepted, and draft complete are now registered (docs/handoff-triggers.md, Wave-2 block); review requested / review passed already existed. The story set accepted → Engineering Director edge is absorbed by the Director’s story set accepted fan-in sink (SOP-054, §3.1 R1); the Design-Research and Quality & Risk edges are pending (those roles are not Interface-Contract identities here — §3.1.1 R3).

Purpose

Turn a user story into something Engineering can build and objectively call done. Acceptance criteria are the contract: they remove judgment calls from “is this finished?” so the Engineering Director never has to guess intent.

When to use

  • Immediately after a user story is drafted (SOP-068 step 3) — before it can be RICE scored into a sprint-eligible state.
  • When new research findings (research findings issued) change what “done” means for an existing story.

Flow

flowchart LR
  A["Draft story<br/>(from SOP-068)"] --> B["Write happy-path<br/>Given/When/Then"]
  B --> C["Write primary<br/>edge cases"]
  C --> D["State explicit<br/>non-goals"]
  D --> E{"Enough evidence<br/>to define 'done'?"}
  E -->|no| F["Flag gap to<br/>Design Research"]
  E -->|yes| G["Self-check vs<br/>quality bar"]
  G --> H["Story sprint-eligible<br/>→ story set (SOP-068)"]
  classDef s fill:#1d4ed8,color:#fff,stroke:#1e3a8a
  classDef d fill:#0f766e,color:#fff,stroke:#134e4a
  class A,B,C,D,F,G,H s
  class E d

Text fallback: take the drafted story → write happy-path criteria in Given / When / Then → write the primary edge cases → state the explicit non-goals → check there is enough evidence to define “done”; if not, flag the gap to Design Research (do not guess) → self-check against the quality bar → the story is sprint-eligible and joins the story set (SOP-068).

Steps

  1. Anchor to the story. Restate the As a… I want… so that… so the criteria are judged against the intended benefit, not a drifted one.
  2. Happy path. Write Given <context>, When <action>, Then <observable outcome> for the primary success scenario. Outcomes must be observable (a state, a rendered element, a recorded value) — not internal implementation.
  3. Primary edge cases. Enumerate the realistic failure / boundary scenarios the story must handle (empty state, missing input, unauthorised access, the broadcast/ fan-out case, etc.). One Given/When/Then each.
  4. Explicit non-goals. State what this story does not include — the scope fence that stops Engineering over-building and stops the story sprawling. “This story does not cover <X>; that is <other story / out of scope>.”
  5. Testability check. For each criterion ask: could Engineering judge pass/fail without asking me? If no, rewrite until yes. Vague criteria (“works well”, “is fast”) are defects — give the observable condition or the number.
  6. Implementation-agnostic check. Strip any how. “Renders within 200ms” is a what (acceptable as a measurable outcome); “uses a Redis cache” is a how (delete — Engineering’s call). A prescribed technical approach is a defect.
  7. Evidence check. If you cannot define “done” because the research evidence is insufficient (e.g. no usability finding on the threshold), flag it to Design Research (research findings issued is the inbound trigger) rather than invent a criterion.
  8. Optional independent review. For high-stakes stories, hand the criteria to Quality & Risk (review requested) for the four-test sample; incorporate review passed feedback.
  9. Mark sprint-eligible. The story now carries complete criteria and rejoins the backlog (SOP-068) for RICE scoring and sprint assembly.

Acceptance-criteria block format (lives with the story in docs/product/backlog.md)

Story: As a <user>, I want <what>, so that <why>.
Source: <concept brief / research finding / Principal directive>
Acceptance criteria:
  Happy path:
    - Given <…>, When <…>, Then <observable outcome>.
  Edge cases:
    - Given <…>, When <…>, Then <observable outcome>.
  Non-goals:
    - This story does NOT include <…>.

Roles / approvers

  • Product Manager — sole author and acceptor of acceptance criteria.
  • Design Research Director — supplies the evidence that defines “done”; receives flagged gaps where evidence is insufficient.
  • Engineering Director — the consumer; judges done/not-done against the criteria; raises ambiguity back as an implementation risk.
  • Quality & Risk — optional independent four-test review for high-stakes stories.

Guardrails

  • No story leaves without criteria — this SOP is the gate (charter rule 1).
  • No technical approach in criteria — Engineering owns how (boundary 1).
  • No guessing “done” — insufficient evidence is flagged to Design Research, not filled with an invented criterion (charter rule 2).
  • Observable outcomes only — a criterion a stranger cannot test is a defect (master-plan §1.3 test 1).
  • Personal information is PA-only.

See also: docs/units/product/charter.md (quality bar) · SOP-068 (backlog) · SOP-070 (roadmap) · docs/sop/change-management.md (SOP-002 — the document DoD this is distinct from) · interface-contract-spec.md · docs/handoff-triggers.md.