04Detail near, coarse far

The holiday showed the principle: the destination is decided months ahead, the third day over breakfast. The reason is not laziness. It is that our knowledge improves over time, and detail planned before the knowledge exists is wasted.

The cone of uncertainty

In 1981, Barry Boehm published an observation that every software leader should know. Estimates made at the very start of a project can be wrong by a factor of about four in either direction, a range of roughly sixteen to one. As requirements, design and code take shape, the range narrows, until it disappears when the product is finished. Steve McConnell later named this pattern the cone of uncertainty.

The cone explains most of agile planning. Detailed plans made at its wide end are mostly fiction, so detail should follow knowledge rather than precede it. A single date hides where a project stands in the cone, so forecasts are given as ranges. And because the cone narrows as work progresses, the forecast must be updated as it narrows.

The cone does not narrow by itself

McConnell insists on a point that is often missed: the cone is a best case. Uncertainty does not shrink because time passes. It shrinks because decisions are made and risks are resolved. A project that defers its hardest questions, above all the integration of its parts, stays at the wide end of the cone while its plan suggests otherwise. As far as I know, studies of real projects, notably Todd Little's in 2006, found that uncertainty often remains high far longer than the textbook shape suggests. The cone is a model of what happens when uncertainty is worked on deliberately, not a law.

This is the strongest argument for ordering work by risk. In the BECS example, the walking skeleton described in section 6 resolves the uncertainty about the unit's identity, the release rule and traceability in the first release. A project that builds each area in depth and integrates at the end discovers the same uncertainties last, when the plan has no room left to absorb them.

[embedded content: the cone of uncertainty · conceptual]

When risks are resolved early, the range of possible outcomes narrows steadily. When integration is deferred, the range stays wide for most of the project, and the plan discovers the truth only at the end.

The practical consequence is to plan at several horizons, each with the level of detail its knowledge supports. Mike Cohn describes six nested levels, his planning onion: strategy, portfolio, product, release, sprint and day. Scrum in Name Only shows the whole onion. This article uses only the four inner levels. Strategy decides which markets and products the organisation pursues; portfolio decides which products are funded and how many teams each receives. Both are decided by executives on a yearly or quarterly cycle, and both are inputs to product planning rather than part of it: they settle whether a product exists and with what capacity, not how its work is ordered and forecast.

Scrum's events cover the two inner horizons. The outer two must be provided by the organisation, and in many Scrum teams nobody provides them.

The horizons in the example

For a BECS vendor, the product horizon might be a goal such as "a complete system for blood establishments in our market within three years". The release horizon is the next version a customer can validate and adopt, for instance "whole blood donations processed from donor to hospital". The sprint horizon is a set of stories towards that release: registering a first-time donor, recording a donation, labelling a red cell unit. Each level is refined as it comes closer, never all at once.

An idea PMBOK already had

None of this contradicts traditional project management. The PMBOK Guide calls it progressive elaboration: a plan is refined continuously as more detailed information becomes available. For the schedule, it describes rolling wave planning: near-term work is planned in detail, later work only at a high level, and each wave is detailed as it approaches. Agile planning did not invent the principle. It applies it at every sprint, with the people who do the work.