SPIDR story splitting
Five reliable cut lines. Pick whichever one produces a slice you'd ship.
SPIDR — Spike, Path, Interface, Data, Rules — is the splitting technique that survives contact with most backlogs. Each letter is a cut line; each cut produces slices that ship independently rather than halves that only work together.
Spike
The unknown is the size. Run a time-boxed investigation, learn the shape, then estimate the real story. See what is a spike.
Path
The story has multiple flows. Ship the happy path first; bad-data paths, error states, and edge cases are their own stories. The user can complete the goal on the happy path even if the rest is missing.
Interface
The story has multiple surfaces — web, mobile, API. Ship one surface first. The remaining surfaces 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 if the second one 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 ship-able 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 prioritization question, not a splitting one.
See also: the story is too big for the diagnostic that this is the splitting move you need; other estimation techniques for fuzzier stories that survive splitting.