Delivery Planning and Forecasting

Stakeholders need to plan: marketing launches, customer commitments, hiring, and budgets depend on when engineering work will land. Engineering managers and tech leads are asked for dates constantly, and the usual approach — estimate every task, add them up, subtract from the calendar — produces confident dates that slip, followed by pressure, overtime, and lost trust.

Reliable forecasting starts from real capacity and historical data, not wishful plans. Teams that measure how much work they actually finish per week can forecast with simple simulations, express results as dates with confidence levels, see dependencies and risks early, and re-forecast as the work reveals itself. The goal is not perfect prediction but honest information that lets the business make good trade-offs.

TL;DR

Quick Example

Forecasting with Monte Carlo simulation from the last twelve weeks of throughput:

Dividing 40 items by the average of 4.8 per week suggests about 8 weeks — a coin flip. The simulation shows the plan needs 10 weeks for reasonable confidence, or a smaller scope.

Core Concepts

Capacity

Throughput-based forecasting includes these effects automatically, because history already reflects them — which is another reason to prefer it over summing task estimates.

Slicing and Dependencies

Forecasts work best with small, similar-sized items (often a few days each); split large items and treat unknown-size items as risks to investigate. Map dependencies on other teams, vendors, approvals, and infrastructure; the critical path — the longest chain of dependent work — determines the earliest possible date regardless of team size. Start dependency-heavy and risky work early. See Software Estimation and Change Impact.

Probabilistic Forecasting

Use recent, representative history (the last 10–20 weeks), keep item sizes consistent, and account for scope growth — backlogs typically grow as work is discovered. See Kanban and Scrum vs Kanban.

Roadmaps With Confidence

Tie roadmap items to outcomes, not just features. See Product Roadmaps and Outcome Metrics.

Milestones and Buffers

Place milestones at points where you learn something real — integration complete, first customer using it — rather than at document completions. Keep buffers visible at the project level instead of padding every task, and consume them consciously.

Tracking and Re-Forecasting

A burn-up chart shows completed work rising toward a scope line; unlike a burn-down, it makes scope growth visible as the line moves up. Re-run forecasts weekly or at each milestone with updated throughput and remaining scope, and communicate changes as soon as they appear: "the 85% date moved from 12 to 19 November because scope grew by 9 items; options are A, B, or C." Track delivery health over time with measures such as lead time and deployment frequency; see DORA Metrics.

Best Practices

Forecast From Data, Not Hope

Use measured throughput and simulation, and show the confidence level with every date.

Make Scope Explicit and Negotiable

When forecasts miss targets, present scope and sequencing options rather than compressing estimates.

Surface Dependencies Early

Map cross-team and external dependencies at the start and track them on the plan.

Re-Forecast Routinely

Update forecasts on a cadence and announce changes early, with causes and options.

Common Mistakes

Planning at 100% Capacity

Average-Based Dates

Hiding Scope Growth

FAQ

How do I forecast without estimating every task?

Measure how many items the team finishes per week, keep items reasonably small, and simulate future weeks by sampling that history to produce dates or quantities with confidence levels.

What is a Monte Carlo forecast?

A simulation that repeatedly samples plausible outcomes — such as weekly throughput — to build a distribution of possible completion dates or totals, from which you choose a confidence level.

How far ahead should teams commit to dates?

Commit to dates for near-term work with reasonable certainty; for later horizons, share priorities and themes rather than dates.

What is a burn-up chart?

A chart showing cumulative completed work rising toward a scope line, which reveals both progress and changes in scope over time.

What should I do when the business needs an earlier date?

Show the forecast and options: reduce or defer scope, change sequencing, remove dependencies, or accept lower confidence — and make the trade-off explicit.

Related Topics

References