SPIDR story splitting

SPIDR is five reliable ways to split a user story — spike, path, interface, data, rules. Each cut line, when it works, and when it produces a fake slice.

SPIDR is five reliable ways to split a user story: Spike, Path, Interface, Data, Rules. Each letter is a cut line, and each cut produces slices that ship independently rather than halves that only work together. It’s the splitting technique that survives contact with most backlogs — when a story is too big, one of these five axes almost always yields a slice you’d release.

Five SPIDR cut lines through a story one story, too big Spike Path Interface Data Rules ship first later ship order
Five cut lines through one story. You don’t use all five — you find the one that produces a slice you’d actually ship.

The five cut lines

Spike

The unknown is the size. Run a time-boxed investigation, learn the shape, then estimate the real story. This is the cut to reach for when the team can’t agree on a number because nobody has done this before — see running a spike for what the deliverable should look like.

Path

The story has multiple flows. Ship the happy path first; bad-data paths, error states, and edge cases become their own stories. The user can complete the goal on the happy path even while the rest is still missing.

Interface

The story has multiple surfaces — web, mobile, API. Ship one surface first. The rest share the implementation but are deliverable on their own schedules.

Data

The story handles multiple data shapes or volumes. Ship the simple case first — single tenant, small dataset, common file format — then the variants. Each is a real story, even when the second is mostly a sibling of the first.

Rules

The story has multiple business rules or roles. Ship the most common rule first; admin overrides, special cases, and exceptions follow. The 80% case is shippable without the 20% case.

When SPIDR doesn’t help

If none of the five cuts produce a real, shippable slice, you don’t have a splitting problem — you have a scope problem. The story is one indivisible piece of work, and the conversation is “do we want all of it this sprint, or none of it.” That’s a prioritisation question, not a splitting one, and no amount of clever slicing will turn it into one.

Pick the cut that produces a slice you’d actually ship. If none of them do, the story isn’t asking to be split — it’s asking to be prioritised.

Frequently asked questions

What does SPIDR stand for?

SPIDR stands for Spike, Path, Interface, Data, Rules — five different axes you can cut a user story along. Each one is a cut line that produces slices which ship independently, rather than halves that only work together.

How do you use SPIDR to split a user story?

Try each of the five cuts against the story and pick whichever one produces a slice you would actually ship on its own. You don’t apply all five — you find the one axis that yields a thin, deliverable slice, and split along it.

Who created the SPIDR technique?

SPIDR was introduced by Mike Cohn as a compact set of five reliable ways to split a user story. It’s popular because the five cuts cover most of the situations teams actually hit, and five letters are few enough to run through in your head mid-refinement.

What if none of the SPIDR cuts produce a good slice?

Then you don’t have a splitting problem — you have a scope problem. The story is one indivisible piece of work, and the real question is whether you want all of it this sprint or none of it. That’s a prioritisation decision, not a splitting one.