Giving a single delivery date implies 100% confidence that the work lands on that day and 0% on every other. That certainty was never there. Naming one date just hides where it went.
People are more comfortable being wrong than uncertain. A date that turns out to be incorrect is accepted as a normal part of project life. A range communicated up front generates immediate pushback, even though it is the more accurate description. The range existed before anyone named a date. The point estimate was a way of avoiding the conversation about it.
A probability forecast pairs a delivery date with a confidence level. “We will ship by week 10” implies 100% certainty. “85% confident by week 10” puts the remaining risk on the table — the team is naming the uncertainty rather than hiding it in a buffer.
How Monte Carlo simulation works
Monte Carlo simulation answers one question: given a backlog of N items and a record of historical weekly throughput, how many weeks will it take?
Each run works the same way. A week is picked at random from the historical record and that week’s completion count is added to a running total. When the total reaches the target, the run ends and the week count is recorded. That one run is a single simulated future — the team completing the backlog with one particular sequence of sampled weeks. It might have drawn a run of productive weeks and finished early, or hit slow ones and taken longer. A single result tells you nothing about which is more likely.
Running the simulation 10,000 times solves this. Each run is independent, drawing its own random sequence from the historical data. By the law of large numbers, the proportion of simulations finishing in any given week converges on the true probability of finishing that week as the run count grows. The P50 is the week where half of all simulations completed; the P85 is where 85% landed. The spread between them is the actual variability in the process — some simulated teams were luckier than others, and that range is real.
The table in the simulator shows 16 weeks of observed weekly completions. Run one simulation to see the sampling in action: each step picks a row at random, adds its count to the running total, and repeats until the target is reached. Fast-forward to 10,000 runs to see the distribution emerge.
The data you already have
The MCS needs two inputs: the number of items to complete and a record of historical weekly throughput. Both are already in the issue tracker — no estimates, no planning sessions.
If the backlog mixes work types with different completion rates, split the throughput history by type and sample from the matching set. Features and incidents close at different rates; mixing them in one sample dilutes both. The simulator uses a single throughput stream; real forecasts gain accuracy by matching the sample to the type of work being forecast.
What historical data captures
Historical weekly throughput reflects everything that affected the team during the period it covers. A dependency stall waiting on another team, an unplanned incident pulling focus — all of it shows up in how many items closed that week. The data does not need to be cleaned or adjusted for those events. They are part of the real delivery rate.
Point estimates don’t capture any of this. They are made before the work begins, before WIP climbs, before the unplanned incident lands. The moment conditions change, an estimate built under different ones is describing a world that no longer exists. Historical throughput recalibrates automatically because it is measured from the team as it ran — carrying the real interruptions and WIP levels with it.
Reading the output
The histogram shows how many of the 10,000 simulations completed in each week.
P50 is the median: half of simulated runs complete by this week. It is not a safe commitment — it is as likely to be late as early. Using P50 as a delivery date means roughly half of similar work will miss it.
P85 is where most teams find their commitment point. A P85 date is late roughly one time in six, which is an acceptable risk for many delivery contexts. This is the number to put in front of a stakeholder.
P95 is conservative: late one time in twenty. Worth using when the cost of a late delivery is particularly high — a hard external deadline, a contractual obligation.
Which confidence level to commit to is a business decision. The forecast makes the trade-off visible; the right people can make it explicitly. Use the simulator above to see how increasing the backlog shifts each percentile — and how the gap between P50 and P95 widens as the item count grows.
Wide tails are informative
The historical data in the simulator comes from a team with high throughput variability — 0 items in some weeks, 8 in others. That spread produces wide forecast ranges.
A simulation returning a completion window that spans many weeks is not a failure of the method. It is an accurate description of a team with that variability. The same estimate given as a single date would have landed somewhere in the middle — communicated with false precision. The discomfort of a wide span was not created by the forecast. It was created by the process variability that the forecast made visible.
A team with consistent throughput — where weekly counts cluster in a narrow band — produces tight forecast ranges. The width of the range is a direct read-out of how reliable the process is.
Takeaways
- — A single delivery date claims 100% confidence. The range was always there; a probability forecast surfaces it.
- — MCS needs only historical weekly throughput and a target item count. Both are already in the issue tracker.
- — Historical data captures the real process. WIP levels and interruptions are already in the record because they affected when tickets closed.
- — P50 is as likely late as early. P85 is the standard commitment point. P95 is for high-cost deadlines.
- — Wide tails describe a variable process. The width is accurate information about forecast reliability.