skip to content

A user story is too large to finish inside one iteration — how do you split it?

level: middleimportance: must knowfreq 71%

answer

  1. cut so each piece is usable
  2. never by technical layer
  3. one workflow step, one rule
  4. happy path first, exceptions later
  5. check each slice against INVEST

basics

~20 s

Split vertically, so each slice runs end to end and delivers something usable, rather than horizontally by technical layer. The common cuts are one workflow step, one business rule, one data variation, or the happy path before the exceptions.

solid answer

~50 s

The failing split is **horizontal** — one item for the data store, one for the service, one for the interface. Each can be finished, yet none is worth anything until all three land, so the team gets no early feedback and cannot re-order the pieces. A **vertical slice** cuts the same work so each piece goes end to end and produces an outcome somebody could use, however narrow. The patterns I reach for, in order: take one **step of the workflow**; take one **business rule** and defer the rest; take one **data variation** — one appointment type, one payment method; take the **happy path** and make each error case a separate item; take one **operation** where create, read, update and delete differ in value. If none applies, the item is usually an epic that needs a conversation rather than a mechanical slice.

code

pseudocode · 15 lines
pseudocode
TOO LARGE
  As a patient, I want to manage my appointments online

SPLIT BY WORKFLOW STEP
  1. View my upcoming appointments
  2. Cancel one upcoming appointment
  3. Move one appointment to another open slot

SPLIT BY DATA VARIATION (inside step 3)
  3a. Move a routine check-up
  3b. Move a treatment that needs a double slot

SPLIT BY BUSINESS RULE (inside step 3)
  3c. Allow moves more than 48 hours ahead
  3d. Apply the late-change fee inside 48 hours

go deeper

for a junior

Know the difference between a vertical slice and a horizontal one, and be able to say why the layer split fails: no single layer is usable on its own. Have one concrete example ready.

for a middle

This is your level's question. Name three or four split patterns without hesitating and apply one to an oversized item handed to you in the room, out loud, arriving at slices somebody could actually use.

for a senior

Show judgement about when splitting stops paying: coordination cost, integration seams, and items so thin nobody can demonstrate them. Be ready to say when you would deliberately leave an item whole.

for a principal

Use slicing to sequence risk, not just size. The angle to own is getting evidence early — which slice retires the largest unknown — and how you hold that line with a stakeholder who wants everything at once.

