The story is too big

The story that doesn't fit in a sprint. The split that has to happen now, or it'll happen badly later.

If you can't finish it in a sprint, it isn't a story. Split it now or it'll split itself badly.

A story that won't fit in a sprint isn't a sizing problem; it's a shape problem. The team will either spend the sprint trying anyway and carry over what's left (badly — the carry-over is whatever's hardest), or finish a shippable subset and call it done while leaving the rest in a half-built state. Both are worse than splitting on purpose before the sprint starts.

The split has to be vertical — a thin slice that's actually deliverable on its own — not horizontal. "Backend first, frontend next sprint" is splitting the same way a knife splits dough: it gets you two halves of nothing.

The story that won't fit becomes three slices that each ship on their own.

Signals the story is too big

  • The team votes 13s and 20s, then keeps re-voting to converge instead of splitting.
  • "It depends" answers more than two 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.

The split that works

Slice vertically. Each slice has to be releasable on its own — even if behind a flag, even if to a small audience. SPIDR gives you five reliable cut lines: spike, path, interface, data, rules. Pick the one that produces a slice you'd ship.

If a single slice still won't fit, the story isn't ready yet — it's a project.

See also: when the team can't agree on a number — it's almost always the same problem in disguise.