07Grow the skeleton

A skeleton that walks is the beginning, not the product. Each following release widens every area a little, rather than completing one area while the others wait. Every release remains an end-to-end increment that a blood establishment could, in principle, validate and use.

Release 2: a realistic day of whole blood collection

The release goal: handle a realistic day of whole blood collection, including donations that prove unsuitable.

• Donation. Add female first-time donors and a fuller questionnaire. Still whole blood only.
• Manufacturing. Handle more separation cases, and units that arrive between four and eight hours after donation or later, since the time before processing determines what can be prepared from a unit.
• Blood tests. Add more tests, and handle positive results.
• Inventory. Add more cases, such as components held in quarantine and components reaching their expiry date.

The goal gives the four teams a shared reason to prioritise. When a team must choose between two stories, the question is which one brings "a realistic day" closer.

When the flow reverses

Positive test results change the shape of the system. Until now, everything flowed in one direction: from donation, through manufacturing and testing, to inventory. A confirmed positive result sends information backwards. The donor must be deferred, which concerns the Donation team. The other components from the same donation must be quarantined, which concerns Inventory. Later releases will go further back in time, with lookback on the donor's earlier donations.

This is how circular dependencies appear. Donation feeds Blood tests, and now Blood tests needs to act on Donation. If Blood tests calls Donation directly, and Donation calls Blood tests, neither team can change or deliver without the other, and every release turns into a joint negotiation.

The way out is to change the direction of the dependency. Blood tests does not tell the other areas what to do. It publishes a fact: "a positive result has been confirmed for this donation". Donation subscribes to that fact and defers the donor. Inventory subscribes and quarantines the components. Blood tests depends on neither of them, and either can change how it reacts without affecting the others. A planning problem, two teams blocking each other, is solved by a design decision.

[embedded content: the four areas of the example · forward flow and one published event]

The unit and its samples flow forward. The positive result travels back as a published event, so Blood tests depends on neither Donation nor Inventory.

Later releases

Later releases continue the same pattern, each with its own goal:

• repeat donors, with donation history and minimum intervals between donations;
• permanent deferrals;
• apheresis donations: plasmapheresis and plateletpheresis;
• autologous donations, where a unit is reserved for the donor's own later use;
• further processing of components;
• lookback on earlier donations after a positive result.

A real BECS also covers areas this example leaves out entirely, such as donor recruitment, mobile collection sessions, hospital services and haemovigilance. They follow the same logic and add nothing to the argument.

The table reads in two directions. Down a column, every release crosses all four areas. Along a row, each team's scope widens step by step. No team ever works for months on a part nobody can use.

A note on vocabulary. The way this example divides the product, into business areas each owned by one team and communicating through published facts, is what Eric Evans calls strategic design in Domain-Driven Design (2003). The areas are bounded contexts, and the published facts are domain events. A future article looks at how domain-driven design and Scrum reinforce each other.

The BECS example is deliberately simplified. It illustrates a way of planning, not the specification of a blood establishment system.