03What a plan must answer

A plan is judged by the decisions it supports, not by its level of detail. Whatever its form, it must answer four questions for the people who depend on it.

1. What will we deliver? Not a list of tasks, but capabilities users can adopt. "Red cell units can be shipped to hospitals" is an answer. "The labelling module is 80% done" is not.
2. Roughly when? A range, not a single date. "Between May and July, most likely June" is honest. "15 June" pretends to a precision nobody has.
3. With what confidence? Which parts are safe, which are at risk, and why.
4. What will we do if things change? What gives way first if the work takes longer than expected: the date, or some of the scope.

Forecast, not baseline

Traditional project management answers these questions with a baseline: a plan approved at the start, against which every deviation is measured and corrected. That works when the work is well understood upfront. In software it rarely is, so a baseline turns every new piece of knowledge into a variance to be explained.

An agile plan answers the same questions with a forecast. A forecast is the best current estimate, made from what the team knows and has measured, and updated whenever that changes. A deviation from a forecast is not an error. It is information, and the plan absorbs it.

The companion article, Scrum in Name Only, explains where this difference comes from: both traditions descend from Deming's cycle, but they let different variables move. This article is about the practice.

The distinction matters most in the relationship with stakeholders. A baseline invites them to hold the team to a number. A forecast invites them to follow how the number evolves, and to make their own decisions in time. A forecast that moves a little every sprint earns more trust than a date that stays fixed and then breaks.