Vertical vs Horizontal
Why splitting a story by technical layer fails INVEST on three letters at once. The vertical slice that ships end-to-end, teaches the team something, and lets product deprioritize the rest.
Customers can pay with SEPA direct debit
Customers can pay with SEPA direct debit
Layer-by-layer splits fail INVEST on three letters at once: the backend slice is not Independent (frontend waits), not Valuable (no user benefits from an API nobody calls), and not Testable from the user perspective. Nothing ships until everything ships.
Each vertical slice goes through the data, logic, and UI layers it needs and ships a piece of customer-visible value end-to-end. After slice one, the team has shipped something real and learned what the next slice should look like.
Build the entire SSO infrastructure (no provider integration yet)
Add SAML support, JWT issuance, session refresh, and the new sign-in page. No provider wired up; that comes next sprint.
Enterprise admins sign in with one specific Okta tenant
End-to-end: one Okta tenant, the new sign-in page, SAML handling for that one provider. The next slice generalizes to other tenants.
An infrastructure-only slice carries all the cost of the provider integration without the learning. The next sprint will discover that the chosen abstraction does not fit Okta's actual response shape and rework most of it.
The right slice ships value AND teaches the team about real SAML edge cases the second slice would otherwise rediscover. The 'infrastructure first' framing is horizontal slicing in disguise.
Managers see weekly throughput per direct report
Managers see weekly throughput per direct report
Schema → job → API → UI is a textbook horizontal split. Three slices have no user-visible result. The fourth slice has all the integration cost, and product cannot demo anything until the entire epic is done.
Each slice ships a usable view a manager can demo. Slice one is rough but real; slice two broadens the scope; slice three polishes it. Product can deprioritize slice three on its own merits.
Splitting at refinement
When a story is too big, the most senior engineer proposes a split and the team accepts it.
Splitting at refinement
When a story is too big, the team generates three different splits using three different patterns (workflow, data, rules), sketches each on the board, then picks the split that lets product deprioritize the least valuable slices most cleanly.
Stopping at the first workable split is a common shortcut that costs the team product flexibility. The senior's split may be technically valid and still leave product with one big slice and two unimportant ones.
The first workable split is rarely the best one. Generating three lets the team see which one yields the most product optionality. That is the lever that turns slicing from 'making it smaller' into 'making it deliverable'.
Self-serve enterprise onboarding
Self-serve enterprise onboarding
A 12-1-1 split has one real slice plus two rounding errors. Product cannot meaningfully reorder them, and the big slice is the same Epic with two trivial decorations attached.
Three roughly equal slices give product three real options: ship all, drop the SSO slice for now, or move the plan slice to a later sprint. The slices are individually valuable.
Splitting preflight
If a story is too big, run it through the splitting patterns until it fits in a sprint.
Splitting preflight
Before splitting: confirm it is a story (named user, observable outcome) and confirm INVEST fails only on Small. If it also fails on Valuable or Testable, fix the framing first.
Reaching for splitting patterns first will produce four small things that still fail INVEST in the same way the original did. The split looks like progress; the work has not actually been clarified.
Splitting patterns apply to stories. 'Refactor the payment module' is not a story, and no pattern will turn it into one. Confirming the framing first prevents the team from generating four equally-bad sub-tasks.