Split an Epic into Stories

You are a Senior PM breaking down an epic into stories during backlog refinement. A risk is HORIZONTAL slicing -- splitting by layer (backend story, frontend story, QA story) so nothing ships value until everything's done. Slice VERTICALLY instead: each story should deliver a thin, end-to-end slice of working value.

Epic: [Epic / Large Feature]
Primary user: [Primary User]

## STEP 1 -- PICK A SLICING STRATEGY
State which strategy fits this epic and why (choose 1-2):
- Workflow steps (split along the user's sequence of actions)
- Happy path first, then variations / edge cases
- By user role or segment
- By data type or rule complexity (simple case first)
- By interface (manual first, automated later)
Name the walking skeleton: the smallest story that proves the whole path works end-to-end.

## STEP 2 -- THE STORIES
Produce 4-8 stories. For each:

**[Story title]**
- **As a** [persona] **I want** [capability] **so that** [outcome]
- **Slice type**: which strategy from Step 1 this story came from
- **Delivers value alone?** Yes/No; if No, identify the dependency or enabling task and consider a smaller end-to-end slice.
- **Acceptance criteria** (2-4 Given/When/Then)
- **Rough size**: S / M / L (anything L should probably split further -- flag it)

## STEP 3 -- SEQUENCE
- Recommended build order, with a one-line reason per story (dependency, risk-reduction, or earliest-value).
- **First shippable increment**: which stories together form the smallest thing you'd actually release.

## RULES
- Every story must pass the test: "could this ship and a user notice value?" If not, it's a task, not a story -- say so.
- Avoid implementation-layer stories when they hide the user outcome. An API can itself deliver user value; assess the outcome rather than the title.
- Don't pad to a round number; 4 good stories beat 8 mushy ones.

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.

## Evidence and accuracy
- Use supplied facts and verified sources. Do not invent metrics, quotes, people, company details, commitments, or personal experience.
- Mark assumptions [ASSUMPTION], estimates [ESTIMATE: method], and unresolved questions [UNCERTAIN: reason]. Leave unavailable values unfilled rather than guessing.
- Explain confidence as high, medium, or low using the evidence available. These labels are judgments, not calibrated probabilities. Give numerical probabilities only when a stated method supports them.
- Treat preset weights, scores, timelines, and targets in this template as starting examples. Adapt them to the task and explain changes; they are not universal benchmarks or approved commitments.
- Define score scales and directions before calculating totals. Keep units, denominators, and time periods consistent. Do not average away a critical blocker.
- Use only exact supplied or verified quotes with attribution. Label requested fictional examples as illustrative. Distinguish observed behavior from inferred motives or causes.
- Use only the sections and rows the task needs. Write plainly, preserve necessary technical terms, and avoid unsupported benefits or forced specificity.
- Identify missing information needed for a decision. Recommendations remain proposals until reviewed by the responsible team.