User-story splitting patterns

SPIDR covers most splitting situations, but a few patterns recur often enough to be worth naming on their own.

Workflow steps

A story that spans multiple workflow steps — submit, approve, notify, archive — splits cleanly along step boundaries. The first step is shippable on its own (the user can submit; approval comes next sprint).

Business rule variations

A story with multiple business rules (regular user, admin, API client) splits by rule. The most common rule first; the variants follow. Each variant is a real story with its own users.

Happy path / unhappy path

Closely related to SPIDR's "Path" cut. Ship the happy path; error handling, retries, and edge cases follow. The user can succeed even if the failure modes aren't fully handled — provided you accept worse failure UX in the meantime.

Deferred quality (acceptable, with discipline)

Ship the slice without the polish — no tooltips, no animations, no admin overrides. Then ship the polish as its own story. This works if you actually ship the polish; teams that punt quality and never come back end up with permanent half-features.

Operations

A story that's part user-feature, part operational concern (logging, monitoring, alerting) splits along that line. Ship the user-facing slice first; the operational slice is a follow-up that often goes faster because the feature is already in production and the gaps are visible.

What's not a real split

"Frontend in this sprint, backend in the next" isn't splitting; it's deferring delivery. Neither half ships anything alone. The same goes for "build it, then write the tests" — un-tested code is a liability, not a slice.

See horizontal vs vertical slicing for the underlying principle; SPIDR for the foundational five cuts.