13Keeping the plan alive

A release plan is useful only as long as it is true. Keeping it true is a small, regular effort, spread across the sprints.

Re-forecast every sprint

After each sprint, the release chart described in the previous section is updated and the forecast range recalculated from recent velocity. The range should narrow as the release progresses. If it doesn't, that is a signal in itself, usually of growing scope or of unresolved dependencies.

Communicate the forecast

How the forecast is said matters as much as how it is computed.

• Give ranges with a most likely point. "Between weeks 14 and 20, most likely around 17."
• Say what is fixed and what flexes. "The validation date is fixed. These two inventory cases are at risk." That is a decision a stakeholder can act on.
• Report changes early. A customer who learns in week 6 that one capability may slip can adjust its validation plan. One who learns it in week 15 cannot.

Measuring and forecasting have improved

Since agile planning techniques were first described, practice has added better ways to measure. Flow metrics such as cycle time, throughput and work in progress are observed rather than estimated, and they expose the handoffs between teams that slow delivery. Probabilistic forecasting replays a team's past throughput many times to produce statements such as "85% chance of completing by week 18". These improve the accuracy of forecasts. None of them replaces the outer planning horizons: a team that forecasts its next sprint perfectly still needs a release to forecast towards.

Re-planning is not failure

In a predictive project, re-planning means the baseline was wrong. In an agile project, it means the plan is doing its job: absorbing what the team has learned. The real failure is a plan nobody has looked at since the first sprint.