Monte Carlo forecasting for Azure DevOps delivery planning

How the Monte Carlo simulation actually works

This is a bootstrap resample of your own history, not a statistical curve fit. For each of 10,000 trials, the simulation walks forward through the forecast window and, at every step, draws one of your team’s own finished sprints at random (with replacement), then adds that sprint’s completed-item count to the running total. Do that 10,000 times and the spread of outcomes becomes the forecast. It runs on the Azure DevOps history the extension already reads, without exporting your data to another platform first, without a personal access token to configure, and without a publisher-hosted analytics backend in between. The simulation is also deterministic: the random draws are seeded from your sprint history, the forecast window, and the trial count, so running it twice against the same inputs returns the same P50/P70/P85/P95 range both times. The range only moves when your underlying throughput changes. If the forecast window’s final stretch does not land on a clean sprint boundary, that trailing partial period is prorated rather than counted as a full sprint, so the model does not overcount near the edges.

Reading percentile forecasts, and why a range beats a single date

Every forecast comes back as four confidence levels read off the same 10,000 simulated runs, each meaning "this many items or more, at least this often":

• P95, Very likely: the number you are 95% likely to reach or beat. Usually the smallest, safest commitment in the range.
• P85, Likely: the level most teams use for a date they are willing to put in front of a stakeholder.
• P70, Probable: a workable middle ground, right more often than not but not a safe promise.
• P50, Coin flip: the number half the simulated runs reached and half did not. Useful as a stretch target, risky as a commitment.

How many by a date, versus when will N items be done

These are two different questions, and the simulation runs a separate mode for each. "How many?" takes a target date (30 days out by default) and returns how many backlog items you are likely to finish by then, at each confidence level; use it when the date is fixed and the open question is scope, for example a release date or a contractual milestone. "When will it finish?" takes a backlog size, such as the remaining items in an epic, and returns a date range instead; use it when the scope is fixed and the open question is the date. Because the direction of the question flips, so does the percentile: for "when will it finish?", P50 is the earliest, most optimistic date, and P95 is the latest, most conservative one. When a backlog is large enough that some of the 10,000 simulated runs do not reach the target count within the forecast horizon, the tool reports the percentage that did not finish instead of quietly assuming every run completed, so a wide date range is not papered over with a falsely confident number.

What the forecast needs before the numbers mean anything

A Monte Carlo forecast is only as trustworthy as the finished-sprint history it resamples from. When you open the forecast for a team, the sprint picker lists your ten most recent finished sprints and defaults to selecting the six most recent to run the first forecast; you can pick a different set by hand, which matters if one of those sprints was a genuine outlier, a holiday week or a reorg, that you want out of the resample. The sprint currently in progress is left out of that default selection automatically: resampling from a partial, still-open sprint would drag the whole forecast down with a throughput number that has not finished counting yet. If a sprint you selected fails to load, the view says so ("only X of Y requested sprints loaded") rather than silently forecasting off a smaller sample and calling it complete. A team with only one or two finished sprints will get a forecast, but the range will be wide until more history builds up; the simulation cannot manufacture certainty your team has not earned yet.