Roadmap Delivery Forecasts: Turn History into Honest Commitments

A roadmap date often changes meaning without changing appearance.

Product uses it as a forecast. Engineering sees a target. Sales repeats it as a promise. A customer plans a migration around it. Leadership later treats the same date as evidence of execution quality.

The first forecasting failure is semantic, not mathematical.

A product leader needs separate artefacts for what is likely, what is desired, what cannot move, and what the organisation is prepared to promise.

Historical evidence can then produce a range. It cannot decide how much risk the organisation should transfer to a customer.

Separate five different statements

Use precise labels before discussing a date.

• Estimate: an assessment of effort, size, or duration for defined work.
• Forecast: a probability statement about an outcome, based on evidence and assumptions.
• Target: a desired result or date used to focus action.
• Deadline: a time boundary after which a consequence changes materially.
• Commitment: an accountable promise made to another party, with an accepted cost of failure.

A target can sit earlier than the forecast to create contingency. A deadline can exist without a credible commitment. A forecast can move when evidence changes without anyone failing to honour a promise.

Do not use “confidence” as a substitute for these distinctions. “High confidence in September” says neither the probability nor what becomes available in September.

Product Planning explains how evidence becomes a bounded commitment. This article concentrates on the delivery forecast that informs it.

Define the outcome being forecast

“Development complete” is rarely the roadmap outcome.

If the external statement concerns customer availability, include the path through integration, testing, security or legal review, migration, documentation, support readiness, release control, and observation.

Write a forecast contract:

Decision served
Outcome and completion rule
Scope included and excluded
Reference class
Start and finish events
Current work in progress
Dependencies and owners
Probability range
Assumptions and data limits
Update triggers
Commitment authority

The start event matters. Forecasts beginning at “engineering starts” omit discovery and queue time. Forecasts beginning when an idea enters a backlog mix waiting with active delivery.

Choose the boundary that matches the decision and keep it stable across historical comparisons.

Build a reference class before estimating the item

An inside view decomposes the current plan and estimates its parts. It is useful for exposing work, but teams can make each component look plausible while missing the pattern of past delivery.

An outside view asks what happened to completed work with similar characteristics.

Build the reference class from items that share the factors likely to shape duration:

• completion definition;
• work type and technical surface;
• service or product area;
• dependency pattern;
• release and approval path;
• team topology and material capacity conditions;
• scale of customer migration or data change.

Do not choose only memorable projects. Define inclusion rules first, then take all eligible completed items within a sensible period.

Reference class forecasting has been developed most visibly for major projects. Flyvbjerg’s work applies an outside view to large transport infrastructure and documents severe forecast error in that domain.

That evidence does not quantify software delivery risk. The transferable practice is using observed outcomes from a declared comparison class rather than relying only on the current plan.

Read flow evidence without turning it into a target

The May 2025 Kanban Guide defines work in progress, throughput, work item age, and cycle time as mandatory flow measures.

They answer different forecasting questions:

• Throughput: how many items finish per period?
• Cycle time: how long did completed items take after the chosen start event?
• Work item age: how long has unfinished work already been active?
• Work in progress: how much work is competing for flow now?

It also defines a service level expectation as elapsed time plus probability, normally based on historical cycle time.

The guide does not supply a universal product forecast or target level. A team can improve throughput by splitting work differently or excluding release activities.

Keep the unit and boundary visible. “Eight items per week” is useless when one team counts customer outcomes and another counts technical tasks.

Use completed history for a base distribution. Use current age and WIP to decide whether the active item still resembles that history.

Agile Estimation That Improves Results explains how to make the underlying work comparisons more useful before converting them into a forecast.

Express probability in a form the evidence can support

A range without probability invites readers to choose the date they prefer.

For a simple reference class, report empirical completion proportions:

9 of 18 comparable items completed within 40 elapsed days.
15 of 18 completed within 63 elapsed days.
All 18 completed within 88 elapsed days.

This is more honest than calling 40 days “likely” and 63 days “safe”. The sample is small, and the longest observed duration is not a guaranteed maximum.

For a portfolio containing many similarly sized items, teams can sample historical throughput repeatedly to produce a distribution of completion periods.

For a network of dependent activities, a schedule-risk simulation can sample uncertain durations and recalculate the critical path.

The US Government Accountability Office Schedule Assessment Guide describes Monte Carlo schedule-risk analysis for large programmes.

Its level of modelling is disproportionate for many product decisions. Its relevant discipline is that dependencies, duration uncertainty, correlation, and the required confidence level must remain explicit.

Do not produce decimals the data cannot support. With a thin or unstable reference class, use broader scenarios and state that probability is weakly estimated.

Test scope sensitivity before negotiating the date

Scope and time are not independent inputs.

Write three coherent scope states:

