A2.05 · Decomposition
Splitting what is too big
When a story fails Small or Estimable, the repair is not to shrink the words. It is to split the story into several that each still ship value.
INVEST (A2.03) reads a story and returns a verdict; a No on Small or Estimable means the story is too big for one rung. The fix is a vertical split — by workflow step, business rule, happy and sad path, or operation — that cuts the story into shippable ones without slicing it into horizontal layers no one can demo. Switch the candidate on the right to read whether it fits one rung or must be split. Three dives follow: when to split, the patterns, and vertical not horizontal.
Does the story fit one rung · switch the candidate
A split is a transformation, not a trim
A split takes one story too big for a rung and returns several that fit, with no work lost: the parts sum to the whole. It is not the same as trimming a sentence shorter. Trimming changes the words; splitting changes the number of stories. The trigger is an INVEST failure — a No on Small or Estimable — read before any code is generated, because it is cheaper to cut a story than to unwind a rung.
A good split holds two properties at once. Every part passes Small and Estimable, so it fits one turn of the loop. And every part stays valuable and demoable end to end, so it is a story, not a fragment. The patterns in this module — by workflow step, by business rule, by happy and sad path, by operation — all cut vertically, down through the Portal’s store, domain, and surface, so each slice is a whole capability. The anti-pattern, cutting by horizontal layer, is small but leaves fragments no role can use.
A story too big for one rung is split, not trimmed: several parts that each pass Small and Estimable and each still deliver value, summing to the original whole.
“Manage the whole catalogue” fails Small and Estimable; split by operation it becomes browse, add, edit, and remove a course — four rungs, each demoable on its own.
Splitting turns one story too big for a rung into several that each fit and each still ship — the parts sum to the whole.
The three dives
Each dive takes one move, in the arc signal → pattern → direction: read the signal that a story must be split, apply the four vertical-slice patterns that make the cut, and keep every cut vertical so no slice becomes a fragment. Read them in order — A2.05.1 starts.
When to split
The signal: a story fails INVEST-Small or Estimable, too big for one rung and hiding several behaviours behind one verb. The failing letter names the repair.
Split patterns
The four vertical seams — by workflow step, business rule, happy and sad path, and operation — each producing slices that every one still delivers value.
Vertical, not horizontal
Every slice must stay demoable end to end. Cutting by horizontal layer — DB, API, UI — yields fragments no role can use. The wrong cut versus the right cut.
A2.05 is the how of the split that A2.03 named. With ready, well-sliced stories in hand, the chapter turns to pinning each one down with concrete acceptance examples. Return to the A2 module navigation to continue.
References
The story-splitting tradition this module draws on, and where it connects in the course.
Sources
- Cohn, M. — User Stories Applied — splitting a large story along value into smaller ones.
- Adzic, G. — Specification by Example — slices defined by concrete examples of behaviour.
- Beck, K. — Extreme Programming Explained — small, complete stories as the unit of planning.
Related in this course
- A2.05.1 · When to split
- A2.05.2 · Split patterns
- A2.05.3 · Vertical, not horizontal
- A2.03 · INVEST — the Small / Estimable test this acts on.
- A2.01 · Value, not tasks — the vertical slice each part must stay.
- A2 · Decomposition — the chapter.