Scrum, day 40: forecasts and promises

Today's objective: explain what a delivery forecast depends on and communicate a change in confidence early enough for stakeholders to act.

Read alongside: Mastering Professional Scrum, chapter 5, focusing on refinement horizons and release planning. Allow roughly five minutes for this companion, plus the assigned reading.

Ask what the date will be used for

The fictional café owner wants ShiftSwap available at another location before its seasonal staffing change. They ask Elena for a date. A confident answer would be convenient, but the team has not yet examined that café's qualification rules or supervisor arrangements.

Elena first clarifies the decision behind the question. Does the owner need to book training, announce a new process, retire an existing tool, or simply compare options? Some actions can be adjusted easily; others create commitments that are expensive to reverse.

The forecast should be useful for that decision. Its scope and uncertainty need to be understandable enough that the owner can choose an appropriate level of commitment.

Define the thing being forecast

“Ready for the new café” could mean a demonstration, a limited pilot, or dependable everyday use with support and training in place. Those are different outcomes with different work and risk.

The team describes a bounded release: specified employees can arrange eligible exchanges, managers can approve them under the café's agreed rules, and both can understand the final result. It identifies any capabilities that remain outside the initial scope.

Without this clarification, people can agree on a date while imagining incompatible deliverables. Refining the scope of the forecast is often more useful than immediately debating the number of weeks.

Use experience without pretending the future is identical

The Developers can examine recent completion patterns, the size and uncertainty of upcoming work, available capacity, and dependencies. That information supports a forecast better than a date chosen solely because it would be convenient.

Historical results still need interpretation. A sequence of small interface changes may not predict the effort of introducing unfamiliar eligibility rules. A recent Sprint with unusual absences may not represent the next several weeks. The team should explain the similarities and differences it considers relevant.

A forecast is an informed statement under current assumptions. It becomes more useful when those assumptions are visible and revisited, rather than hidden behind a precise calendar date.

Communicate uncertainty in a usable form

The team might offer a range or several scope options instead of a single unconditional date. It should explain the basis for that form. A range invented to sound cautious is not automatically more credible than an invented point estimate.

For example, Elena can describe a likely window for a limited pilot if the café uses the existing eligibility rules, and explain that a different rule set requires investigation before a meaningful forecast. She can also identify the next review point when more evidence will be available.

If probabilities are used, they need a defensible method and relevant data. The team should not attach a confident percentage to a guess merely because probabilistic language appears sophisticated.

Separate an external deadline from a scope assumption

The seasonal staffing change has a real date. That constraint does not make every desired feature feasible by then. The team can examine what useful scope could be ready, what needs to be learned, and what alternatives the café has if the forecast changes.

Perhaps a limited pilot can begin with the existing approval policy. Perhaps training can use the current product while a later improvement remains optional. Perhaps the café should retain its existing process until the required capability is demonstrated.

The useful conversation concerns choices under the constraint. Declaring the date “fixed” while silently allowing quality to fall does not resolve the underlying uncertainty.

Update the forecast when its assumptions change

The team discovers that the new café uses a different qualification rule. That discovery affects scope and may affect the forecast. Elena should communicate it while stakeholders still have choices, not wait until the expected release week.

A useful update explains what changed, which work or decision is affected, what the team knows now, and when it expects better information. It can include a smaller alternative if one would preserve a worthwhile outcome.

Repeatedly moving a date without explanation weakens confidence. Preserving an outdated date despite contrary evidence creates a larger surprise later. Transparent updates help people distinguish ordinary learning from an unmanaged problem.

Make promises deliberately

Organizations sometimes need commitments that go beyond a forecast. If the café plans to retire its old process, the consequences of failure become significant. The people making that commitment need to understand the evidence, contingency, and authority involved.

Scrum does not remove responsibility for such decisions. It creates opportunities to inspect real progress and adapt. The team should resist presenting uncertainty as certainty merely to make the conversation easier, while still doing the work needed to improve confidence.

The product can also provide evidence before the final commitment: a usable pilot, a verified rule set, or a successful operational rehearsal. These can reduce uncertainty more effectively than another round of optimistic estimates.

Rewrite a delivery update

Take a statement such as “the feature will be ready next month.” Add the intended usable scope, the assumptions behind the forecast, the important unknowns, and the next point at which the team will update it.

Identify the stakeholder decision the forecast supports. Explain what they could safely prepare now and what would benefit from waiting for more evidence. Keep the language understandable without hiding the uncertainty in technical terminology.

Reflection: if the forecast changed tomorrow, would stakeholders still have a useful choice? If not, what earlier signal or smaller commitment could preserve one?

Next, day 41 returns to improving the team using what recent work has revealed.