Story Splitting

Purpose

Story Splitting helps teams decompose oversized user stories into thin vertical slices that are independently testable and deliverable. Smaller stories improve flow, reduce risk, and accelerate feedback.

At a glance

How to run

1. Pick the story (5 min) — Select a story the team agrees is too large for one Sprint.
2. Review splitting patterns (5 min) — Present the nine common patterns: workflow steps, business-rule variations, happy/unhappy path, data variations, interface variations, CRUD operations, performance, spike vs. implementation, defer quality attributes.
3. Apply patterns (25 min) — Walk through each pattern and brainstorm how it could apply. Write each candidate slice on a card. Aim for slices that have independent user value.
4. Validate slices (5 min) — For each candidate, ask: Is it independently testable? Does it deliver value? Can it be completed in one Sprint? Discard or merge slices that fail.
5. Estimate & order (5 min) — Quickly size the new slices and decide which to tackle first.

Materials needed

• The original large user story with acceptance criteria
• Story-splitting patterns cheat sheet
• Sticky notes or digital cards
• Whiteboard or Miro

Pitfalls & common mistakes

• Splitting by technical layer — Build the API / Build the UI is horizontal slicing; always prefer vertical slices with end-to-end value.
• Slices too thin to test — Each slice must be independently demonstrable.
• Only one pattern tried — Apply multiple patterns; the best split often comes from the third or fourth attempt.
• Losing the user perspective — Every slice should still be expressible as a user story.

Inclusion & accessibility

• Share the original story and patterns cheat sheet in advance.
• Use colour-coded cards for different splitting patterns to aid visual thinkers.
• Encourage quiet ideation before group discussion (2 min silent brainstorm per pattern).

Variations

• Hamburger method — Visualize slices as layers of a burger, from MVP to premium.
• Elephant carpaccio — Richard Lawrence's exercise for practising ultra-thin slicing.
• SPIDR — Spike, Paths, Interface, Data, Rules — a five-pattern mnemonic.

When NOT to use this

• If the story is already small enough to complete in a day or two — splitting further creates overhead.
• If the team lacks enough understanding of the story — run a spike or Example Mapping first.

Source & further reading

• Lawrence, R. (2009). "Patterns for Splitting User Stories." agileforall.com
• Patton, J. (2014). *User Story Mapping*. O'Reilly.