Using Monte Carlo Forecasts in your Scrum Events
If you read some other articles from me, you might be aware that I’m an advocate of flow metrics and that I like to use Monte Carlo (MC) Forecasts (see also Running Monte Carlo Simulations in Azure DevOps or How to Visualize Work Item Age in Azure DevOps).
I also happen to be a proponent of Scrum. In this post, I’ll combine those two things and I try to show how you can use MC Forecasts in your Scrum Events.
Monte Carlo Forecasts?
First things first. If you wonder what the heck MC Forecasts are, I recommend you read the first sections of this post. It contains a high-level introduction and also further links if you want to dive deeper.
Scrum or Kanban?
Flow Metrics and Monte Carlo forecasts are often associated with Kanban. You might be wondering how to combine this with Scrum.
It’s not Scrum or Kanban, you don’t have to choose one over the other. Instead, the Scrum framework and the Kanban strategy complement each other nicely. Within the boundaries of the Scrum Framework, you can use Kanban to optimize flow. There is a good reason why official training classes exist from both Scrum.org (Professional Scrum with Kanban) and ProKanban.org (Applying Flow Metrics for Scrum) that connect those two things.
Using Forecasts in Your Scrum Events
Now that we’ve got these things out of the way, let’s get down to business and check all of the Scrum Events and how we can use the forecasts in each of them.
As a reminder, these are the five events in Scrum:
- The Sprint itself is the heartbeat and helps to deliver a done, usable increment that meets the Sprint Goal.
- The Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint.
- The Daily Scrum helps to inspect the progress toward the Sprint Goal and adapt the Sprint Backlog as necessary.
- The Sprint Review exists to inspect the outcome of the Sprint and determine future adaptations.
- The Sprint Retrospective’s purpose is to plan ways to increase quality and effectiveness.
Sprint Planning
How much time do we tend to spend during Sprint Planning on discussing things like Story Points, past velocity and capacity of people, only to get an idea of how much will fit in a Sprint? And how often do we get it right despite the effort we spend on it? In my experience, the answer to this is rarely (if we even bother to check if we get it right…).
MC Forecasts can help you save some time and ideally get a more accurate idea about how many items will fit. You can run a forecast for “How Many Items will we able to do in x days” where x is your Sprint length.
The simulation will give you different levels of certainty. This can be useful, as you could for example use the 85th percentile as an indicator of how many items will “fit” in your Sprint. Then you could use the number the 95th percentile gives you to choose how many items can be related to your Sprint Goal. The “remaining items” could be used for items that are not related to the Sprint Goal.
No need to discuss velocity or have discussions about capacity. Instead, you can use Sprint Planning more according to its original intention: discuss the Sprint Goal and how to achieve it.
If you track your forecasts over time, you can also visualize the “actual” items the team has recently been able to deliver in the timespan:
This can help you to see if the team recently over- or underperforms compared to the forecasts, for example, due to changes in the team setup, the product, or its environment. You can then also take this into account when thinking about how many items you want to plan.
Daily Scrum
The Daily Scrum — is most likely one of the most dreaded and misunderstood meetings held all over the world. In environments where “Zombie Scrum” is dominant, it often turns into a dull status report. But even in teams where Scrum is lived according to its values, it’s easy to fall back to old habits and focus on the work you are doing and not on adjusting the team’s plan toward the Sprint Goal.
What if, instead of looking at some tickets in a tool, you would see a “When” forecast, that tells you when all your Sprint Goal related items are done?
This tends to be a good conversation starter:
- It seems we’ll be achieving the Product Backlog Items related to the Sprint Goal early, is there a way to get feedback before the Sprint Review?
- It looks like we’re not able to achieve what we initially planned, how can we adjust our plan? Can we split some work off an item that is not needed for the Sprint Goal? Or should we have a discussion with the PO and/or stakeholders about alternatives?
- How can we support each other so that we focus on the Sprint Goal items?
Using a When forecast can help you make the dailies more engaging again. It also helps you and your team keep the focus on the Sprint Goal, the plan to reach the goal, and the items related to it.
Sprint Review
It’s the end of the Sprint, your team, and your stakeholders are in the Sprint Review. As a reminder, here is what the Scrum Guide says about the Sprint Review:
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next
— Scrum Guide 2020
You can run a “When” prediction and share what is the likelihood of reaching a specific target date with the items remaining in the backlog.
If you don’t work with target dates, you can answer the stakeholders, when the feature is most likely done.
Or you can answer “how many” items will fit till a specific target date. That lets you discuss which items will be making “the cut” and which ones have to be left for a later release.
This is a very good foundation to have meaningful discussions with your stakeholders about how to proceed. Using this as a baseline, you can collaborate with them during the Sprint Review and co-create the next steps the team should take.
Sprint Retrospective
During the retrospective, you can look at forecasts too. If you store your historical forecasts (say you do one per day) you have the data already. You can generate insights by checking the forecasts over time or comparing them to the actual results. If you want, you can even create a nice visual timeline.
Was the forecast stable or was it “off”? If so, what caused that change? What changed in your environment that caused this? Did you have many unplanned items?
It’s not about making the forecast 100% accurate, but they can give you pointers to bottlenecks or make transparent issues the team might not have been aware of.
Sprint
You can (and in my view should) use forecasts throughout your Sprint. You should inspect them frequently and take action as soon as you learn something. You should not wait for a specific event to happen to start a conversation.
If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.
Outputs vs. Outcomes?
Isn’t the forecast mainly output-based and Scrum all about the outcomes? Should we care that much about the output then? Yes, we should care about the outcomes we generate with our output. But we still need some kind of output to achieve that.
We have to plan for some output to create the outcome we wish for. And with Monte Carlo forecasts we can get some ideas on how long this would take.
For example, we hypothesize that we can achieve Outcome X by implementing Feature A. Now the forecast might show that it will take two months for us to implement Feature A. This could lead to a discussion where we change our plan and implement Feature B, which could lead to partially achieving Outcome X but in less time (according to our forecast).
Yes, focus on outcomes, but don’t forget that you have to deliver something to to achieve them. And for this, we can and should still use forecasts.
Conclusion
Monte Carlo forecasts are a nice complementary practice to Scrum. You can use them in all the Scrum Events in various fashions. As they are based on real data from your team, they are a great tool to have data-driven discussions inside your team and with your stakeholders.
As they are based on historical data, and all you need is the date you closed an item to run a forecast, you most likely have already everything in place to make use of it. I encourage you to try it out in your team — whether you are doing Scrum or not.
