From Meteorology to Project Management: The Power of Predictive Modelling- Part 2
Monte Carlo Simulation forecasts project completion dates with a methodology akin to how meteorologists predict hurricane paths, embracing uncertainty to chart a course through complex variables.
Part one covered the history of predictive modelling and the mechanics of Monte Carlo simulation. This part is where it gets useful. I will walk through the software I actually use, what to feed it, and how to read what comes out the other side. Theory is easy. Getting a forecast you would stake your reputation on is the harder part, and that is what the rest of this post is about.
Software Solution:
Below are a few software solutions for forecasting completion dates with MCS that meet various needs.
ActionableAgile- Jira plugin, Azure Plugin and standalone SaaS
Nave- Kanban software solution with MCS integrated
Capacity Planning & Feature Monte Carlo for Azure DevOps and Jira (free)
In the examples below, we will be exploring the ActionableAgile MCS modules.
The ActionableAgile Jira Plugin, a robust extension of Jira, empowers teams with sophisticated analytics and actionable insights, enhancing their workflow processes. This tool offers real-time analytics, facilitating prompt identification of bottlenecks and performance measurement and enabling teams to fine-tune their strategies, thereby improving flow and delivery.
Harnessing the real-time data within Jira, the plugin provides an extensive array of metrics and visualisations. These tools aid in making informed decisions and optimising processes, ensuring that teams have the knowledge they need to excel in their tasks.
For more information on configuring your project to work with ActionableAgile, visit the 55 Degrees website. We will use the sample historical data set provided with the Jira plugin for our examples below.
When Will it be done?
Below is a screenshot of the ActionableAgile plugin ‘When’ module. Using MCS, you would use this to forecast a range of probable delivery dates.
Data Set- Used to select a team’s data for analysis.
Charts- Type of chart used. In this case, ‘When”.
Histogram- A picture of the various completion dates and how often they occurred.
Control for all Charts- Where you control the information needed for running the Monte Carlo simulation.
Calendar- The Histogram in a format that is easier to read.
Legend- Colour-coded legend for the Calendar denoting percentile outcomes.
How to Interpret Monte Carlo Simulation Results:
In this example, we set a backlog of 100 tasks and want to start working on it on 1 February. That’s all you need to input for a fundamental forecast once your Jira project has been integrated with the plugin.
The simulation we’ve conducted offers a compelling insight: there’s an 85% probability that we can complete all the backlog items by the 20th of March. This statistical probability isn’t just a number; it’s a guiding light in the maze of project management.
As we project further into the future, the certainty of completing all tasks increases. However, it’s essential to understand that our forecast isn’t about these specific 100 tasks in our backlog being delivered by the 20th of March. That’s not the claim here.
Instead, we are asserting our capability to deliver 100 work items by that date, with an 85% probability of achieving this goal. This distinction is crucial. It’s not about the exact tasks but the volume of work and our ability to handle it efficiently within the given timeframe. This approach shifts our focus from the minutiae of individual tasks to the broader capability of our team and processes.
How Many?
Below is a screenshot of the ActionableAgile plugin ‘How Many’ module. You would use this to forecast how many items you can complete by a specific date within a probable range of certainty. This is an excellent tool if you have a drop-dead date for delivery and want to determine how many units can be completed in that time.
Data Set- Used to select a team’s data for analysis.
Charts- Type of chart used. In this case, ‘How Many’.
Histogram- A picture of the various completion dates and how often they occurred.
Control for all Charts- Where you control the information needed for running the Monte Carlo simulation.
Calendar- The Histogram in a format that ‘How Many’ can be completed on a specific date.
Legend- User-selectable percentile
Advanced features:
I filtered out a few items in the above examples for easier reading. Below is the out-of-the-box module with filters off.
Daily Throughput- The throughput date control that can be useful if some of your data was generated in conditions unlike that for which your future work will be completed (for example, you now have a different team size, set of organisational constraints, balance of work, etc.)
Selected Throughput- What you choose in the throughput date control will be reflected on the throughput basis. This is where you can see the data used for the histogram and calendar. The throughput basis and throughput date control show a daily throughput (the number of items finished on a particular calendar day).
Scale Throughput- Play with this field to see how an improvement in your throughput will impact your forecasts. You can use decimal points here. So, if you think getting help will improve your throughput by 10%, you can update this to 1.1 and see how that changes your forecast. Conversely, if half your team is away on holiday for the duration sampled, you can scale by .5.
How will this impact my team?
The biggest impact your developers will notice is less work. All they need to do is keep Jira up to date. Story point planning for velocity is not required to estimate completion dates, which shifts the forecasting job squarely onto the production team where it probably belonged all along.
In this setup, production owns the forecast. Individual contributors across disciplines stop being asked to estimate how long a task will take in order to pin down a feature delivery date. That conversation just goes away.
What I do ask for early is User Story Mapping. Ideally at the very start, to establish an initial user story count. It gives the team a shared view of scope before anyone commits to anything, and it is the foundation the forecast sits on. Skip this step and the simulation runs on guesses rather than a mapped-out backlog.
Hold on, are we not still estimating user stories?
Yes. And yes, the count is subject to the same biases as any other estimate. The advantage is that it is a single number. One number to revise, one number to feed into the simulation, one number to argue about in a planning meeting. Compare that to estimating every story individually and the cognitive load drops through the floor.
The approach is also fluid. I update the simulation weekly as stories get added, removed, or rescoped. The forecast moves with the project instead of ossifying at kickoff and then quietly embarrassing everyone three months later. And none of that weekly movement adds work for the dev team.
Forecast accuracy improves as the project progresses. More sprints means more throughput data, which means a tighter distribution. The cone narrows.
What about stories of different sizes and complexity?
Fair question, and the honest answer is that Monte Carlo does not care about individual story complexity in the way traditional estimation does.
What it cares about is the team’s overall throughput pattern over time. The simulation is built on the assumption that your historical data already contains a mix of easy stories, hard stories, and the ones that turned into a three-week nightmare nobody saw coming. That variability is baked into the history. You do not need to model it separately because the team already lived it.
Story complexity is in the data. It just is not dissected in the model. The simulation gives you a range of probable outcomes based on what the team has actually done, with all the natural bumps and dips included. Trying to predict an exact finish date for a specific story is a game nobody wins. Predicting a probability distribution for 100 stories across the next twelve weeks is a game you can win, as long as you have clean throughput data to feed it.
Story complexity is in the data. It just is not dissected in the model.
What this buys you
Running Monte Carlo simulations against your Jira throughput data changes what a producer can say with confidence. You stop guessing delivery dates and start quoting probabilities. Team capacity lines up against project scope in a way that survives contact with reality, and resource allocation follows the numbers instead of the loudest voice in the planning meeting.
Stakeholder trust is the second-order effect, and it is the one I care about most. When you show a publisher the correlation between last quarter’s throughput and this quarter’s projection, the conversation stops being about whether they believe you and starts being about what they want to do with the information. That is a better conversation for everyone.
It also sharpens the calls producers have to make week to week. Which stories to prioritise, when to cut scope, when to push back on a new request. Those decisions get easier when you can see what each choice does to the probability curve. When market conditions shift or player feedback reshapes the roadmap, you can re-run the numbers on Monday morning and have a new forecast by lunch.
The financial side follows from the rest. Better forecasts mean fewer runaway overruns, and fewer overruns mean a studio that can plan its year rather than survive it. That is the whole argument in one sentence.