Monte Carlo Forecasting for Software Delivery Dates

Monte Carlo forecasting answers "when will this be done?" by resampling how much work your team finished recently and reporting a range of dates instead of one. A single date hides the spread. What you want is a set of percentiles: a date you beat most of the time, a date that is plausible, and a date you should not promise past.

What Monte Carlo forecasting is

Monte Carlo forecasting turns a history of completed work into many possible futures, then counts how often those futures land on a given day. You resample the weekly or daily throughput you already recorded, keep adding samples until the remaining work is covered, and write down the date that run finished. Do that a few thousand times and the pile of finish dates is your forecast.

For a delivery team, the random input is the number of items you actually finished in each recent period. It is not an invented rate of story points per developer.

Multiplying average throughput by remaining items gives you one number, and it assumes every week is an average week. Real weeks vary. Some are thin because of holidays, incidents, or an item that sat in progress. Some are fat because several small items closed together. Sampling the real weeks keeps that lumpiness, while averaging it away is how teams end up publishing a date that was never likely.

Read the result as a distribution under current assumptions. If scope or throughput changes, run it again.

Why one delivery date keeps missing

Launches and contracts need a day. The mistake is treating that day as a property of the work, like a file size, when it comes from a process that varies.

• Throughput moves week to week even when the team and the codebase stay the same.
• Remaining scope is a count of unequal items, and it changes after the estimate.
• The day someone asked is often earlier than the day work started, so the stakeholder's clock runs longer than the one the team measured.

A range shows how much those facts have already moved the date. If the 50th and 95th percentiles are three days apart, you can plan tightly. If they are six weeks apart, the backlog is too noisy to pin to a Thursday.

Teams that track cycle time and lead time already have half the raw material. Cycle time tells you how long an item takes once it starts. Throughput tells you how many items finish per period. A delivery forecast here usually samples throughput, because the question is how many more items fit before a date. Wild cycle times show up as wild throughput, and you fix that in the process rather than with a harder average. Why delivery estimates miss covers the gap between a gut estimate and a forecast built from history.

Inputs you need before you simulate

You need three inputs, and all three have to be honest.

A throughput history. Count items finished per week (or per day). Fifty to a hundred recent periods is a comfortable sample. With fewer than about twenty, the draws mostly replay the same handful of weeks. Prefer completed items over points unless your points are stable, and drop any stretch where the team, the product, or the definition of done changed.

A remaining-work count, in the same unit. "The epic" is not a unit, but a list of open tickets is. If tickets will split, split them first or accept that the count is low.

A calendar. If weekends produce no finished work, simulated weekends should not consume throughput. Put public holidays in the calendar too.

Leave out target velocity and any staffing plan you have not actually worked under. If headcount is about to change, wait for a short history from the new team, or run two forecasts and label which history each one uses.

How a Monte Carlo simulation for forecasting runs

On a backlog, a monte carlo simulation for forecasting is a short loop.

1. List historical throughputs, one number per period. For example: 4, 7, 3, 8, 5, 6, 2, 9 items per week.
2. Set the remaining item count. For example: 40.
3. Start at the next delivery day. Draw one historical week at random, with replacement, so the same week can come up more than once. Subtract it from the remainder and step one week forward. Repeat until the remainder hits zero or goes below, then record the date.
4. Do this about 2,000 times. More runs smooth the chart, but they do not add information the history lacks.
5. Sort the dates. The middle date is the median. The date 85% of the way down the list is the day by which 85% of the simulated futures had finished.

Drawing with replacement asks whether the coming weeks could look like random weeks you have already had, rather than replaying last quarter in order. A burn-down plots one path. The simulation keeps every path and shows how far apart they spread.

A worked example with made-up numbers

These figures are illustrative so you can check the arithmetic. They are not a benchmark.

Weekly throughput for the last ten weeks: 5, 6, 4, 8, 5, 7, 3, 6, 5, 9. That sums to 58, an average of 5.8 items per week. Remaining scope is 29 items. The forecast uses whole weeks starting Monday 6 October, and weekends are not delivery days.

The naive date is 29 / 5.8 = 5.0 weeks, which lands in the week of 9 November. That path assumes every future week is the average week. The history contains both a 3 and a 9, and the average never draws either one.

One simulated run might draw 4, 9, 5, 6, 3. After five weeks the sum is 27, so a sixth draw of 5 finishes the 29, and that run lands in week 6. Another draws 8, 7, 9, 6 and finishes in week 4. Another draws 3, 4, 3, 5, 4, 5, 6 and needs seven weeks. Repeat that 2,000 times. In this illustration the sorted results look like this:

