Splitting by workflow steps
The most-reached-for splitting technique, and the one that goes wrong most often. The test is whether each step delivers value alone.
Workflow splits work when each step delivers value alone. Otherwise you've just sliced a waterfall.
Workflow splitting takes a user journey — sign up, set preferences, confirm email, see dashboard — and turns each step into its own story. When it works, it's the cleanest splitting technique in the toolkit: each story ships a recognizable user-visible thing, each can be demoed, each can be scoped and estimated independently. When it doesn't work, it's horizontal slicing wearing workflow-shaped labels, and the team has gained nothing except a longer backlog.
The test
Take each "step" the team produced and ask: would the user benefit from this if we shipped it and nothing else? "Set preferences" is fine — a user with preferences but no email confirmation is in a usable state. "Email confirmation" is fine — a user who got confirmed but hasn't seen the dashboard yet is in a usable state. "Submit form" is not fine — a user whose form submission goes nowhere is worse off than before. If the answer is no, the step is a sub-task, not a story, and the workflow doesn't split there.
The other test, which is faster: could each step be released to production over the course of three sprints without anything else changing? If the user starts in week one with sign-up only, then in week three sees preferences enabled, then in week five gets the dashboard — and at each step the experience is coherent, even if reduced — the workflow split works. If skipping any step leaves the user looking at a broken page, the split is fake.
Where the technique fails
Most workflow splits fail on the "user benefits from each alone" test. Engineering teams reach for it because it matches the way the code naturally decomposes — endpoints, services, components — and the resulting stories feel granular. They are granular. They're also horizontal slices with workflow vocabulary on top: the auth-service story, the preferences-API story, the dashboard-component story. None of those ships anything to the user; all of them ship things to other engineers.
The tell: each "step" story is owned by exactly one specialist (backend, frontend, design). Real workflow splits cross specialties because real user-facing steps cross the stack. If sign-up is one ticket and "sign-up UI" is another, the splitting was horizontal, not workflow-based.
When workflow splitting beats alternatives
Multi-step user journeys with natural pause points. Onboarding flows. Approval workflows where the user can legitimately walk away mid-process. Account-setup processes where each step unlocks something. The pattern works because each step is an independent decision the user makes, and the system has to support each one regardless of what comes after.
It also works for migration-style stories where the team can ship a partial state to production. "Show the new sidebar" can ship before "wire the new sidebar to live data" if the sidebar shows static state in the interim. That's workflow splitting against deploy state rather than user journey, but the same test applies: each shipped step has to be coherent on its own.
If skipping any step leaves the user looking at a broken page, the split is fake. Find a different axis.
Adjacent: SPIDR splitting for the other axes when workflow doesn't fit; horizontal vs vertical slicing for the failure mode this technique most often slides into; user-story splitting patterns for the broader catalog.