A user story is a short, user-focused description of a need — "As a [role], I want [goal] so that [benefit]" — and, crucially, not a specification. Ron Jeffries' Three C's made the point structural Jeffries, 2001: the Card is a deliberately incomplete placeholder, the Conversation uncovers the hidden assumptions, and the Confirmation turns shared understanding into testable acceptance criteria. The card was never the point. The conversation was.
§1INVEST, and its internal tension
Bill Wake's INVEST checklist Wake, 2003 remains the quality gate: a good story is Independent, Negotiable, Valuable, Estimable, Small, and Testable. Layer-sliced "API story / UI story" pairs fail Independent. "As a developer…" tasks fail Valuable. "Easy to use" fails Testable; "loads in under two seconds" passes.
The checklist hides a real tension: shrinking a story by stripping architectural layers destroys its independence and value. The skill is finding a seam that keeps the slice vertical. Matt Riley's reading of the letters is worth keeping: Small and Valuable are the two that matter most — and the two hardest to achieve at once Riley, Jun 2020.
§2Semantic diffusion and the epic problem
Agile vocabulary eroded through what Martin Fowler called semantic diffusion — terms outliving their meaning. The sharpest case is the epic. In Mike Cohn's original usage an epic was simply a story discovered to be too big through sizing. Tool-driven practice turned it into a permanent container: "Phase 1", "Infrastructure". Riley's article traces what follows Riley, Jun 2020: container-epics invite decomposition by architectural layer, layer tasks deliver no independent value, and the team lands in a hidden waterfall — every story "Done", nothing releasable.
Riley's "epic confusion" piece is a 2025/2026 response to the agent
era. It was published by Thoughtworks on June 11, 2020 — years before coding
agents. The confusion it names is a tooling-and-habit problem that AI inherited, not one
it created.
| Aspect | Horizontal slicing | Vertical slicing |
|---|---|---|
| Focus | Architectural layer | Customer value |
| Dependencies | High | Low |
| Feedback | Slow, end-loaded | Fast, immediate |
| Releasability | Only after all layers merge | Potentially each story |
Direction matters as much as size. Top-down — epic broken into layer tasks — yields dependency hell. Bottom-up — small vertical stories, optionally grouped under a label — preserves value. And when epics exist mainly for reporting or tool defaults, the team is serving the tool, not the product.
§3Splitting, mapping, and the job story
The splitting techniques are a settled toolkit. Mike Cohn's SPIDR mnemonic: split out Spikes when risk blocks estimation, deliver happy Paths first, simple Interfaces before enhancements, one Data subset per story, and layer business Rules on afterwards Cohn. Gojko Adzic's Hamburger Method takes the simplest working option from each technical layer as the first story Adzic; Alistair Cockburn's Elephant Carpaccio pushes slices thin enough to build in minutes Cockburn. Always along value lines — "User Management" splits into Sign Up, Log In, Forgot Password, never into front-end and back-end.
Jeff Patton's story mapping restores the context a flat backlog strips: user activities form the chronological backbone (these are the true epics), stories hang beneath, and horizontal slices across the map become releases Patton. Alan Klement's job stories — "When [situation], I want [motivation], so that [outcome]" — swap persona for triggering context, useful where the situation matters more than the role Klement.
§4Acceptance criteria
Acceptance criteria are the story-level definition of done — each criterion binary, observable, and about what, not how: "email sent on password change", not "configure SMTP". Three formats now coexist. Checklists are fast and readable. Gherkin's Given/When/Then is testable and automatable, at the price of verbosity. And EARS — Easy Approach to Requirements Syntax, five sentence patterns of the form "WHEN [condition] THE SYSTEM SHALL [behavior]" — migrated from aerospace into the agent toolchain; AWS Kiro generates acceptance criteria in EARS by default Augment Code survey, 2026. Criteria written after coding are documentation, not requirements.
§5Why this matters more in 2026
The baseline matters here because the agent era stress-tests it hardest. Tightly scoped, vertically sliced work is where coding agents perform best, so the pressure toward Small and Testable intensifies rather than relaxes. Meanwhile a specific antipattern is creeping back in through the new tooling: several 2026 "let the AI split your story" guides cheerfully propose backend / frontend / database splits — precisely the horizontal slicing Riley and Cohn spent years warning against 2026 splitting guides, synthesis. An agent proposing a split is not evidence the split is vertical. The seam stays a human judgment.
Riley's closing line has aged into a design principle for the whole agent era: make it easy to write good stories and hard to write poor ones. Essay 03 takes up what happens when the reader of the story stops being human.
§6Sources
- Matt Riley — User stories: a tale of epic confusion, Thoughtworks (Jun 11, 2020).
- Bill Wake — INVEST (2003); Ron Jeffries — Three C's (2001).
- Mike Cohn — SPIDR, epic origin, backlog bankruptcy; Gojko Adzic — Hamburger Method; Alistair Cockburn — Elephant Carpaccio; Jeff Patton — story mapping; Alan Klement — job stories (JTBD).
- EARS in agent tooling — Augment Code SDD tool survey (2026).