Percentile	Simulated duration	Illustrative end
50th	5 weeks	week of 9 November
70th	6 weeks	week of 16 November
85th	7 weeks	week of 23 November
95th	8 weeks	week of 30 November

Half the futures finish in the same week the average suggested, which is common when the history is roughly symmetric. The 50th is still not your planning date. An 85th-percentile date in the week of 23 November means 85% of these runs finished 29 items by then, assuming future weeks resemble those ten and nobody adds scope.

From the median to the 95th is about three weeks on a five-week job. That is the buffer the history already implies. Putting the launch on the average and "adding a few days" does not match the sample.

If four items arrive, the remainder becomes 33. Re-run the simulation instead of stretching the old date by 4 / 5.8. A few unlucky draws can move the 85th percentile by more than a week.

Plan an external launch on the 85th, mention the 50th internally as the early case, and treat a result past the 95th as a sign that the item count or the history is wrong.

How to talk about the range

Put the percentile in the same sentence as the date. "85% of simulated runs finish by 23 November, from the last ten weeks and 29 items" is something a colleague can plan against. "Mid-November" throws that information away.

Keep three numbers visible: the remaining item count, the history window, and the percentile you will plan on. When the range is too wide to book an event, cut scope or change the system that produces throughput. Another meeting about the same average will not tighten an honest sample.

Open a cumulative flow diagram next to the dates. If arrivals stay steeper than departures, the remainder grows while you simulate, and the forecast goes stale from the left. For a campaign, take the date from a high percentile and split items into "must be in the launch" and "can follow." Launch dates stay usable when the date and that list move together.

What makes the range lie

The history is not the future system. A quiet quarter and a discovery quarter do not share a distribution, and sampling across the join pretends they do.

The mix of work shifted. If the backlog flips from small bugs to a migration, old weekly counts describe the wrong kind of items. Split by type, or say plainly that the sample does not apply.

"Finished" is slippery. Reopens, "done" that still needs review, and Friday batch-closes all distort the weekly totals. Running more simulations on dirty counts just gives you a smoother wrong answer.

Flow is getting worse under a flat total. Read throughput next to cycle time. If cycle time is stretching while throughput holds steady, the slowdown usually has not reached the sample yet.

The units do not match. Counting both parents and subtasks, or treating an epic as one item while the history counts its children, shifts every percentile in the same direction. Match the unit of the history to the unit of the backlog.

Write the assumptions next to the chart. When they are false, skip the forecast and say why. That is still more honest than one guessed date.

Where to start if you already have the data

You need items finished per week and a list of what "done for this release" includes. The same completed-item log feeds cycle time, and the primer on cycle time covers the definition, the formula, and why percentiles show up there too. Cycle time asks how long an item took. The forecast asks when a batch runs out.

Spreadsheets, marketplace apps, and planning products can all resample throughput, because the method is not proprietary. Whatever you use should show the history it used, the remainder, the run count, and the calendar, and it should rerun when tickets move. If those are hidden, you cannot explain a slip.

Falrow runs the same calculation beside the tickets: Monte Carlo delivery forecasts with 2,000 runs, plus cycle time percentiles and cumulative flow. It is the same statistic you could build in a spreadsheet this afternoon, and the insights view is the packaged version if you would rather not maintain the sheet. Either way, name the percentile and the window, and rerun when the remainder changes.

FAQ

How many runs does Monte Carlo forecasting need?

Two thousand runs is a solid default, and a few hundred already sketch the shape. Going to tens of thousands changes the chart less than correcting one bad week in the history. Add runs only when the percentile you care about still jitters between refreshes. A short or mixed history will not get more accurate because you simulated it more often.

Is Monte Carlo forecasting the same as velocity?

No. Velocity collapses history into one rate and multiplies. Monte Carlo forecasting keeps each period's count and asks how often random sequences of those counts cover the remainder. The average often lands near the median, but the higher percentiles, the ones you can plan a launch on, only appear when the variation stays in the model. If your weeks barely move, the two answers will almost match, and a narrow range will tell you so.

Which percentile should we promise?

Match the percentile to the cost of being late, and say which one you used. Many teams use the 50th internally and something near the 85th for an external date, but there is no universal choice. A low percentile will be missed about as often as the forecast implies. A very high one is safer and often too far out to be useful. If the 95th is unacceptable, cut items and forecast again.

How is this different from a cycle time scatterplot?

A cycle time scatterplot shows how long each item took. A throughput Monte Carlo asks how many items finish per week, then how many weeks a known remainder needs. Use both. Rising cycle times warn you that next month's throughput may drift away from the sample. Build both charts from the same completed items so they cannot disagree without you noticing.