Four layers, each 90% done, ships nothing.
Every layer reports 90%. The feature has never once run end to end. Slicing vertically — one narrow journey through UI, API, service, data and deploy — is the difference between progress you can measure and progress you can only claim.
Commit before you look.
Two teams have the same three weeks and the same feature. Team A builds layer by layer — the UI, then the API, then the service, then the schema — and at the deadline every one of those four layers is 90 % complete. Team B builds one narrow journey all the way through all four layers, and nothing else. Who has more of the feature working in production?
Paint a release. See what a user can actually do.
Six candidate journeys across the top, five bands of the stack down the side. Click cells to say what this release builds — or use a preset. A column only counts when every band under it is built, because that is the only way a request gets from a screen to a database and back to a user. Then run integration and find out which bugs you have met and which are still waiting.
The four seams
Each boundary between two bands hides one integration bug. You only meet it once some single journey has both bands built — that is what "crossing the seam" means.
Effort runs left to right. Every bug you have found is marked at the moment you found it; the shaded band on the right is the last stretch before the deadline, where a surprise costs the most.
Cut the story: slice or layer?
The epic is "a customer can reorder something they bought before." A team has broken it into six backlog items. Three of them are thin vertical slices — a real user could complete a real, narrow journey when the item is done. Three are layer tasks — necessary construction work that no user can exercise on its own. Call each one before you see the answer.
Called: 0 of 6 · Correct: 0
Thin slices vs finished layers.
Both plans build the same software in the end. They differ entirely in what you know, and when you know it — and that difference is the whole argument.
| Layer by layer | Thin vertical slices | |
|---|---|---|
| Progress signal | Percent complete per layer, self-reported. | Journeys a real user can complete, counted. |
| Integration risk | All of it, saved up for the end. | Spent on day one, then never again. |
| First feedback | After the last layer lands. | After the first slice ships. |
| If you stop early | Nothing usable. Four unfinished layers. | Fewer journeys — but the ones you built work. |
| What "done" means | My part is finished. | A user did the thing, in production. |
| Feels productive? | Yes — everyone is busy in their own lane. | Less so — the first slice looks trivially small. |
Product slicing vs engineering slicing
Two different calls wear the same word. The MVP Slicer asks which slice to build — which narrow journey proves the riskiest assumption about demand or behaviour. That is the product decision. This module asks how a slice is built so it actually reaches a user — through every band of the stack, deployed and observable. That is the engineering decision. Get the first one right and you build the correct thing; get the second one right and you build it in a way that ships.
"But the foundations have to come first"
Sometimes, genuinely — you cannot slice through a database that does not exist. The honest version of that argument is the walking skeleton: make the first slice deliberately trivial ("show the signed-in user's name") but insist it crosses every real boundary — the real gateway, the real auth, the real database, the real pipeline, the real dashboards. You still get your foundations. You just get them proven instead of assumed, and you get them in week one rather than discovering in week eleven that two of them disagree.
The related lever: batch size
Slicing thin and shipping often are the same discipline seen from two angles. A thin slice is what makes a small batch possible; a small batch is what makes a thin slice worth cutting. Small Batches covers the risk and queueing maths on the other side of that pair.
Where the shape of the cut shows up.
The grid is a toy. These are the rooms it describes — and every one of them is a conversation you have probably sat through.
The 90%-done project
At the same steering meeting, the front-end lead reports 90%, the API lead reports 90%, the platform lead reports 90% and the data lead reports 90%. Everyone is telling the truth. The feature has never run end to end once, and nobody in the room can say so, because the status format has no way to express it. Integration week becomes integration quarter.
The tracer bullet
A team starting on a new cloud stack spends story number one on something embarrassingly small — display the signed-in user's name — but routes it through the real gateway, the real auth, the real database, the real deployment pipeline and the real dashboards. It looks like nothing shipped. It de-risks everything that comes after it, because every seam has now been crossed while the team still has eleven weeks left.
The demo that can't be demoed
The screens are pixel-perfect and the API has a lovely test suite, but the demo runs against stubs because the two have never been connected. The story is marked done. Three sprints later the connection is attempted, the response shape is wrong, dates come back as strings, and the "done" work is reopened.
The team that can't slice
A team tries to adopt vertical slicing and cannot. Every slice needs the front-end team, the back-end team, the DBAs and QA — four backlogs, four sprints, four queues. The technique is not failing; the org shape is. No single team owns a journey, so no single team can finish one.
A slice you can't run end to end isn't a slice — it's an unpaid integration bill.
The technique is easy to describe and hard to hold. It means shipping something that looks trivially small while colleagues ship something that looks impressive, and defending "one journey works" against "four layers are nearly done" in a room that finds the second answer more comfortable. That is the work we do with the engineering teams we coach — turning "we should slice thinner" into a way of working that survives a deadline.
Talk to us about coachingShippable is a minimum, not an average
Four layers at 90% integrate to zero usable journeys. What a user can do is set by the weakest band in the stack, so averaging the layers hides exactly the thing you need to know.
The seams hold the surprises
Integration bugs live at boundaries, and you only meet them by crossing one. A thin slice crosses every seam in week one; a layered plan saves all of them for the week you can least afford them.
Thin and whole beats thick and partial
A narrow journey that really works teaches you more, and risks you less, than a broad capability that has never been exercised. Width is cheap once the skeleton stands.