Agile tells a team how to work. Kanban tells them how to see the work. Neither one, by itself, answers the question a client actually asks: when will this be done, and how sure are you? That question is what Monte Carlo simulation answers — and this guide walks through the whole chain, from the raw data sitting on a kanban board to a delivery date you can actually defend.
What "agile forecasting" actually means
Most agile forecasting starts and ends with the sprint review: did the team finish what it committed to. That's a useful retrospective question, but it isn't a forecast — it looks backward at one sprint instead of forward at when the whole backlog will actually be done. The usual stand-in for a forward-looking answer is velocity: divide the points remaining by average points per sprint, and announce the sprint number that lands on. It's fast, and it's also built on story points, which measure relative effort, not calendar time. Two teams can carry identical point totals and finish weeks apart, because points were never meant to predict a date in the first place — the reasons why are worth understanding on their own. Agile forecasting, done properly, replaces that stand-in with a method built from data that actually correlates with dates: how long individual pieces of work take, and how many get finished per week.
Kanban gives you the raw material
A kanban board doesn't calculate a forecast, but it does generate the two numbers a forecast is built from, ticket by ticket, automatically: cycle time (how long a ticket takes from start to done) and throughput (how many tickets finish per week). Add work-in-progress — how many tickets are open at once — and you get the number that quietly determines how fast the other two even can be. Together, these are what this site calls flow metrics, and reading all four of them together — WIP over time, a cumulative flow diagram, a cycle time scatter, and a throughput run chart — is what turns a board from a to-do list into a dataset.
The catch is that the board itself stops there. Jira, Trello, Linear, and Asana all show what's where; none of them tell you when it'll actually be done, or how confident to be about that date. That gap between a well-run board and an actual forecast is exactly where Monte Carlo simulation comes in — not as a replacement for the board, but as the missing layer on top of it.
Why Monte Carlo simulation, and not a formula
The simplest way to turn cycle time and throughput into a date is a formula: average cycle time times tickets remaining, or remaining tickets divided by average throughput. Formulas like that collapse a team's real variability into a single average, and averages hide exactly the information a forecast needs — how often things run long, and by how much. A single date built this way is a guess wearing a suit, confident-sounding and almost never right.
Monte Carlo simulation takes a different approach: instead of averaging history, it resamples it. The simulation replays "finish the remaining backlog" thousands of times, each run randomly pulling from the team's actual historical cycle times and throughput rather than from a plan. Some runs get a lucky stretch. Some hit a string of slow tickets, the way real projects do. Run it 10,000 times and the result isn't one date — it's a full distribution of possible finish dates, weighted by how often each one actually occurred across every simulated future. A Gantt chart, by contrast, has no native way to represent that uncertainty at all — it was built to sequence dependencies, not to express a probability.
Reading the output: P50, P85, P95, and confidence
A Monte Carlo forecast doesn't hand back one number — it hands back three, each a percentile of the simulated distribution. The P50 is the midpoint: what happens in half of all simulated futures, the date you'd bet on. The P85 is safe enough to put in front of a client, since 85% of simulated futures finished by then or earlier. The P95 is the number you can defend if someone asks what the worst case looks like. Which of the three actually belongs in an email to a client is its own question, and the answer depends on how much risk that specific commitment can absorb.
Every forecast should also carry a confidence label — not just a date, but how much the underlying history supports it. What moves a forecast from Low confidence to High is mostly a function of how much real history the simulation has to resample from, which is why a forecast run in a team's first week looks different from one run six months in, even against the same backlog.
Mistakes that quietly wreck a forecast
Two habits undermine agile forecasting more often than bad data does. The first is the gambler's fallacy: assuming that a string of missed deadlines makes the next one "due" to land on time, or that a lucky streak can't continue. Neither intuition holds up — each ticket's duration is drawn from the same underlying distribution regardless of what came immediately before it. The second is deleting outliers before forecasting, on the theory that an unusually slow ticket doesn't represent "normal" work. Most of those outliers are signal, not noise — they're evidence of exactly the kind of variance a Monte Carlo forecast exists to account for, and removing them quietly makes every forecast after that point too optimistic.
Putting it into practice
Teams starting from zero don't need to wait for months of history before forecasting — a synthetic starting distribution can seed a usable range from day one, tightening as real completed-ticket data replaces it. Once forecasts are running, keeping a running record of forecast versus outcome is what turns a probability curve into something a client actually trusts, and writing that range into the SOW itself, rather than a bare date, is what keeps a missed P50 from turning into a client conflict.
None of this requires abandoning agile or kanban — it requires adding the one layer both were always missing. The board and the ceremonies stay exactly as they are. What changes is the answer to "when will this be done": not a number someone eyeballed, but a probability built from how the team has actually performed.