Introduction

"When will it be ready?" Every software leader hears that question, and many agile teams struggle to answer it. They can say what will be done by the end of the sprint. They cannot say when the product, or the next version of it, will be usable by the people waiting for it.

In a previous article, Scrum in Name Only, I argued that many Scrum teams have lost the habit of planning beyond the current sprint, and that this loss is one of the main reasons their increments stop adding up to a product. This article is about how to get that habit back. It is not a summary of any method. It sets out why each planning practice exists, how to apply it, and what happens when it is skipped.

The running example

To keep the discussion concrete, I use one example throughout: a Blood Establishment Computer System, or BECS. Blood establishments use these systems to manage the whole chain from the donor to the hospital: registering donors and their eligibility, collecting donations, separating them into components such as red cells, platelets and plasma, testing every donation, and managing the inventory of components until they are shipped to hospitals.

I was CTO of a software vendor in this field. All BECS implement broadly the same processes, so the example draws on that experience without describing any particular product. It is deliberately simplified. The aim is not to specify a BECS but to show how a large, regulated product can be planned and built incrementally, by several teams, starting from a thin first release.

The example suits the subject for three reasons. Its processes form a real chain with no shortcuts, so a first release must cross all of them. It is safety-critical, so some rules cannot be postponed. And it is regulated as a medical device: each new version must be validated by the blood establishment before use, which makes a trusted release timeline a necessity rather than a courtesy.