User Story and Acceptance Criteria
Parent: Code Plan Writing · researched 2026-05-29T18:28:41.360Z· 10 sources · 10 concepts · skill user-story-and-acceptance-criteria
This skill takes a feature idea and produces backlog items the team can groom, estimate, and ship. Covers Mike Cohn's user-story template, the INVEST quality bar (Bill Wake, 2003), Given/When/Then acc
Overview
- This skill takes a feature idea and produces backlog items the team can groom, estimate, and ship. Covers Mike Cohn's user-story template, the INVEST quality bar (Bill Wake, 2003), Given/When/Then acceptance criteria in Gherkin form, splitting strategies (vertical-slice principle and SPIDR), and the separation between acceptance criteria (per-story, varies) and definition of done (team-wide, stable). [source]
1. The Mike Cohn user-story template
- As a <role> - the user, not the system. "As a user" is the most common failure mode. Name a specific actor type: "As a job seeker", "As an on-call TAM", "As a paid subscriber on the Pro tier." [source]
- I want <capability> - the what, written goal-first, agnostic to how. [source]
- so that <benefit> - the why. The benefit clause is the most-skipped and most-valuable. [source]
2. INVEST — the quality bar
- I - Independent. The story can be built, demoed, and shipped without waiting on another story. [source]
- N - Negotiable. The story is a placeholder for a conversation, not a contract. [source]
- V - Valuable. The story delivers value to a real user or stakeholder. [source]
- E - Estimable. The team has enough context to size it. [source]
- S - Small. Fits comfortably inside an iteration. Heuristic: ≤ 50% of one developer's iteration capacity. [source]
- T - Testable. A definite test exists for "done." [source]
3. Given / When / Then — Gherkin acceptance criteria
4. The vertical slice rule
- A user story must be a thin vertical slice through the architecture - a sliver that touches every layer and delivers end-to-end value. [source]
- Horizontal (wrong): [source]
- Story 1: Build the UI for case filtering. [source]
- Story 2: Build the API endpoint for case filtering. [source]
- Story 3: Add the database index for case filtering. [source]
- Vertical (right): [source]
- Story 1: Filter cases by severity (S1 only, no UI persistence). [source]
- Story 2: Filter cases by status, with severity already shipped. [source]
5. SPIDR — five ways to split a story
- S - Spike. Time-box a research task to remove uncertainty blocking estimation. [source]
- P - Path. Split by user path. "Pay with credit card" / "Pay with Apple Pay." [source]
- I - Interface. Split by client or platform. "Filter cases on desktop" / "Filter cases in mobile app." [source]
- D - Data. Split by data scope. "Filter cases for active accounts only" first; "including archived accounts" later. [source]
- R - Rules. Relax business rules in the first slice. "Refunds, with no approval workflow" first; "Refunds with manager-approval workflow" later. [source]
6. Acceptance criteria vs Definition of Done
- Acceptance Criteria (AC): [source]
- Specific to this story. [source]
- Authored by the product owner with the team. [source]
- Vary between stories. [source]
- Answer: "What must this story do for the user to accept it?" [source]
- Definition of Done (DoD): [source]
- A team-wide standard that applies to every story. [source]
- Stable across sprints. [source]
- Answers: "What must any item meet to be called done?" [source]
- A story is done when both its acceptance criteria are met and the team's definition of done is satisfied. [source]
Anti-Patterns
- "As a user, I want..." - every story starts the same way, tells you nothing. [source]
- Solution-shaped capability clauses - "I want a dropdown in the top-right corner." [source]
- No so that clause - strips out the prioritization signal. [source]
- Horizontal-layer stories ("Build the backend for X") - each is independently unshippable. [source]
- Acceptance criteria that restate the story. [source]
- 20-criterion acceptance lists - the story is too big. Split. [source]
- Conflating Acceptance Criteria with Definition of Done. [source]
- Forcing bugs / tech-debt / spikes into user-story syntax. [source]
Decision Heuristics
- "As a user" or a specific role? Always specific. [source]
- Story or epic? If the story has > 1 sprint of work or > 5 acceptance criteria, it's an epic. Split via SPIDR. [source]
- Gherkin or checklist for AC? Gherkin when multi-step interactions or branching. Checklist when criteria are independent observable facts. [source]
- Put it in AC or in DoD? Specific to this story → AC. Applies to every story → DoD. [source]
References
- Mike Cohn, "User Stories and User Story Examples" - Mountain Goat Software [source]
- Bill Wake, "INVEST in Good Stories, and SMART Tasks" - XP magazine, 2003 [source]
- Mike Cohn, "SPIDR: Five Simple but Powerful Ways to Split User Stories" [source]
- Cucumber, "Gherkin Reference" - https://cucumber.io/docs/gherkin/reference/ [source]
- Scrum.org, "Definition of Done vs Acceptance Criteria" [source]
Children
- Mike Cohn As-a/I-want/so-that template (frontier)
- INVEST principles (Bill Wake 2003) (frontier)
- Given/When/Then Gherkin acceptance criteria (frontier)
- Vertical-slice rule (frontier)
- SPIDR story splitting (Spike/Path/Interface/Data/Rules) (frontier)
- Acceptance Criteria vs Definition of Done (frontier)
- Ron Jeffries 3 C's (Card/Conversation/Confirmation) (frontier)
- Story sizing (Fibonacci/t-shirt/no-estimates) (frontier)
- Roles vs personas (frontier)
- Anti-stories (bugs/spikes/tech-debt) (frontier)
Frontier under this node: Acceptance Criteria vs Definition of Done, Anti-stories (bugs/spikes/tech-debt), Given/When/Then Gherkin acceptance criteria, INVEST principles (Bill Wake 2003), Mike Cohn As-a/I-want/so-that template, Roles vs personas, Ron Jeffries 3 C's (Card/Conversation/Confirmation), SPIDR story splitting (Spike/Path/Interface/Data/Rules), Story sizing (Fibonacci/t-shirt/no-estimates), Vertical-slice rule