SPIDR Breakdown Technique

---

Origins

SPIDR was articulated by Mike Cohn as a deliberate, memorable catalog of story-splitting moves.¹ Teams who struggle with smallness often do so not because they lack the will but because they lack the repertoire: when someone says "split this further", no one knows where the seam is. SPIDR gives the team five places to look — five named moves — that, between them, cover the vast majority of useful splits.

The acronym stands for:

• Spike
• Path
• Interface
• Data
• Rules

Spike

A spike is a small, time-boxed investigation whose output is understanding, not working software. Use a spike when the team genuinely cannot estimate or commit because the unknowns are too large. A spike is itself a story — small, valuable in the sense that it produces clarity, with a defined exit criterion (we will have learned X by Y).

Spikes are powerful but easy to abuse. Two pitfalls: the spike that has no exit criterion and runs forever, and the spike that becomes a euphemism for "real work we are too embarrassed to estimate." A healthy spike is short, focused, and unmistakably distinct from production work.

Path

Most features have multiple paths through them — happy path, error path, edge cases, alternate flows. Splitting by path means delivering the most valuable path first and the others as separate stories. Reset password with email link can ship without reset password via security questions, which ships without reset password with admin override.

Path splits are usually the easiest and most valuable. They produce thinner vertical slices that still deliver something a user can do end-to-end.

Interface

Interface splits separate the channel from the capability. The same underlying behavior can be delivered first through one interface (a simple web form, a CLI, an API call) and later through richer interfaces (a polished UI, mobile clients, third-party integrations). Reporting features split well this way: ship the CSV download first, the rich dashboard later.

This is often the right move when a feature is genuinely needed by an internal user but a fully polished consumer interface would dominate the story's effort.

Data

Data splits restrict the scope of inputs the story handles. Support English-language addresses first; international addresses next sprint. Handle PDF imports first; Word and Excel later. Process orders under $10,000 first; large orders with their special workflow later.

The trick is to choose a data slice that is meaningful on its own. Splitting "support all currencies" into "support USD only" is fine if USD is most of your traffic. Splitting it into "support currencies starting with the letter A" is not — the slice has to deliver real value to be a valid split.

Rules

Rules splits hold off complex business logic. Apply the discount; deal with the loyalty tier multipliers later. Allow cancellations within 30 days; the seasonal exceptions can come next sprint. Often, the basic rule covers 80% of cases and the elaborate rules cover the long tail.

This split is particularly useful when the rules are still being debated by stakeholders. Shipping the simple rule unlocks real-world data on whether the elaboration is worth the cost.

Using SPIDR in Refinement

When a story is too big, walk it explicitly through the five letters:

• Is there a Spike that would let us commit?
• Are there Paths we can defer?
• Can we ship a simpler Interface first?
• Can we restrict the Data we handle in the first slice?
• Can we leave any Rules out of the first version?

Usually at least one letter produces a clean split. Often two or three do, and the team chooses the one that produces the most valuable thin slice. The discipline of walking all five letters in order is what trains the muscle — left to instinct, teams default to one familiar pattern and miss the others.

SPIDR and Story Slicing Patterns

SPIDR overlaps significantly with the broader vocabulary of story slicing patterns. The difference is positioning: SPIDR is a compact, memorable starter kit; the wider slicing pattern library (Richard Lawrence, Mike Cohn, Christiaan Verwijs and others) extends it with additional moves like Workflow, Operations, and Quality. Teams comfortable with SPIDR usually graduate naturally into the larger library.

Coaching Tips

Print SPIDR on the wall.

The acronym is short enough to memorize. A visible reminder in the refinement space speeds up adoption.

Walk all five letters out loud.

Even when the first letter produces a split, walking the rest often surfaces a better one.

Default to Path splits.

If you're stuck, ask "what's the happy path?" — and ship that. The other paths almost always slice cleanly behind it.

Beware the rule-tail.

The simple rule plus "we'll add the exceptions later" is a recipe for a backlog full of exception stories. Make sure each rule split is genuinely sequenceable.

Spike with a hard time-box.

Two days max for most spikes. Longer than that and the spike has become real work.

Validate the slice produces value.

After splitting, ask the PO: "would you ship this on its own?" If the answer is no, the split is technical, not vertical.

Summary

SPIDR is the cheapest training a team can give itself for story splitting. The acronym takes two minutes to teach, and the structured walk through the five letters reliably produces splits that pure intuition would miss. Teams that internalize SPIDR are not faster because their stories are smaller; they are faster because they have stopped getting stuck on the question of how to make them smaller.

Back to Story Crafting