1. Core outcome: the smallest release that satisfies the named customer decision.
2. Expected outcome: the current intended release with ordinary supporting work.
3. Extended outcome: useful additions that can move without invalidating the core.

Forecast each state through the full release boundary.

Avoid moving quality, security, accessibility, data integrity, or recovery work into “optional scope” merely to protect a date. Those are often conditions of a responsible outcome.

A scope reduction is credible only when it removes work and dependencies. Renaming unfinished obligations as follow-up does not change the delivery system.

Model dependency risk as a conditional forecast

“Blocked by another team” is not a probability model.

For each material dependency, capture:

• deliverable and acceptance condition;
• earliest need date;
• owner and authority;
• current state and evidence;
• historical or contractual delivery pattern;
• alternatives if it is late;
• effect on the forecast if each alternative is used.

Then publish conditional ranges.

For example: “The 63-day range assumes certification begins by day 20. If it begins later, the item leaves the current reference class and will be reforecast.”

That statement gives the organisation an earlier decision. It can escalate, change scope, buy an alternative, or accept the later range.

A fictional roadmap forecast

The following example is hypothetical. The dataset and decision are invented to demonstrate the method.

A product team plans a new payroll integration. External customers need enough notice to schedule their own configuration work.

The completion rule is production availability for a controlled customer cohort, including documentation, support readiness, and a verified rollback path.

The team identifies 18 integrations completed under the same release process. Their elapsed durations in days are:

24, 27, 29, 30, 31, 33, 35, 36, 38,
40, 42, 45, 48, 52, 57, 63, 71, 88

Nine of eighteen finished within 38 days, and fifteen of eighteen within 57 days. The small class contains no guarantee beyond its observed conditions.

The current integration has two differences:

• a new external certification step;
• an optional historical-data import.

The team separates scope:

Scope state	Included	Forecast treatment
Core	current payroll records and controlled release	use reference class, adjusted for certification
Expected	core plus scheduled backfill	wider range due to data-volume uncertainty
Extended	historical import and automated reconciliation	separate roadmap decision

Certification has no close internal reference. The provider gives a review window but no service commitment. The team cannot defend one empirical probability for the combined work.

It therefore models two conditions and labels the resulting ranges as scenarios rather than pretending they come directly from the reference class.

If certification starts by day 20, the internal planning range is 6 to 10 weeks. If it starts later, the team reforecasts and the external window does not hold.

The customer communication window is 8 to 11 weeks. It is broader than the internal target and names certification as the review trigger.

The regulatory deadline is 14 weeks. The organisation commits only the core scope, keeps historical import outside the promise, and reserves the final three weeks for customer migration risk.

At day 25, certification has not started. The work item is still inside the historical cycle-time range, but the dependency assumption has failed.

The team lowers the forecast before the code appears late. It offers the customer a manual migration route and moves the historical import to a separate decision.

Nothing in the example guarantees delivery. The method makes the risk transition visible while options still exist.

Update confidence through evidence, not proximity

Forecasts do not become more credible merely because the date is closer.

Define update triggers before work starts:

• scope passes or fails a named decision;
• a dependency meets or misses its need date;
• an active item crosses an age percentile from its class;
• WIP or team capacity leaves the reference condition;
• a test, review, or migration reveals another work class;
• release evidence changes the completion rule.

At each update, preserve the previous forecast, its assumptions, and the reason for change.

Track calibration across comparable forecasts. If ranges labelled as 80% repeatedly contain far fewer outcomes, the labels are not calibrated. If every range is extremely wide, it may protect credibility without supporting a decision.

Translate one forecast for different audiences

Do not give every audience a different truth.

Maintain one evidence core, then expose the relevant contract:

• Internal forecast: probability range, assumptions, scope states, ageing, and dependencies.
• External window: customer-safe availability range and conditions that could change it.
• Deadline: consequence boundary and source of authority.
• Commitment: exact scope, owner, recipient, contingency, and remedy if the promise fails.
• Next review: date or event when evidence will be reconsidered.

Strategic Roadmapping governs bets across teams. Release Management governs exposure once work can reach users.

Forecasting sits between them. It shows what the delivery evidence can currently support before the organisation chooses what to promise.

Sources

• Flyvbjerg: From Nobel Prize to Project Management develops reference class forecasting through large infrastructure projects. Its error distributions do not transfer directly to software delivery.
• The Kanban Guide, May 2025 defines WIP, throughput, work item age, cycle time, and a probabilistic service level expectation. It does not prescribe one product forecast.
• US GAO Schedule Assessment Guide describes schedule credibility, dependency logic, and risk simulation for major programmes. Most product teams need a lighter application.

Read next

• Product Planning: Commit Without False Certainty
• Strategic Roadmapping: Govern the Bets Between Teams
• Turning Product Vision into a Roadmap
• Release Management: Control Exposure, Preserve Options