Forecasting Delivery Dates Without Estimates: Monte Carlo, Explained

Introduction

Most writing about Monte Carlo forecasting is aimed at agile coaches running transformations at companies with a portfolio office. This one is aimed at someone who has to tell a client on Friday when the integration will be ready, and who does not want to spend Thursday in an estimation meeting to produce a number everybody privately discounts.

The technique sounds statistical and intimidating. It is neither. If you can count how many items your team finished in each of the last twelve weeks, you have everything you need, and the mental model fits in a sentence.

How Does Monte Carlo Forecasting Work for Software Teams?

Monte Carlo forecasting takes your team's actual delivery history, replays it in random order thousands of times, and records how long each replay takes to finish the work in question. The result is not a date but a distribution of dates, from which you read off confidence levels: this finishes by the 9th half the time, by the 20th eighty-five percent of the time.

No item is estimated. The only inputs are how many items remain and how many the team has finished per week historically.

Why a Single Date Is Always Wrong

When someone gives a single-date estimate, they are stating one outcome from a distribution of possible outcomes and dropping the distribution. The date they pick is usually near the optimistic end, because the estimate is constructed by imagining the work going as planned, and the ways it can go wrong are numerous and individually unlikely while collectively near-certain.

Everyone involved knows this. The stakeholder applies a private multiplier, the team applies a private buffer, and both distortions are invisible to the other party. The negotiation happens in the dark.

A forecast with confidence levels puts the distribution back. It does not make the uncertainty go away, it makes it explicit, which is the only honest thing you can do with uncertainty and the only thing a stakeholder can actually plan around.

What the Simulation Actually Does

Here is the whole algorithm, with no statistics vocabulary.

You have twelve numbers: the count of items your team finished in each of the last twelve weeks. Say they are 5, 7, 4, 6, 3, 8, 5, 5, 9, 2, 6, 6. You have twenty-two items left to deliver.

1. Pick one of the twelve numbers at random. Say you draw 4. Subtract it: eighteen items left, one week elapsed.
2. Pick again, with the same twelve available. Say 8. Ten left, two weeks elapsed.
3. Keep going until the remaining count hits zero. Record how many weeks that took.
4. Do the whole thing ten thousand times.

Now you have ten thousand answers. Sort them. The number in the middle is your fifty percent date: half the simulated futures finished by then. The number 85% of the way up the sorted list is your eighty-five percent date.

That is it. It is a spreadsheet exercise, and the reason it works is that drawing randomly from your real history reproduces your real variability, including the bad weeks, which is exactly what a human estimator leaves out.

What to Say to a Stakeholder

The output is only useful if you can say it out loud without sounding evasive. The failure mode is presenting three dates and letting the other person conclude that you do not know.

Say this:

"Based on the last three months of our actual delivery, there's an eighty-five percent chance this is done by the 20th. I'd plan around the 20th. There's a coin-flip chance it lands by the 9th, but I wouldn't promise anything to your customer based on that."

Three things make that work. You lead with the number you are recommending they use, rather than with the range. You attach it to evidence, which is the part a single estimate never has. And you name explicitly what the optimistic date is and is not good for, which pre-empts them anchoring on it.

Pick one confidence level as your house standard and use it consistently. Eighty-five percent is a reasonable default for commitments. Switching between levels depending on how the conversation is going is how you lose the credibility this technique buys you. See client communication.

The Data You Need, and the Ways It Goes Wrong

Eight to twelve weeks of throughput history is enough. Fewer than eight and the sample does not contain enough bad weeks to be realistic. More than about six months and you are drawing from a team that no longer exists.

Three things break the forecast:

• Scope growth. The simulation assumes twenty-two items. If discovery adds eight more, the forecast was never wrong, it was answering a different question. Track how much the item count grows per week and include that as a second random draw if it is significant.
• Team change. History from a team of six does not forecast a team of four. After a change, wait for four weeks of new data rather than blending.
• Wildly variable item size. The method assumes remaining items resemble historical items. If the twenty-two remaining are all epics and history is mostly small fixes, split them first. See breaking work into tasks.

Where FlowBoard Fits

FlowBoard does not run Monte Carlo simulations. What it gives you is the input: weekly throughput, derived from completion events with no sizing step, which is the only data the method needs.

Twelve numbers into a spreadsheet, one column of random draws, and you have the forecast. If that sounds like too much, the crude version is genuinely better than an estimation meeting: remaining items divided by average weekly throughput gives you the fifty percent date, and multiplying it by 1.5 approximates the eighty-five percent one for most teams.

What to Do This Week

Next time someone asks for a date, count the remaining items, pull your twelve weekly throughput numbers, and answer with a confidence level instead of a date. You will not need the full simulation to notice that the honest answer is later than the one you were about to give.

Then read no estimates in practice for the cases where you should still just estimate, and throughput for the metric this all rests on.