Agile fundamentals for teams

In this video, we'll explore forecasting. We'll explain its purpose and look at methods Agile teams can use, to forecast. 

Forecasting is an important part of Agile planning. It creates transparency and helps you track your progress toward your goals. It also allows you to estimate when you’ll complete a piece of work. This can be particularly helpful when stakeholders ask when something will be done. 

But remember, a forecast is not a commitment—it’s an estimate. Think of it like a weather forecast. We can predict the weather with reasonable accuracy for tomorrow. But the further ahead we look, the harder it gets to predict with accuracy. Agile forecasting works in the same way. 

Its purpose is to give you and your stakeholders a view of what’s likely to happen. It helps you gauge when you may meet certain goals and how realistic your current plan is. 

Let’s start by looking at how Scrum teams that use story points for estimation, forecast. One common tool is a burn-up chart. In this example, I’ve plotted the same data used to calculate velocity, from our previous video. The blue line shows the cumulative number of story points completed in 5 sprints. This is where the team currently is. 

I’ve added two extra lines. The green line shows the teams velocity, plus an extra 20%. The red line shows the team's velocity, minus 20%. This creates a cone of uncertainty. It shows us a range of possibilities rather than a single answer. 

You can use this chart for scope-driven planning. Imagine the must-have features for the first release add up to 120 story points. By drawing a horizontal line at 120 story points, we can see where it intersects the cone of uncertainty. 

I can then draw vertical lines down. This tells you the team is likely to complete these features after either 8 or 9 sprints. 

Now, let’s say someone asks which features will be ready after 10 sprints. I can draw a vertical line at the 10th sprint and see where it intersects the cone of uncertainty. 

I can then draw horizontal lines across.  

This tells you the team will likely have completed at least 135 story points of features. They may complete some of the features between 135 and 165 points. But it’s unlikely they’ll complete anything beyond that. 

For Kanban teams, they take a different approach to forecasting. Instead of using story points, they rely on throughput. This is a measure of the number of tasks completed over a period of time. 

Teams use historical data to make estimates about the future. Instead of relying on averages, many teams use Monte Carlo simulations. 

This takes historical data and runs it through thousands of possible scenarios. From this, it will generate probabilities. Let's look at an example. 

Here is a table of throughput data for a team. It shows throughput for the last 5 weeks. As you can see, it has fluctuated over time. 

Imagine someone asks the team how long will it take to complete the next 30 items in the backlog. They can use a tool to generate an answer based on their throughput data. In this case, there is a 90% chance the team will deliver them in 3 weeks. For 4 weeks, the probability increases to 99%. 

What about if someone asks how many items they'll complete in the next 5 weeks? The tool can use the simulations to answer that too. Here, you'll see there's greater variety. 50% is a balanced best guess, that they'll complete 60 items. 80% is a more realistic forecast, whereas 90% is the most conservative. It's up to the team to decide which confidence commitment they want to use. 

This approach is effective because it accounts for the variability in your team’s work. As a result, it gives you more realistic answers to questions. Although it's not perfect, it provides an idea about what’s likely to happen. 

Whether you’re using Scrum or Kanban, forecasting helps you make informed decisions. It also helps you set realistic expectations. But remember, a forecast is a guide, not a guarantee. Like the weather forecast, the closer you are to the present, the more accurate you will be.