User Story Splitter

Goal

Transform one large, unwieldy user story into a set of small, independently deliverable stories, each with clear acceptance criteria and no hidden dependencies.

Trigger

When a user story is too large to complete in a single sprint or contains multiple distinct behaviors, edge cases, or user journeys.

Steps

1. 1

   Analyze the user story below and identify all the distinct behaviors, user journeys, data variations, and edge cases embedded within it: $user_story

   • □The full original story is pasted in
   • □No assumptions made yet — just extraction
2. 2

   Classify the story's complexity drivers: list which SPIDR patterns apply (Spike, Path, Interface, Data, Rules). Note which dimensions are causing the story to be large and why each makes it hard to ship atomically.

   • □At least one SPIDR pattern identified
   • □Reason for bloat is clearly stated
3. 3

   Propose a splitting strategy based on the identified complexity drivers. Choose the most appropriate split pattern (e.g. happy path first, data variations, workflow steps, CRUD operations, rule sets) and justify the choice over alternatives.

   • □One primary split strategy chosen and justified
   • □Alternative strategies briefly considered
4. 4

   Generate 3–7 child user stories using the chosen strategy. Each story must follow the 'As a [role], I want [action], so that [benefit]' format, be completable in under 3 days, and deliver independently testable user value without requiring other child stories to be done first.

   • □Every story uses the standard As a / I want / So that format
   • □Each story is independently shippable
   • □No story depends on an unshipped sibling
5. 5

   For each child story, write 2–4 acceptance criteria in Gherkin-style Given/When/Then format. Flag any story that still feels too large and recommend a further split.

   • □Every child story has at least 2 acceptance criteria
   • □Gherkin format used consistently
   • □Oversized child stories flagged
6. 6

   Produce a dependency map showing the recommended delivery sequence. Identify which story is the 'walking skeleton' or minimum shippable slice, and flag any technical prerequisites (e.g. API, schema changes) that must be resolved before any story can start.

   • □Delivery order clearly stated
   • □Walking skeleton / first slice identified
   • □Technical blockers surfaced

Output format

Return a numbered list of child stories. For each: (1) the user story statement, (2) acceptance criteria in Given/When/Then, (3) estimated size (S/M/L), and (4) delivery order position. End with a one-paragraph summary of the split strategy used and a simple numbered delivery sequence.