## Why the obvious split is the wrong one The reflex when an item is too big is to cut it the way the system is built: one item for the data store, one for the service, one for the interface. This is a **horizontal split**, and it fails for a reason that has nothing to do with tidiness. None of the three pieces is worth anything alone. You cannot show one to a stakeholder, you cannot learn anything from it, and you cannot re-order the pieces because all three must land together anyway. The list now holds three items where it held one, and the team's ability to change its mind has not improved at all. A **vertical slice** cuts the same work so that each piece runs end to end and produces something a person could use, even if what it does is narrow. The test is blunt: *if only this slice shipped, could anyone do something they could not do before?* If the answer is no, it is a fragment, not a slice. | | Horizontal split | Vertical slice | | --- | --- | --- | | Cut along | Technical layers | User-visible outcomes | | Each piece alone | Useless until all land | Narrow but usable | | Feedback arrives | After the last piece | After the first piece | | Re-ordering | All or nothing | Each piece can move | ## Split patterns worth having ready An interviewer who hands you an oversized item is checking whether you have patterns rather than instinct. Five cover most cases: 1. **By workflow step.** Take one step of the user's journey and leave the rest. "Manage my appointments" becomes view, then cancel, then move. 2. **By business rule.** Implement one rule now and defer the others. Moves more than 48 hours ahead first; the late-change fee later. 3. **By data variation.** One appointment type, one payment method, one region — then widen. 4. **Happy path first.** Build the main path and make each error, timeout and conflict case its own item. This is often the single largest reduction available. 5. **By operation.** Create, read, update and delete rarely carry equal value. Take the ones that do. Two more are worth knowing: **by channel**, where one way of reaching the capability ships before another, and **manual first**, where a person performs one step that will later be automated so the rest of the path can go live now. ## Applying them Given *as a patient, I want to manage my appointments online*, the first cut is by workflow step: view, cancel, move. "Move" is still large, so cut again — by rule and by data variation: move a routine check-up more than 48 hours ahead; then a treatment needing a double slot; then the inside-48-hours case with its fee. Three of those five could be released independently, and each would be visible to a patient. After splitting, check each slice against the **INVEST** heuristics: **I**ndependent enough to move in the order, **N**egotiable rather than frozen, **V**aluable to somebody, **E**stimable in the sense that the team understands it well enough to judge it, **S**mall, and **T**estable through stated acceptance criteria. The two letters that catch bad splits are V and T — a fragment fails "valuable", and a slice for which nobody can write a single criterion fails "testable". ## Splits that are not splits - **Design, build, test** as three items — the layer failure wearing process clothing. - **Part one and part two**, where part one is defined as "the first half of the work". - **An investigation plus the real item**, when the investigation is simply the first day of the real item. - Slicing so thin that coordination costs more than it saves; thirty items nobody can hold in mind is not an improvement on five. - Splitting to make an item *fit* rather than to change what it *contains*. Splitting is re-scoping, not re-sizing: if the same total work must still ship together on the same day, nothing was gained. ## When not to split Splitting has a price — more items to order, more conversations, more integration seams. It is worth paying when the team needs feedback sooner, when part of the work carries risk worth retiring early, or when the item genuinely cannot finish inside one iteration. It is not worth paying when the capability is worthless in parts and will be released as one thing regardless; there the honest move is to keep it whole and be explicit that it spans iterations rather than to manufacture slices that only exist on the list. A good answer also names what splitting does *not* do. It does not reduce total work, it does not make an unclear item clear, and it does not remove a dependency. An item that resists every pattern above is usually one nobody understands yet, and the fix is a conversation rather than a knife. ## The fixed-scope pressure A customer insisting on fixed scope hears "we are splitting it" as "we are cutting your feature", and the argument that follows is about the total rather than the sequence. What works is to show the order of the slices instead of debating the sum: the same scope, arriving in an order they can see, with the chance to change their mind after the first slice rather than after the last. That is a better offer than the one they think they are being denied, and it is one the team can actually keep.

  • How do you tell a genuine slice from a technical fragment dressed up as one?
    Ask what a person could do if only that slice shipped. A slice answers with a sentence about somebody's behaviour — a patient can cancel a check-up. A fragment answers with a sentence about the system — the cancellation endpoint exists. The second test is whether anyone can state a single acceptance criterion for it in the user's language; if the only criteria are about internal structure, it is a fragment.
  • When is it right to leave an item large and not split it at all?
    When the capability is genuinely worthless in parts and will be released as one thing anyway, so slicing buys no earlier feedback and no re-ordering — only coordination cost. Also when the item is unclear rather than large; splitting something nobody understands produces several items nobody understands. In both cases say so explicitly and plan for the item to span iterations rather than pretending it was reduced.
  • The customer insists the whole capability must ship together. Does splitting still help?
    Yes, for the team even when not for the release. Slices integrate earlier, so risk surfaces in week one instead of week six, and each finished slice is real evidence of progress rather than a percentage. What changes is the conversation: you stop offering partial delivery and start offering visible sequence and earlier certainty about whether the whole thing will land.

Slicing a cake: everyone wants a slice with sponge, filling and icing. Nobody wants a plate of bare sponge while somebody else holds all the icing.

saying these in an interview costs you the question

  • Splits by technical layer: data store item, service item, interface item
  • Splits into 'part one' and 'part two' with no independent outcome
  • Slices into design, build and test items
  • Treats splitting as re-sizing rather than re-scoping the item
  • Splits until items are too thin for anyone to demonstrate