Warning signs a story needs splitting
You rarely need a formula to know a story is too big — the estimation itself tells you. Watch for these signals during backlog refinement and voting:
- The votes land at the top of your deck — lots of 13s and 21s.
- The spread is wide and won't converge even after discussion — a common disagreement that splitting resolves.
- The story's description uses "and" to join what are really separate outcomes.
- Nobody can describe what "done" looks like in one sentence.
- The team keeps saying "it depends" — usually on a branch you could split out.
Split vertically, not horizontally
The cardinal rule: each slice should deliver a thin piece of end-to-end value, not a technical layer. A vertical slice touches whatever it needs to — interface, logic, storage — but does one small, demonstrable thing. A horizontal split carves the story by layer ("do the database, then the API, then the UI"), which produces pieces nobody can ship or even really estimate, because none of them is done until all of them are. Vertical slices stay independently valuable and independently estimable.
Patterns that actually work
When a story resists splitting, run it through a few standard lenses until one clicks:
- Workflow steps — ship the happy path first, add the steps around it later. "Check out with a saved card" before "check out with a new card, PayPal, and gift codes."
- Business rules — implement the common rule now, the exceptions as their own stories. "Refund within 30 days" before "refund with restocking fees and partial returns."
- Happy path vs. edge cases — the successful flow is one story; validation, error states, and empty states are follow-ups.
- Data variations — support one format, region, or currency first, then generalize.
- Effort spike — when the story is unknowable, split off a timeboxed investigation so the remainder becomes estimable.
A worked example
Take: "As a user I can export my report as CSV, Excel, and PDF, with scheduling and email delivery." That's a 21, and the votes will be all over the place. Slice it vertically:
- Export the report as CSV, downloaded in the browser. Small, shippable, valuable.
- Add Excel as a second format. Reuses the pipeline; smaller than the first.
- Add PDF. Different rendering path — worth its own estimate.
- Schedule an export to run later.
- Email the finished export to the user.
Five stories, each a 2, 3, or 5, each demonstrable on its own. The team can ship the first slice next sprint instead of carrying a 21 for three sprints. And each slice estimates far more tightly than the bundle ever could.
Re-estimate the slices
Splitting isn't just bookkeeping — it changes the numbers. The pieces almost always sum to less than the original estimate, because the original number carried a risk premium for everything you didn't understand. Once each slice is concrete, that premium evaporates. Re-vote the slices fresh; don't try to divide the old estimate across them. If a slice still lands at the top of the deck, split again. See story point estimation for why smaller stories estimate more reliably.
Mistakes to avoid
- Horizontal splits. "Backend story" and "frontend story" can't be demoed or shipped independently. This is the most common splitting mistake and it defeats the purpose.
- Splitting into tasks. "Write the migration," "add the endpoint," "style the form" are tasks, not stories — they don't each deliver user value.
- Slices too thin to matter. If a slice delivers nothing a user or stakeholder would notice, you've over-split. Aim for the smallest thing that's still worth demoing.
- Splitting during voting. Do the splitting in refinement, before the session — mid-vote restructuring derails the whole meeting.
The Agile Alliance's guidance on splitting stories is a good reference for the full pattern catalog. The habit to build: when a story feels too big to estimate, that feeling is the trigger to split — don't push through it with a bigger number.