user-stories

# User Stories Turn a fuzzy epic, spec, or feature into a backlog of small, testable, independently shippable user stories. Each story names a user, a capability, and an outcome, carries acceptance criteria a developer and tester can verify, and is sliced as a thin vertical end-to-end path — never a horizontal technical layer. Where a story is too big, split it with a proven pattern rather than guessing. **Grounded in:** *User Story Mapping* — Jeff Patton: vertical slices and story mapping, with INVEST and Given/When/Then. **Go deeper (The Product Channel):** [Guide to Product Requirements Documents](https://sidsaladi.substack.com/p/guide-to-product-requirements-documents) ## When to use this - An epic or spec is too large to estimate or build, and needs decomposing. - You're handed a PRD and need a ready-to-groom backlog out of it. - A single story keeps growing or hides several decisions and should be split. - A story exists but its acceptance criteria are vague, missing, or untestable. - Sprint planning needs stories small enough to fit a sprint with clear "done." ## Before you start (gather these) - The epic / spec / feature you're decomposing — the scope boundary. - The user or persona who benefits (and any distinct user types involved). - The outcome / goal: what changes for them when this ships. - If pointed at a PRD or doc, read it first and pull the above from it. - If scope, persona, or outcome is unclear, ask before slicing — don't invent them. ## Principles -...