06Start with a walking skeleton

What should come first in a release plan? The common answer is "the most valuable features". For a new product, or a major new part of one, I believe the answer should be a walking skeleton: the thinnest possible path through the whole product, from one end to the other, that actually works.

Value, risk and learning

Before deciding what comes first, it helps to be clear about what sets the order of a backlog. Four factors matter.

• Value: what the work brings to users or to the business.
• Cost: what it will take. Of two items of similar value, the cheaper one goes first.
• New knowledge: what the work will teach the team about the product or the technology.
• Risk: what doing the work early removes.

Value is the factor teams discuss most, yet it is not one thing. The Kano model, which comes from Noriaki Kano's research on customer satisfaction in the 1980s, distinguishes three kinds.

• Basic expectations. Their absence is unacceptable, and their presence earns no praise. In a BECS: the safety rules, the release rule and traceability.
• Performance features. The more, the better. In a BECS: processing a day's donations faster, or fewer manual entries.
• Delighters. Features users did not ask for but appreciate once they have them. In a BECS, for instance, a view of the day's collections against the hospitals' expected needs.

The distinction changes how each kind is planned. Basic expectations are not traded against features: they bound the scope of every release. Performance features are where most prioritisation discussions take place. Delighters are valuable but can usually wait, which makes them good candidates for the feature buffer.

When several performance features compete, relative weighting makes the reasoning explicit. Each feature is scored on the benefit of having it and the penalty of not having it, and the total is divided by its cost. The result is not precise, but it turns a debate of opinions into a comparison everyone can follow.

Value alone does not set the order: cost, knowledge and risk set it too. For the first release of a product, knowledge and risk dominate. That is the case for the walking skeleton.

Why the skeleton comes first

The term comes from Alistair Cockburn. A walking skeleton is a tiny implementation of the system that performs a small end-to-end function and connects all the main parts of the architecture. It is a working increment and a proof of architecture at the same time.

Scrum in Name Only presents the walking skeleton as the first proof of architecture. Here it is the first step of the release plan. Both describe the same release, seen from two sides.

It deserves first place because value is not the only thing a plan must order. Risk and learning matter as much. The riskiest parts of a product are rarely inside one area. They are at the joins: the integration between areas, the rules that span several of them, the infrastructure everything depends on. A team that builds each area in depth before connecting them discovers those risks last, when they are most expensive. A skeleton discovers them first.

The example: four areas, four teams

Our BECS has more areas than these, but four are enough to show the approach. Each is a coherent part of the business with its own vocabulary and rules, and each is owned by one team.

• Donation. Registering donors, checking their eligibility through a questionnaire, and recording donations.
• Manufacturing. Separating each donation into components such as red cells, platelets and plasma, and any further processing.
• Blood tests. Recording blood group and infectious disease test results, and deciding whether each donation is suitable.
• Inventory. Holding components until they are released, and shipping them to hospitals.

The tempting plan is to give each team its whole area and integrate at the end. The walking skeleton does the opposite: each team builds a very thin slice of its area, and the slices are connected from the first release.

Release 1: the walking skeleton

The release goal: a first-time male donor gives whole blood, and the resulting red cell unit is shipped to a hospital.

• Donation. Male, first-time donors only. Whole blood only. A simple questionnaire, with no deferral.
• Manufacturing. Every unit arrives less than four hours after donation. Only the red cells matter.
• Blood tests. Blood group and a small set of infectious disease markers. All results are negative.
• Inventory. Enter red cell units into stock and ship them.

Each choice removes a source of complexity without removing a boundary. Male donors avoid sex-specific eligibility criteria. First-time donors avoid donation history and minimum intervals between donations. Whole blood avoids apheresis equipment. Negative results avoid, for now, everything that follows a positive one. What remains is the simplest path that still crosses every area.

A working BECS, for one narrow case. This first release is not a mock-up or a technical demonstration. A real donor can be registered, a real donation recorded, separated, tested, released and shipped, with every step traced. It falls far short of what a blood establishment needs: it handles one kind of donor, one kind of donation and one kind of component, and nothing goes wrong. Yet staff in a blood establishment recognise their own work in it immediately, from the donor's arrival to the unit leaving for the hospital. That recognition matters. The people who will use the product can react to it from the first release, and their feedback shapes everything that follows.

What the skeleton proves

The value of release 1 lies less in the four slices than in what flows between them.

• The identity of the unit. A donation receives an identifier at collection, in practice following the ISBT 128 standard, and that identifier travels through manufacturing, testing and inventory. If it cannot travel cleanly through the skeleton, nothing else will work.
• The release rule. A component can be labelled and shipped only when its processing is complete and its test results are acceptable. This rule depends on three areas at once. It is exactly the kind of integration that teams building separately would leave until last, and it is the one that matters most for safety.
• Traceability. From donor to hospital and back, every step is recorded with an audit trail. In a regulated product, this is not a feature to add later. It is part of the skeleton.
• The delivery pipeline. The skeleton is built, tested and deployed the way every later release will be, including the documentation and verification evidence regulation requires.

Once the skeleton walks, the four teams share working interfaces and a common understanding of how a unit moves through the system. From then on, each can deepen its own area with far less coordination.