Splitting Patterns
The Humanizing Work nine patterns and the SPIDR mnemonic that compresses the most useful five. Workflow steps, CRUD, business rules, data shapes, input methods, major effort, simple-then-complex, defer performance, and spike.
Editors publish articles through legal and marketing approval
Editors publish articles through legal and marketing approval
Splitting by component (data model, routing, queue UI, notifications) is horizontal slicing. None of those stories ship a working publish flow on their own; an editor cannot publish anything until the whole stack lands.
Workflow-step splits ship the simplest end-to-end path first, then layer in the intermediate steps. Each slice is a real flow editors can use today.
Users manage their account
Users manage their account
'UI' and 'API' is horizontal slicing. The team builds the bones for all four operations, ships none of them, and product cannot reorder a single piece against its actual urgency.
'Manage' is almost always a clue that multiple operations are hiding behind one verb. CRUD-style splitting names them, often with very different priorities. Sign-up is urgent; close-account can wait until next quarter.
Search flights with flexible dates
Search flights with flexible dates
Splitting into picker UI, API, and results list is horizontal slicing dressed up as a feature breakdown. None of the three stories ships a working search alone, and the three actual rule variations are still hidden inside whichever story claims them.
Three rules, three stories. The team can ship the most-used variant first and learn whether the other two are actually wanted before building them. The split exposes priorities; the lump hides them.
Customers find services near a location
Customers find services near a location
Splitting into geocoder, index, and UI is layer-by-layer work. All three data variations are still bundled into each layer, so country users wait for the neighborhood index to land before anything ships.
Start with the simplest data shape (country), ship it end-to-end, then broaden. You often discover that later variations are wanted less than you assumed and can be deprioritized.
Customers book a meeting time
Customers book a meeting time
Splitting into model, API, UI, and email is layer-by-layer slicing. No customer can book anything until all four ship together; the team cannot trade the calendar picker for an earlier launch even though it is the most expensive piece.
When the UI is doing most of the work, ship the feature with a minimal input first. The booking logic, validation, and confirmation are live on day one. The fancy interface lands in slice two without blocking the core value.
Customers pay with any card type
Customers pay with any card type
Splitting into abstraction, adapters, UI, and receipts is layer-by-layer work. No customer pays anything until all four ship, and the team has built the abstraction without ever feeling the shape of one real payment going through.
The first slice carries the entire infrastructure cost; the rest are nearly free once the pipeline is live. The team estimates Mastercard accurately by the time it lands, because they have learned what the pipeline actually requires.
When to spike
Whenever a story looks big or hard, file a spike to research it before estimating.
When to spike
Reach for a spike only when the other splitting patterns do not apply, that is, when the team genuinely cannot estimate because the implementation approach is unclear. A spike is an admission that you cannot split yet, not a default move.
Spiking by reflex is procrastination dressed as research. Most 'big' stories are not unknowable; they are unsplit. Try the patterns first; spike only when the patterns honestly do not apply.
Spike is the explicit last resort in the Humanizing Work guide. Most stories can be split by workflow, data, rules, or interface before research is needed. Defaulting to a spike costs the team a sprint of value while the eight other patterns sit unused.
Customer exports a report
During refinement: "yeah, but also schedule it." "Yeah, but also email it." "Yeah, also let them filter the columns." All in scope.
Customer exports a report (CSV, current filters)
Captured during refinement and pulled out as their own candidate stories: scheduled exports (EXP-78), emailed exports (EXP-79), per-column selection (EXP-80). Product prioritizes the candidates separately.
Keeping all of it in one story is the cure for productivity. The 13 will not finish in the sprint, and product loses the chance to defer the things they would have deferred anyway if asked.
When the scope keeps growing, capture the simple core as the first story and pull each 'yeah, but also' into its own candidate. Product prioritizes them after; the original story can ship.
Managers see throughput report (sub-second p99 from day one)
Compute the report, build the page, and optimize cold-start latency to under 1s p99. Cache layer included.
Managers see throughput report (correct, possibly slow)
Ship the correct report with a loading spinner. Optimization (caching, pre-aggregation) is RPT-45 and gets prioritized after we see real usage.
Building the cache before the report ships locks in assumptions about hot paths the team has not measured. Half the optimization work is for usage patterns that never materialize.
Ship correct, then ship fast. The optimization story can be sized accurately once you see where the real time is going. Premature optimization wastes estimates and often optimizes the wrong path.