Splitting user stories that won't fit a sprint

A story you can't estimate is usually one you can't ship yet. How to tell when to split, the cut lines that produce shippable slices, and the ones that only fake it.

Splitting a user story means cutting one story that’s too big into smaller stories that each still deliver something a user can use. A story you can’t estimate is usually one you can’t ship yet — and splitting is the move that gets it back on the board.

Most “we can’t estimate this” conversations are splitting conversations in disguise. The team doesn’t have a number-and-effort problem; they have a too-many-unknowns problem. Splitting reduces the unknowns until the story has the shape of work that’s been done before — and the estimates converge.

When to stop estimating and start splitting

A story that won’t fit in a sprint isn’t a sizing problem; it’s a shape problem. Watch for the signals:

  • The team votes 13s and 20s, then keeps re-voting to converge instead of splitting.
  • “It depends” answers more than a couple of the refinement questions.
  • The story spans more than one team’s area.
  • “Done” requires multiple deploys.
  • You can describe it in two sentences but not in two acceptance criteria.

If you push through anyway, the team spends the sprint trying and carries over what’s left — badly, because the carry-over is whatever was hardest — or finishes a shippable subset and calls it done while the rest sits half-built. Both are worse than splitting on purpose before the sprint starts.

One oversized story splitting into three thinner slices ? ? too big won't fit in a sprint ✓ slice 1 shippable ✓ slice 2 shippable ✓ slice 3 shippable each slice ships on its own
The story that won’t fit becomes three slices that each ship on their own — not two halves of nothing.

Why a wide vote spread means split, not re-vote

When a team sizes work together with planning poker, a wide spread is the most useful signal it produces. Cards spread from 3 to 13 isn’t a number disagreement. It’s two stories pretending to be one. The 3 voter is seeing one scope; the 13 voter is seeing a different scope. Re-voting won’t reconcile them — the work is the conversation about which scope is real. Here’s what’s usually happening underneath:

  • One person is sizing the happy path; another is sizing the edge cases.
  • One person assumes the design exists; another assumes they’re designing it.
  • One person is sizing the query; another is sizing the rollout.
  • One person knows the dependency exists; another doesn’t.
  • One person is sizing for someone in the room; the work belongs to a different team.

More detail rarely fixes this — it produces a longer ticket, not a sharper estimate. Splitting does: into a spike if the unknown is the cause, into vertical slices if the unknown is the scope. Two cards spread doesn’t mean the team disagrees. It means the team is voting on different stories. Send it back.

Slice vertically, not horizontally

The split has to be vertical — a thin slice that’s actually deliverable on its own — not horizontal. “Backend first, frontend next sprint” splits the story the way a knife splits dough: you get two halves of nothing. A vertical slice touches every layer and ships a working column — one button that works end to end, even if it only handles one input case. See horizontal vs vertical slicing for the principle in full.

Splitting patterns that work

SPIDR — spike, path, interface, data, rules — covers most splitting situations, and it’s the first place to look. A few other patterns recur often enough to be worth naming.

Workflow steps

A story that spans a user journey — sign up, set preferences, confirm email, see dashboard — often splits cleanly along step boundaries. When it works, it’s the cleanest technique in the toolkit: each story ships a recognisable user-visible thing, each can be demoed, each can be scoped on its own.

The test is one question, asked of every step: would the user benefit from this if we shipped it and nothing else? “Set preferences” passes — a user with preferences but no email confirmation is still in a usable state. “Submit form” fails — a user whose 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 faster version of the same test: could each step reach production over three sprints without anything else changing, and leave a coherent experience at every stop? If skipping a step leaves the user looking at a broken page, the split is fake. That’s the trap engineering teams fall into — the steps match how the code decomposes (auth service, preferences API, dashboard component), so they feel granular. They are granular. They’re also horizontal slices with workflow vocabulary on top, and none of them ship anything to the user. The tell: each “step” is owned by exactly one specialist. Real workflow steps cross the stack, because real user-facing steps do.

Business-rule variations

A story with multiple rules or roles — regular user, admin, API client — splits by rule. Ship the most common rule first; the variants follow. Each variant is a real story with its own users.

Happy path, then 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 before the failure modes are fully handled — as long as you accept worse failure behaviour in the meantime, and you actually come back for it.

Deferred quality

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 return 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 isn’t a real split

“Frontend this sprint, backend the next” isn’t splitting — it’s deferring delivery, because neither half ships anything alone. “Build it, then write the tests” is the same shape: untested code is a liability, not a slice. If a piece of work only has value once its sibling lands, you haven’t split the story. You’ve scheduled it.

When a story can’t be split: run a spike

Sometimes the unknown is the size itself — nobody’s done this before, the vendor’s API doesn’t answer the load-bearing question, or the work depends on a measurement nobody has yet (current p99, current call volume, current data shape). That’s when you run a spike: a time-boxed investigation whose output is knowledge — a doc, a prototype, a recommendation, a measurement — not shipped product code. You come back able to estimate the real story honestly.

Spikes get misused as “let’s just start and see what happens.” That isn’t a spike — it’s an unestimated story with extra steps. Two signals you’ve got the wrong tool: there’s no specific question being answered, or the deliverable is “the feature is built.” The first means the team isn’t actually unsure; the second means it’s a story.

If a single slice still won’t fit, the story isn’t ready yet — it’s a project. Size it as one, communicate the timeline, and stop pretending a sprint will hold it.

Frequently asked questions

How do you split a user story?

Split it vertically — along user outcomes, so each slice touches every layer and ships something a user can use, even if it only handles one case. SPIDR gives five reliable cut lines: spike, path, interface, data, rules. Pick whichever one produces a slice you would actually release.

What do you do when a user story is too big for a sprint?

Split it before the sprint starts, on purpose. A story that won’t fit gets carried over badly — the leftover is whatever was hardest — or shipped as a half-built subset. Both are worse than a deliberate vertical split into slices that each ship on their own.

When should you split a story instead of estimating it?

When the team can’t fit it in a sprint, when the vote spreads wide (a 3 next to a 13), when “it depends” answers more than a couple of refinement questions, or when the story spans more than one team. A wide spread isn’t a number disagreement — it’s two stories pretending to be one.

What is a spike in agile?

A spike is a time-boxed investigation, run when the team can’t size a story without learning more. The output is knowledge — a doc, a prototype, a measurement — not shipped product code. Two things make it a spike rather than open-ended work: a clock and a deliverable.

What are the common ways to split a user story?

Workflow steps, business-rule variations, happy path then unhappy path, deferred quality, and operational concerns — plus the five SPIDR cuts. The test for all of them is the same: would the user benefit if this slice shipped and nothing else did?