March 2022 Agile Data Newsletter

article: Why Monte Carlo Forecast? | news: Launch Agile Physics - The Math of Flow training

Why “Monte Carlo” Forecast?

I get a lot of questions from people, and I always try and respond. Sometimes though my thinking takes too long and I forget, and if that has happened to you, please just re-email me. The question I got via LinkedIn this week was roughly as follows:

“How does Monte Carlo forecasting differ from a team using historical card counts or velocity data?”

This great question gets to the point of what forecasting is trying to achieve, and why team forecasting is different from organizational forecasting.

(If you don’t understand what we are talking about, what Monte Carlo forecasting is, see this interactive article for the low-down)

Average plans fail on average
If we use a team’s historical throughput or velocity data and project that pace forward to predict “when we will be done” (typically burndown or burnup charts) we land on zero (shipped) with the same chance as a coin-toss. Monte Carlo allows us to choose what degree of certainty we think appropriate to communicate using the same inputs. The goal of probabilistic forecasting is to take the variability of the inputs and project a set of answers that show the accumulation of that variability of the result. This solves the problem of giving a delivery date that already suffers from 50/50 chance of failing; we get to choose a higher degree of certainty, like 85% or 95% that better accounts for all sources of things going pear-shaped.

The complexity of considering variability quickly nukes intuition
When teams project historical pace data, that have just one uncertain input - that story count or velocity data. But start adding more uncertain inputs, the scope is uncertain, the growth of that scope is uncertain, the defects that need fixing are uncertain, the pace in December or August versus other months is uncertain, and so on. Considering these without the help of a computer spreadsheet is tough to impossible. The benefit of Monte Carlo and spreadsheets like mine is they add this capability without blowing up our brains with complex math.

All models are wrong - that is the BLOODY point
The other reason for using Monte Carlo isn’t really the Monte Carlo part, but that using a spreadsheet model means you consider more factors and can spot when things are going pear-shaped earlier. Upon spotting that delivery isn’t going as expected means you now have a set of inputs to ascertain what guess was wrong. Is scope changing, did defect count through the roof. Models help us see “oh crap” earlier when there is time to do something about it. I like to teach that the models help have the right conversations earlier because they say “Nope” earlier which causes discussion as to what needs to be done to make a “Yep.”

TLDR; Spotting forecast and reality diverging earlier is the key capability. Earlier identification means a faster reaction.

One team’s predictability doesn’t mean product delivery predictability
The more we scale organizations the less relevant any single team’s work has on overall delivery. Dependencies between teams’ and outside the technical organization begin to impact delivery more than any single teams success. Agile is a team sport (Klaus Leopold) - we need to use Monte Carlo to model the uncertainty through the entire delivery chain, not “my part.”

Over the years I’ve helped hundreds of teams make the move to Monte Carlo forecasting, and here is the main point I need to stress. Use the simplest method you can that gets the results you want. If Monte Carlo gives you added benefit for no extra effort, and if it sparks the right discussions, then you should consider using it. I’ve tried to create self-explanatory tools and training that balances complexity with rewards. If you haven’t checked them out, they are free to download and use here -


PS. Training isn’t necessary to get started. If you want to learn more in-depth usage we have two courses available. More info available here:

Using the Monte Carlo Forecasting Spreadsheets (online)
Forecasting Essentials Workshop (instructor-led)

Agile Physics - The Math of Flow FREE Online-Training Launched

I have a lot of material that I want to cover in my forecasting and metrics training that just doesn’t fit. It is generally the mathematics behind some of the magic numbers, or principles I teach. This saddens me. I think as an Agile industry we train concepts without being able to back that concept with proof.

My attempt at solving this depth gap is by putting an online training course that teaches the math and physics that apply in our world. This isn’t unprecedented, the book Factory Physics did the same for factory and process queuing-related industries in the ’90s.

Lesson 1: System Utilization and Lead-Time (Kingman’s Approximation)
Lesson 2: Likely Improvements by Adding Teams and People (Amdahl’s Law)


Not for what we need to know. What is important is what inputs are needed and how they relate to each other. Math is just a fancy way to take inputs and mix and match those to get to a result. The exciting part is what factors matter most, and how. I’ll be recording a video explaining the core concepts for each formula, and you might be surprised by how easy it really is.

For example, the first lesson is on how utilization impacts the waiting time. Many people teach that “above 80% utilization lead-time explodes” but do you know why? Is it always true? (no). Uncertainty is necessary. And that isn’t just cycle-time being uncertain, it turns out when work arrives is important. You don’t need to derive the formula, but you do need to know that uncertainty plays a role, and in highly unpredictable environments, 60% might be the threshold for disaster.

The first two lessons are up, with some others partially started. I’d like to hear your ideas for what proof is needed, and I’ll dig up someone who can teach me so I can teach you.

Go to the Agile Physics - The Math of Flow FREE online course page