part three · walking skeleton
Walking Skeleton
The smallest end-to-end release that changes the situation.
The walking skeleton is the corpus's most important slice. It is the smallest release that — when shipped — moves the prediction. Anything smaller is a feature; anything larger is a release plan.
End-to-end is the rule
The walking skeleton spans every Epic in the cycle, end to end. It does not fully build any one Epic. It builds the thinnest believable slice through all of them.
For Gal's grading flow:
| Epic | Walking-skeleton story |
|---|---|
| Sign in | Email login |
| Open queue | Queue loads with today's submissions |
| Grade | Open one submission, score it, save |
| Submit | Submission marks the cycle complete |
The skeleton is Gal can grade one submission end to end. It is not Gal's full work, but it is complete work — there is nothing missing for the activity to be performed once.
Why end-to-end
Because end-to-end is the only kind of slice that:
- Surfaces integration risk at the cheapest moment. The expensive moment is when six independently-built features are wired together two days before release.
- Is checkable against the prediction. A partial slice cannot be observed in the field doing the activity; the activity is incomplete.
- Is honest about scope. We have built half of every Epic is a statement that hides what is finished from what is not.
- Lets the team rehearse the chain end-to-end before stakes are high.
The walking skeleton is sometimes ugly. It often has placeholder UI, manual fallbacks, or simplified rules. That is not a problem. It is a complete activity, even if rough.
What the walking skeleton is not
- It is not the MVP. The MVP is what is shipped to users; the walking skeleton may be shipped to a small pilot, or only to staging. They are different artifacts; sometimes the same one.
- It is not a prototype. A prototype is throw-away. The walking skeleton is built on the same code paths the production version will eventually run on.
- It is not the first release necessarily. For some products, the walking skeleton is shipped only internally; release 2 is the first user-visible release.
Building one in practice
The walking-skeleton stories are written first in any cycle. They are pulled into amigos first. They are coded first. They are integrated and shipped first. Other stories — the richness of each Epic — are pulled in after the skeleton is alive.
A cycle that ships the richness of Epic 1 first and then discovers Epic 2 was harder than expected ends up with Epic 1 fully built and Epic 2 partially built. The skeleton-first pattern reverses this.
The skeleton as the prediction's prerequisite
The prediction names the change in the world. The walking skeleton is what makes that change observable for the first time. Without the skeleton, the prediction has nothing to land against.
Concretely: Gal completes a grading cycle in under 15 minutes requires that Gal can complete a grading cycle. The walking skeleton is what makes that possible at all. Subsequent releases tune for time.
When the skeleton can't be small
Some features genuinely have non-trivial floors. A regulated payment integration. A real-time collaborative editor. The skeleton in these cases is still the smallest end-to-end version, but it may be larger than the team would prefer.
The corpus pattern: when the skeleton is large, the cycle is reshaped around it. We are spending this cycle on the skeleton; the richness comes next cycle. The honest naming is what protects the chain from cycles that ship nothing because they tried to ship everything.