How do you split a story that is too big to fit in a Sprint?

Short answer

Split vertically, so each slice goes end to end and delivers something demonstrable, using patterns such as workflow steps, business-rule variations, happy path first, and data or interface variants.

Treat this as a story splitting and refinement problem, not as a request to make tickets smaller. Good story splitting preserves a user-visible slice, keeps acceptance criteria testable, and gives refinement a sharper question to answer. Weak story splitting divides frontend, backend, and testing into separate tasks, which only creates partial work. Strong story splitting uses refinement to expose the real uncertainty, then splits around that uncertainty so each smaller story can still be reviewed and accepted. Story splitting is strongest when every slice still proves or disproves something useful.

Why the size matters at all

A story that spans a Sprint gives you no feedback until it is finished, and no early warning if it is going wrong. It also destroys forecasting, because throughput measured in items only means something when items are roughly comparable in size and finish regularly. So the goal of splitting is not tidiness. It is to get a reviewable, potentially shippable result inside days rather than weeks, and to move the risk of being wrong to the front.

That gives you the test for any proposed split: could this slice be demonstrated to the Product Owner on its own, and could it in principle be released? If the answer is no for a slice, you have decomposed the work into tasks, which is a different and lesser thing.

Patterns, in rough order of usefulness

Workflow steps. Take the end-to-end journey and ship one stage properly. "Submit an expense claim" splits into submit, approve, reimburse — each with a real user and a real outcome.

Business-rule variations. One rule now, the rest later. Flat-rate tax first, then the regional rules, then the exemptions. This is often the largest reduction available because the rules are usually where the volume of work hides.

Happy path first. Build the case where everything works, then add the error handling, retries and edge cases as separate items. This is the pattern most likely to be misused, so be explicit that it means deferring rare paths, not deferring validation on the common one.

Data or entity variants. Support one file format, one currency, one document type, one integration partner.

Interface variants. Ship the API and a plain form; the polished component, the keyboard shortcuts and the empty states are later items. Do not use this to defer accessibility if accessibility is in your Definition of Done.

Effort variants. Do it manually or with a configuration file now, automate it later. A monthly report that an operator triggers by hand is worth shipping while the scheduler is still a story on the backlog.

Concretely, one epic split two ways:

Bad split, layered	Better split, vertical
Database schema for bookings	Book one room type, single night, no payment
Booking API endpoints	Multi-night stays with pricing rules
Booking UI	Cancellation within the free window
Payment integration	Card payment on booking
Testing and hardening	Group bookings

The left column cannot be reviewed until the last row is done, and every row is a guess about what the next row needs. The right column is releasable at row one and every row after it teaches you something about the next.

Splits that are not splits

Two failures are common enough to be worth naming. The first is "part 1 and part 2", where the split is drawn at the Sprint boundary rather than at a boundary in the work — the team simply agrees that whatever is unfinished on Friday becomes part 2. That is carryover with better branding, and it removes the honest signal that the Sprint missed something.

The second is carving off the testing, the code review, or the deployment as their own backlog item. Anything in the Definition of Done travels with every slice; if it can be split off, it was never really in the Definition of Done. A team under pressure will do this precisely because it makes the first item finishable, which is exactly why an interviewer watches for it.

When it genuinely will not split

Occasionally the size comes from an unknown rather than from scope — a protocol nobody has used, an integration with no documentation. Splitting scope does not help, because you cannot slice what you cannot yet describe. Take a time-boxed spike with a stated question and a deliverable, and note that the spike's output is a decision, not working software, so its value is in what it lets you split afterwards.

The other hard case is a genuinely atomic technical change, such as a migration that cannot be half-applied. Here the useful move is a thin end-to-end path with values hardcoded or a feature flag holding it dark, so the plumbing is proven early and the behaviour arrives incrementally behind the flag. If neither works, say so and plan the large item explicitly rather than pretending a fake split makes it safe.

---

© 2026 Preptima. Originally published at preptima.com.