Monte Carlo Delivery Forecasting, Explained

Every software team gets asked the same question: “When will it be done?” And most teams answer it the same way — they estimate each piece of work, add the estimates up, and commit to a date. Then the date slips, trust erodes, and next quarter everyone pads their estimates a little more.

Monte Carlo forecasting takes a different approach: instead of asking people to predict the future, it uses the team's actual delivery history to simulate thousands of possible futures, and reports how likely each finish date is. No story points, no planning poker, no estimation meetings.

The core idea

Suppose your team finished 4, 7, 3, 6, and 5 items over the last five weeks, and you have 30 items left. A naive forecast divides: 30 items ÷ 5 items/week = 6 weeks. But throughput isn't constant — some weeks you ship 7, some weeks 3 — and a single average hides that variability entirely. The average also gives you a date you'll miss roughly half the time, which is not what anyone hearing “6 weeks” expects.

A Monte Carlo simulation instead plays the future out many times:

1. Randomly sample a week from your history (say, the week you finished 3).
2. Subtract that from the remaining work.
3. Repeat until the backlog hits zero, and note how many weeks it took.
4. Run that whole simulation thousands of times.

Each run finishes at a slightly different time, because each run samples a different sequence of good and bad weeks. Collect all the finish times and you get a distribution — and from it, honest statements like:

• 50% confidence: done by August 14 — a coin flip.
• 85% confidence: done by September 4 — a solid commitment.
• 95% confidence: done by September 18 — for dates you can't miss.

That range is the whole point. A single date pretends certainty that doesn't exist; a distribution tells stakeholders exactly how much risk they're accepting when they pick a date to communicate.

Why it works without estimates

Monte Carlo forecasting sidesteps estimation because it measures the system rather than the tasks. Your historical throughput already encodes everything that slows work down — code review queues, interruptions, meetings, rework, that one flaky CI pipeline — because all of it happened while you were finishing those items. Estimates, by contrast, describe work in an idealized world and then collide with reality.

Research on flow metrics has repeatedly found that item sizes in a mature backlog vary less than teams assume, and that counting items forecasts about as well as summing points — with zero estimation overhead. The prerequisite is simply that your backlog items are roughly right-sized: if one “item” is a typo fix and the next is a six-month epic, split the epics first.

What you need to run one

• Completion history: how many items your team finished per week (or per sprint) — ideally 8–12 periods, though even 5–6 gives a usable signal.
• Remaining count: how many items are left in the scope you're forecasting.
• A simulator: a spreadsheet can do it, but a tool that reads your history automatically keeps the forecast honest and current.

Reading the forecast responsibly

A few habits make Monte Carlo forecasts far more useful:

• Communicate at 85%, not 50%. The 50% date is a coin flip; treating it as a commitment is how forecasts get a bad name.
• Re-forecast continuously. Every completed week is new data. A forecast is a living answer, not a one-time ceremony.
• Watch for regime changes. If the team doubled in size or the codebase changed drastically, recent history matters more than distant history.
• Account for scope growth. Backlogs grow. If yours historically grows 20% mid-project, forecast against the grown number, not today's count.

The bottom line

“When will it be done?” deserves a better answer than a padded guess. Monte Carlo forecasting gives you one: a probability-weighted range grounded in how your team has actually delivered, updated automatically as new work completes, and free of the estimation theater that consumes so many team hours.