One journey, all the way down
The smallest journey that gives a real result and survives a restart. It starts in the interface, passes through the logic and the storage, and comes back with something saved.
Kill the app and reopen it. If what you did is still there, the slice proved something. If not, you have a demo.
The exclusions do more work than the inclusions. Without them a small journey quietly grows into the whole roadmap. Where the user starts and finishes, what has to persist, the one check that matters, and what is deliberately being left for later.
The order inside the slice
This is the part I had backwards for a long time. I used to build the screen first, because the screen is the bit you can see.
A screen built on invented data has to be rebuilt when the real data turns up. A screen built on storage that already works just plugs in. So the records, the storage and the save-and-recover path now come first, and the first thing I build is deliberately ugly. One button that starts something, one line of text showing its state, then kill the process and check it came back.
Interfaces were what pushed me into this order. The ones I got from a description alone were poor, and feeding in more product documentation did not fix them. They improved once there was something real underneath to build against. I am not sure how much of that was the tool and how much was me asking for something finished instead of something specific. Probably mostly the second.
When the screen can come first
Granted, a hollow screen you can put in front of people buys a better conversation than any description of it. So what settles the order is what the screen is for. The product thinking still comes before either, and which one you are building is a conscious decision.
The failure is building one to learn from and then quietly making it the product, just because binning something that looks finished feels wasteful. Deleting it was the price of the answer. The expensive rebuilds are the other kind, where nothing was decided and the code found out first.
Then widen
Each later slice should extend something that already works. If every addition needs its own separate route through the product, they are not slices of one product any more.
When a slice exposes a wrong assumption, the map gets updated before the system grows. A plan is a starting position, and the work is what tells you where it was wrong.
Further reading
- Principles behind the Agile Manifesto, on frequent delivery and working software as the measure of progress.