One of the most common questions asked of any engineering team is "when will feature X be done?" Traditional point-based estimation is notoriously unreliable. Monte Carlo simulation offers a statistically rigorous alternative: instead of a single estimate, it gives you a probability distribution of completion dates based on your team's real historical performance.
What Is Monte Carlo Simulation?
Monte Carlo simulation runs thousands of randomized scenarios using your team's actual sprint-over-sprint throughput data. Each scenario randomly samples from your historical delivery rates to simulate how long it might take to complete a backlog of N items. The result is a probability distribution: "there is a 50% chance we finish by March 15, an 85% chance by April 2, and a 95% chance by April 20."
Why Not Use Average Velocity?
Averaging velocity produces a single-point estimate that has no probability attached to it. It ignores the natural variability in your team's delivery. If your velocity ranges from 30 to 60 points per sprint, using the average of 45 gives you a 50% chance of being right, which is a coin flip. Monte Carlo makes that uncertainty explicit and lets stakeholders choose their risk tolerance.
How Agile Analytics Runs the Simulation
Agile Analytics uses your completed work in Azure DevOps to power the simulation:
- It samples from the number of items your team completed per sprint, or per week if you forecast from weeks.
- It runs 10,000 trials by default.
- It reports each result at four confidence levels: 95% (Very likely), 85% (Likely), 70% (Probable) and 50% (Coin flip).
- Each confidence level is the share of simulated runs that came out at or better than the number shown.
How to Use the Forecast
The Monte Carlo view has two questions to choose from: How many? (how many items can we finish by a date) and When will it finish? (when will a given backlog be done). You set the backlog size or the target date, and pick the history to sample from: a selection of past sprints, or the last 8, 12 or 26 complete weeks.
What-if Scenario
The What-if Scenario panel adjusts throughput by -20%, -10%, +10% or +20% against the baseline, so you can see how much the date moves if the team slows down or speeds up. That is useful in conversations about cutting scope to hit a deadline or moving the date.
Choosing the right confidence level
A forecast is most useful when its confidence level matches the decision being made. The mistake many teams make is treating one date as right for every audience. A planning conversation, an executive status update and a contractual commitment usually need different levels.
- P50 is the median outcome: you are about as likely to finish earlier as later. Use it for internal planning and scenario discussions, never as a commitment.
- P85 is a more conservative date. Use it for stakeholder communication and roadmaps, where being trusted matters more than being optimistic.
- P95 is a high-confidence date. Use it only when missing the date costs much more than carrying the buffer, such as a contractual or regulatory milestone.
Presenting a P50 date as a commitment is the most common way forecasting goes wrong. Half the time the team will be late, stakeholders read normal variation as failure, and the response is usually more pressure, more scope churn and less trust. Choosing the level up front keeps the conversation honest about uncertainty. A good forecast summary is short:
- State the scope being forecast.
- State the history window the simulation sampled from.
- Give the P50 and P85 results together, so both the optimistic and the safer answer are visible.
- Say what happens if scope grows or throughput drops.
Communicating Forecasts to Stakeholders
One of the biggest benefits of Monte Carlo forecasting is that it changes the conversation. Instead of defending a single estimate, you can say: "Based on our last 6 sprints, there is an 85% probability we will complete this by April 2. If you need 95% confidence, the date is April 20." This is honest, data-driven, and far more useful than a single-point guess.
Tips for More Accurate Forecasts
- Use at least 6 sprints of history, because fewer sprints produce wider uncertainty bands
- Keep your backlog items roughly similar in size for more consistent throughput sampling
- Re-run the forecast each sprint as scope and throughput evolve
- Use item count (not story points) for Monte Carlo, because throughput in items is more stable than velocity in points
- Review the forecast in sprint planning and retrospectives to build shared understanding of delivery uncertainty
Related: Monte Carlo forecasting in Azure DevOps · Throughput and cycle time