Slicing the work
A feature described in a spec is usually too big to build and release in one go. Slicing is the craft of cutting it into smaller pieces that can each be finished, released and learned from. Done well, it is the single biggest lever on delivery speed.
Vertical, not horizontal
The instinctive way to split work follows the layers of the system: database first, then the backend, then the interface. Each piece is technically complete, and none of them is usable until the last one is done. Nothing can be released and nothing can be learned until the end.
A vertical slice cuts through every layer but covers only a small part of the behaviour. It is thin, but a real person can use it. The first slice of a reporting export might only handle one report type and one format, but it works from the button to the downloaded file.
Story mapping as a starting point
Jeff Patton’s story mapping is a simple way to find good slices. Lay out the steps a person goes through, left to right: this is the backbone. Under each step, list the things the product could do to support it, most essential at the top. Then draw horizontal lines across the map. Everything above the first line is the first release; the next band is the second.
The first line should sit as high as possible while still letting someone complete the whole journey, however crudely. It is surprising how often the first release turns out to need a fraction of what was originally specified.
Ways to split
When a piece of work still feels too large, a few questions usually reveal a seam:
- By step in the workflow. Can one step ship before the others, with a manual workaround for the rest?
- By rule. Can the simple case come first and the complicated business rules later?
- By data. One type of record, one currency, one language to begin with.
- By user group. Internal users or a small set of customers before everyone.
- By quality. A plain version first, the polished one after it has proved useful — as long as plain does not mean broken or inaccessible.
- Manual behind the scenes. Could someone on the team do part of the work by hand while the automated version is built?
An example
The export feature from the spec note might be sliced like this:
- CSV export of the monthly summary report, current month only.
- Any date range, plus the two other most used reports.
- Totals and formatting that open cleanly in common spreadsheet tools.
- Exports of very large reports handled in the background, with an email when ready.
- Scheduled exports — only if the first four show that people export regularly.
The first slice could ship within days. It will not please everyone, but it will show whether people use export at all, which reports they choose and what they do with the file. Each later slice is informed by what the earlier ones revealed, and the last one may never be needed.
About “minimum viable”
The phrase minimum viable product is used to mean almost anything, from a landing page to a nearly finished product. In slicing, the useful idea is narrower: the first slice should be the smallest thing that is genuinely useful to someone and teaches you something you did not know. Small but embarrassing is fine. Small but useless is not, because it teaches you nothing except that people do not use useless things.
Signs the slices are too big
- Nothing has been released in several weeks of work.
- Slices are described in technical terms (“API layer”) rather than by what someone can do.
- Every slice depends on all the others to be useful.
- Estimates for individual slices vary wildly.
Thin slices only pay off if they actually reach people. The mechanics of that are in Releasing and measuring.