Delivery forecast accuracy: making commitments people can trust

"When will it be done?" is the question every technology leader dreads, because the honest answer is "we don't know exactly," and the expected answer is a date. So a date is given, the date becomes a promise, and the promise is broken. After a few rounds of this, stakeholders stop trusting any forecast at all.

Delivery forecast accuracy isn't about guessing better. It's about forecasting from evidence, being honest about uncertainty, and checking how good your forecasts actually are.

Why forecasts go wrong

• Estimates become commitments. An early estimate, made with little information, is written into a plan and treated as fixed.
• Plans assume ideal capacity. Forecasts ignore unplanned work, leave and shared specialists. See IT capacity planning.
• Scope grows silently. The forecast was for the original scope; the work now includes 40 percent more.
• Dependencies aren't included. The team's part is on track; the integration it depends on isn't. See Cross-team dependencies.
• Nobody measures accuracy. Without a record of past forecasts against actuals, there's no way to improve.

Forecast from completed work, not planned work

The most reliable predictor of what a team will finish is what it has finished before. Use completed throughput (items finished per week or sprint) or completed velocity, not planned figures.

For example, if a team has completed between 6 and 10 items per two-week sprint over the last eight sprints, and 48 items remain, the forecast is roughly 5 to 8 sprints, or 10 to 16 weeks. That range is far more honest than a single date.

Express uncertainty as a range with confidence

Replace "it will be done on June 30" with something like:

"We expect to finish between mid-June and mid-July. We're about 85 percent confident it will be done by July 15."

Ranges feel uncomfortable at first. But they give stakeholders what they actually need: a sense of risk. And they're more often right, which builds trust.

As work progresses, the range should narrow. If it widens, that's a warning sign worth discussing.

Separate the forecast from the commitment

A forecast is your best evidence-based view of what will happen. A commitment is a promise made to stakeholders. They should be connected but not identical.

Commit to a date near the conservative end of the forecast range, and keep forecasting as you go. When the forecast moves past the commitment, that's the moment to renegotiate, early and openly, not the week before the deadline.

Track scope change explicitly

Record scope at commitment and track every addition. When a stakeholder asks why the date moved, "we added 15 items since commitment" is a factual answer that doesn't require anyone to be wrong. It also turns scope growth into a decision: add the scope and move the date, or defer the scope.

Measure forecast accuracy

Forecast accuracy is simple to calculate:

Accuracy = actual duration ÷ forecast duration

A value of 1.0 is perfect; 1.3 means the work took 30 percent longer than forecast. Track it across completed initiatives:

Patterns tell you where forecasting is weakest. If large platform initiatives consistently run 50 percent over, future forecasts for similar work should account for that. This is the Validate delivery step of PROVE in practice: improving the reliability of commitments by learning from evidence.

What leaders can do

• Ask for ranges, and accept them. If you demand a single date, you'll get one, and it will be wrong.
• Reward early warnings. The team that says "we're at risk" six weeks out deserves thanks, not blame.
• Review forecast accuracy as a portfolio measure. Not to grade teams, but to calibrate future decisions.

How Aizu helps

Aizu's delivery confidence views put capacity and delivery signals next to scope, dependencies and risk, so a commitment can be examined before it slips. Delivery evidence from Jira and Azure DevOps, including completed sprint velocity, sits alongside the business context, and the decision record keeps the original commitment and its assumptions for comparison. Related: Leading indicators of project trouble.