Splitting Patterns — Reference

Nine ways to cut a big thing

Print this. When a piece of work is too big and it isn't obvious how to cut it, run down the list in order and stop at the first pattern that fits.

Source The nine patterns and their order come from the Humanizing Work Guide to Splitting User Stories (Richard Lawrence & Peter Green). The evaluation criteria at the bottom are from the same guide and from Bill Wake's INVEST.

The patterns, in the order to try them

#	Pattern	Cut it by…	Smells like this when it fits
1	Workflow steps	Taking one step of a multi-step process end-to-end, and faking or deferring the rest.	The story describes a journey: "sign up → verify → onboard → invite team".
2	Operations (CRUD)	Splitting create / read / update / delete into separate slices.	The word "manage" appears. "Manage projects" is four stories wearing a coat.
3	Business rule variations	Shipping one rule, deferring the other rules that act on the same feature.	Lots of "except when…", "unless the user is…", "for annual plans…".
4	Variations in data	Supporting one data type, format, locale, or source first.	"…for any file type", "in all currencies", "from any provider".
5	Data entry methods	Building the crudest working interface first; fancier input later.	The hard part is the widget (drag-drop, autocomplete), not the behaviour behind it.
6	Major effort	Doing the first case that requires the infrastructure, then the cheap ones that reuse it.	"Pay by card, PayPal, or invoice" — the first payment method costs 80% of the work.
7	Simple / complex	Extracting the plain-vanilla scenario, deferring every edge case as its own slice.	You catch yourself saying "well, it also has to handle…".
8	Defer performance	Making it work, then making it fast / scalable / pretty.	The requirement has a number in it: "in under 200ms", "for 10k rows".
9	Break out a spike	Timeboxing an investigation, then splitting properly with what you learn.	You genuinely cannot see the shape of the work. Last resort — a spike ships nothing.

Pattern

Cut it by…

Smells like this when it fits

Workflow steps

Taking one step of a multi-step process end-to-end, and faking or deferring the rest.

The story describes a journey: "sign up → verify → onboard → invite team".

Operations (CRUD)

Splitting create / read / update / delete into separate slices.

The word "manage" appears. "Manage projects" is four stories wearing a coat.

Business rule variations

Shipping one rule, deferring the other rules that act on the same feature.

Lots of "except when…", "unless the user is…", "for annual plans…".

Variations in data

Supporting one data type, format, locale, or source first.

"…for any file type", "in all currencies", "from any provider".

Data entry methods

Building the crudest working interface first; fancier input later.

The hard part is the widget (drag-drop, autocomplete), not the behaviour behind it.

Major effort

Doing the first case that requires the infrastructure, then the cheap ones that reuse it.

"Pay by card, PayPal, or invoice" — the first payment method costs 80% of the work.

Simple / complex

Extracting the plain-vanilla scenario, deferring every edge case as its own slice.

You catch yourself saying "well, it also has to handle…".

Defer performance

Making it work, then making it fast / scalable / pretty.

The requirement has a number in it: "in under 200ms", "for 10k rows".

Break out a spike

Timeboxing an investigation, then splitting properly with what you learn.

You genuinely cannot see the shape of the work. Last resort — a spike ships nothing.

The trap Pattern 9 is where an unpracticed slicer goes first, because it feels like progress and requires no decisions. It is listed last for a reason: a spike produces knowledge, not a working increment. Use it only when patterns 1–8 genuinely don't apply.

Is the split any good?

Test	Ask
Throwaway test	Could I deprioritise or bin one of these pieces and still ship something worthwhile? If no piece is droppable, you cut along the wrong line — you produced steps, not slices.
Vertical test	Does each piece touch every layer it needs to be observable? "Build the schema" is not a slice.
Balance test	Are the pieces roughly the same size? Prefer a 2-2-2-2 split over a 5-3. Lopsided splits usually mean one piece is still hiding a whole story inside it.
Testable test	Can you state, in one sentence, what you'd check to know the piece is done? If not, it isn't understood well enough to start.

Test

Ask

Throwaway test

Could I deprioritise or bin one of these pieces and still ship something worthwhile? If no piece is droppable, you cut along the wrong line — you produced steps, not slices.

Vertical test

Does each piece touch every layer it needs to be observable? "Build the schema" is not a slice.

Balance test

Are the pieces roughly the same size? Prefer a 2-2-2-2 split over a 5-3. Lopsided splits usually mean one piece is still hiding a whole story inside it.

Testable test

Can you state, in one sentence, what you'd check to know the piece is done? If not, it isn't understood well enough to start.

Two sentences to remember

Slice on the business situation, not the technology. Cockburn's rule from Elephant Carpaccio — the moment you start cutting by layer (backend / frontend / API), you have stopped slicing and started scheduling.

The good split is the one that lets you throw a piece away. That is the whole point of small batches: cheap discovery that you didn't need it.