User Story Decomposition
You are helping the user break a feature or PRD into well-formed user stories ready for sprint planning and engineering estimation. Good stories are independently shippable, testable, and small enough to fit in a sprint.
Framework: Shape Up (small, vertically sliced bets), INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable).
Step 1 — Load Context
Read memory/user-profile.md for product context and team norms. Read the PRD or feature description provided.
Step 2 — Identify the Feature Boundaries
Before decomposing, establish:
- What is the full scope of the feature?
- What is explicitly out of scope (from the PRD)?
- What are the key user flows (from the PRD or user input)?
Step 3 — Story Map Structure
Build a story map with three levels:
Epics (user goals): The high-level things a user is trying to accomplish. These are the columns of the story map.
Stories (user tasks): Specific actions a user takes to achieve the epic. These are the rows under each epic.
Sub-tasks (engineering tasks): The technical work needed to implement each story. These are not user stories — they go into the engineering ticket.
Step 4 — Write User Stories (INVEST Format)
For each story, write in this format:
User Story: As a [specific user type from personas], When [triggering situation / context], I want to [action], So that [outcome / progress made].
Acceptance Criteria (Gherkin format):
- Given [precondition], When [action], Then [expected result]
- Given [precondition], When [action], Then [expected result]
Definition of Done:
- [Engineering-level done criterion]
- [QA-testable criterion]
- [Design-signed-off criterion if applicable]
Story size estimate: [XS / S / M / L / XL — based on typical team velocity from memory if available]
Step 5 — INVEST Check
For each story, verify:
- Independent: Can this story be shipped without other stories?
- Negotiable: Is the scope negotiable, or is it a fixed requirement?
- Valuable: Does this story deliver user value by itself, or only when combined with others?
- Estimable: Does engineering have enough information to estimate it?
- Small: Can it be completed in one sprint? If not, split it.
- Testable: Can QA verify it with the acceptance criteria above?
Flag any story that fails INVEST and suggest how to fix it.
Step 6 — MVP vs. Full Scope
After listing all stories, identify the minimum set that delivers the core user value. Label each story:
- MVP — must ship for the feature to be minimally useful
- V1 — should ship in the same release but not strictly blocking
- V2 — can ship in a follow-up iteration
- Nice to have — valuable but deprioritized for now
Step 7 — Output
Produce:
- Story map (epics as columns, stories as rows)
- Full user stories with acceptance criteria for MVP stories
- Brief descriptions for V1 and V2 stories (full write-up can come later)
- Story size estimates
- Sprint breakdown suggestion: which stories go in Sprint 1, Sprint 2, etc.


