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.