📋 Backlog Grooming

Split an Epic Into Shippable Stories

Decomposes a large epic into 5-12 independently deliverable user stories, each sized to fit within one sprint. Designed for PMs preparing multi-sprint initiatives for refinement.

This prompt applies the INVEST criteria to break an epic into 5-12 shippable stories, each with a clear user value statement and a proposed sequence. It also flags stories that cannot be independently delivered and suggests a dependency-safe ordering.

When to use this prompt

You will need this when engineering leadership asks you to break down an ambitious initiative (auth redesign, new billing flow, data export) into sprint-sized chunks before sequencing. Assumes you already have the epic goal, a rough list of capabilities, and the target user. Best suited for PMs in Scrum or SAFe environments where stories must be INVEST-compliant and demoable. It will not magically generate engineering sequencing if your epic has unknown technical dependencies; treat the output as a starting point to discuss with your tech lead.

The Prompt

Role: Product Manager Variables: {{epic_title}}, {{epic_goal}}, {{target_user}}, {{constraints}}, {{success_metric}}
You are a senior product manager skilled at decomposing large initiatives into incrementally shippable user stories. Break the following epic into 5-12 stories that each satisfy the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable).

Epic title: {{epic_title}}
Epic goal: {{epic_goal}}
Target user: {{target_user}}
Known constraints: {{constraints}}
Desired outcome: {{success_metric}}

For each story, produce:
- Story title (verb-led, user-facing)
- User value in one sentence ("so that...")
- INVEST self-check: flag which letters are at risk and why
- Suggested sprint position (1, 2, 3...)
- Dependencies on other stories in this epic (if any)

After the list, produce a "Sequencing notes" section covering:
1. Which story delivers the first measurable value (thinnest possible slice)
2. Which 2 stories could be dropped without killing the epic
3. Any story that you could not make INVEST-compliant and why

Keep each story title under 10 words. Avoid technical jargon in the value statement. If the epic is too vague to decompose, ask one clarifying question instead of guessing.

Example Output

Epic: Self-serve billing portal

1. View current invoice — so that customers confirm charges without emailing support. INVEST: all green. Position: 1. Deps: none.
2. Download past invoices (12 months) — so that finance teams reconcile historical spend. INVEST: Small at risk (PDF gen). Position: 2.
3. Update payment method — so that cards can be replaced without churn. INVEST: Independent at risk (depends on #1 auth). Position: 2.
4. Change plan tier — so that customers self-upgrade without sales touch. INVEST: all green. Position: 3.
5. Cancel subscription — so that customers retain trust in easy exit. Position: 4.

Sequencing notes: Story 1 is the thinnest slice with measurable value (ticket deflection). Stories 4 and 5 could be dropped for v1 without killing the epic. Story 3 cannot be fully Independent due to the auth coupling in #1 — flag for tech lead.

Frequently Asked Questions

When should I use this prompt?

Use it immediately after an epic is approved and before sprint planning. It works best on epics with 2-6 sprints of estimated work. Smaller epics (1 sprint) rarely need formal decomposition, and epics larger than 6 sprints usually hide multiple initiatives that should be split at the portfolio level first. Pair this with a quick tech lead review within 24 hours to validate sequencing and expose hidden technical dependencies the model cannot see.

What if my epic has unknown technical dependencies?

The model cannot reliably detect engineering dependencies it has no visibility into, so the sequencing is a draft. Run the output past your tech lead in a 15-minute review and explicitly ask: which of these stories have shared code paths, database migrations, or infra work that prevents parallelization? Then re-order. A good rule: if two stories touch the same service boundary, treat them as dependent until proven otherwise.