A Monte Carlo release forecast answers the question every stakeholder actually asks — “when will it be done?” — without pretending the answer is a single day. Instead of multiplying remaining scope by average velocity and reading off one date, it replays your team’s historical throughput thousands of times and returns a distribution: 50% chance by the 14th, 85% by the 28th, 95% by the 4th. The recurring Agile-forum argument about this method is not whether the maths works. It is whether a range is a usable answer.

How the simulation actually works

The mechanic is less exotic than the name suggests.

1. Take your team’s completed-items-per-sprint for the last several sprints. That is your throughput sample.
2. Pick a sprint at random from that sample. Subtract its throughput from the remaining scope. Repeat until the scope hits zero, counting sprints.
3. Do that ten thousand times. You now have ten thousand possible finish dates.
4. Sort them. The date 50% of runs finished by is your coin-flip date. The date 85% finished by is the one you should be quoting.

Nothing in that requires estimating the remaining work in hours. It requires counting what you finished, which your Jira history already knows. That is the whole appeal: the forecast is built from evidence rather than optimism.

Why the average-velocity answer is worse than it looks

Take a team that averages 30 points a sprint but ranges between 20 and 40. Divide 150 remaining points by 30 and you get five sprints. That number feels solid. It is not — it is roughly a 50% outcome dressed as a commitment. Half the possible futures land later than it, and nobody in the room was told that.

The variance is the information. A team that ranges 28–32 and a team that ranges 10–50 can share an average and have completely different risk profiles. Averaging throws that away at exactly the moment you need it. We made the same argument from a different direction in three-point estimation for release forecasting — PERT gets you a range too, but Monte Carlo gets it from history instead of from three more guesses.

What it needs from your data — and where it breaks

The method is honest about its inputs, which is also how it fails.

• It assumes tomorrow resembles the last few sprints. Reorganise the team, change the tech stack, or lose two engineers, and the historical sample is describing a team that no longer exists.
• It assumes scope is stable. A forecast against a backlog that grows 10% a sprint is forecasting a moving target. Measure the growth first — see how to measure scope creep.
• Partial sprints poison the sample. A holiday sprint or a half-length first sprint drags the distribution down. Exclude them deliberately rather than letting them quietly widen the range.
• It says nothing about dependencies. Throughput history captures how fast your team finishes its own work. It cannot see the other team’s slip.

None of these are reasons to skip the forecast. They are reasons to re-run it. A Monte Carlo release forecast that is generated once and pasted into a status deck has the same defect as the average-velocity date it replaced: it stops updating the moment it becomes inconvenient.

Saying it out loud to stakeholders

The objection that ends most of these threads is “my exec will not accept a range.” In practice they will, if you give them one number and a label rather than a chart. “We are 85% confident by 28 November” is a commitment. “Somewhere between mid-November and early December” is a shrug. Pick a confidence level, quote the date that goes with it, and restate it every sprint as the distribution shifts.

What changes the conversation is showing the date move. When the 85% date slides a week, that is a re-forecast with evidence behind it — which is a far easier conversation than the one where a fixed date holds for four months and then slips a month at once. That is the whole case for renegotiating a release date before it slips.

Running this against live Jira data

A forecast is only as good as its refresh rate, which is the argument for keeping it next to the plan rather than in a notebook. Advanced Release Planning, Roadmaps & Management for Jira builds the release view directly on live issue data: remaining scope, delivery trend, and a forecast that moves when the work moves. When scope is added or a sprint underdelivers, the projected date updates in the same place the release is planned — so the re-forecast happens as a matter of course rather than as an escalation.

Where this fits

Forecasting is one stage of release planning, not the whole of it. For the end-to-end practice — scoping a release, forecasting it, tracking it, and defending it from scope — start with the pillar: Release Planning: A Complete Guide for Agile Teams in Jira. For the forecasting stage specifically, release date forecasting covers the alternatives side by side, and the release burndown chart is how you watch the forecast hold or fail between refreshes.

The simulation does not make your team faster. It makes the date you quote match the evidence you already have — which is usually the cheaper problem to fix.