When will we get there? It’s not just a question you might hear from the kids on the way to Grandma’s house for Easter. It’s something that organizational stakeholders, customers, managers and many others want to know too. And no one wants to hear, “We’ll get there when we get there,” as an answer.
In Scrum, part of the Product Owner accountability is to provide a forecast that sheds light on possible answers to the when will we get there question. In my last post, we discussed three ways to size Product Backlog items (PBIs). Today, we’ll discuss ways the Product Owner can use this information to create a meaningful forecast.
What is a forecast?
In Scrum, a forecast is not a plan. Nor is it a promise. Instead, it’s similar to a weather forecast. A forecast shows where we are currently trending for delivery of PBIs, based on what we know.
Why can’t we make promises about the future with Scrum? Because in complex environments where we use Scrum, we face more unknowns than knowns. A forecast can be helpful in a complex environment, but it can never be a guarantee. As we learn more, we will update the forecast based on that new information. Nothing supersedes empiricism, which is making decisions based upon what is known.
It is critical stakeholders understand the uncertainty factor in all forecasts.
How do we forecast in Scrum?
To provide a meaningful forecast, a Product Owner needs two things. First, they need work items in a Product Backlog that the team has ordered and sized so that they can complete them on one Sprint. Second, the Product Owner needs history indicating a range (low to high) of how much work the Scrum team can deliver per Sprint.
Let’s look at some common forecasting tools for Scrum teams.
Burn-down
Scrum.org’s Scrum Glossary describes a burn-down chart as follows:
A chart that shows the amount of work which is thought to remain in a backlog. Time is shown on the horizontal axis and work remaining on the vertical axis. As time progresses and items are drawn from the backlog and completed, a plot line showing work remaining may be expected to fall. The amount of work may be assessed in any of several ways such as user story points or task hours. Work remaining in Sprint Backlogs and Product Backlogs may be communicated by means of a burn-down chart.
The sample chart above shows the work completed with a dark line while possible completion dates are forecasted with a dotted line.
Burn-up Chart
Rather than focusing on the # of Product Backlog Items that remains, the burn-up chart shows the number of Product Backlog items that were closed over time. The number of Product Backlog items that were done, or completed, is graphed over time and is shown approaching a ‘planned scope’ line.
You can create a burn-up chart using Excel with data from your Product Backlog.
Cumulative Flow Diagram
Of the three types of charts discussed in this article, my favorite is the cumulative flow diagram. This chart is similar to a burn-up, except it shows the total amount of in-progress work, work created, and work completed on a single chart.
A Cumulative Flow Diagram is really the most realistic of the three charts included in this article, because it shows the growth in the Product Backlog by creating a graph which shows not only the number of PBIs completed or closed over time, but the number that were created over time as well. This reflects the way that agile teams really work—as they learn, they create more PBIs to reflect the evolving needs of the team.
For example, I was recently part of a team working towards a hard deadline. The team knew generally what needed to be done, which was that we needed to deliver all "must have" functionality by a certain date. However, not all of the PBIs necessary to meet this goal had even been created. Instead, the Product Owner worked together with the team to continuously refine the Product Backlog, always staying about one Sprint ahead of the Developers. To use an analogy, the team was designing the airplane while we were in flight.
My example is the way that most agile teams really work, and that’s a good thing, because it avoids waste and allows the Product Owner and the team to learn what works and what doesn’t, adjusting the Product Backlog accordingly. The cumulative flow diagram reflects this reality because it graphs not only the total PBIs that were closed over time, but also the total created for a specific goal over time.
The following graph is an actual cumulative flow diagram for an initiative and shows progress over six Sprints.
This next graph is the same initiative showing progress over several months. Over time, as the team got closer and closer to achieving their goal, the number of PBIs created compared to the number closed also got closer and closer.
A cumulative flow diagram is most helpful when showing progress towards a single goal. A cumulative flow diagram is not helpful when measuring progress towards several upcoming deliverables. Instead, roadmaps, which will be discussed next, can be used to discuss multiple upcoming deliverables.
Roadmap
I think of the Product Backlog as a series of steps down a path. Each work item is a step, and together they make up the Product Backlog. We take steps along that path by delivering PBIs. The Product Backlog is our plan of what to do next and what steps to take. A Roadmap is simply a visualization of what is already in the Product Backlog.
Like a burn-up or burn-down chart, a roadmap is simply a forecast of the most likely completion of items in the Product Backlog. For example, if your Product Backlog has 30 items that require your team to deliver one feature, the roadmap will show the forecasted completion date for that feature. However, a roadmap does not have to include dates. For a few of my favorite roadmap templates, read my post, “Forecasting with Roadmaps” and download a template you think would work for you.
Monte Carlo
The Monte Carlo forecasting tool helps to create a probabilistic forecast of how long it will take to deliver a certain number of PBIs (or you can use points).
The Monte Carlo forecasting tool above was created by Focused Objective LLC.
Simply enter the start date, enter a low and high guess of how many PBIs are necessary to deliver the goal, and enter a high and low guess for how many PBIs the team can deliver per Sprint. Finally, enter your team’s Sprint duration and voila—the forecasting tool provides you with the likelihood of your team delivering by a particular date.
The forecast uses either an estimate of how many Product Backlog items (or points) your teams can deliver per Sprint or - for greater accuracy - you can enter historical data into the spreadsheet.
How does it work? Based on the estimates or historical data provided, the spreadsheet creates a number of simulated trials to determine the most likely completion date for your initiative.
In my experience, the Monte Carlo spreadsheet is extremely useful. Visit the Focused Objective LLC website where you can access a Monte Carlo spreadsheet on their free tools page.
Conclusion
Providing stakeholders and customers with a believable forecast is vital for building trust. When forecasting, ensure that your stakeholders and customers understand that just like a weather forecast, things can change as more information becomes known.
What to learn more about Scrum?
Signup for one of Rebel Scrum’s upcoming classes:
Introductory class for those new to Scrum
Geared towards Scrum Masters coaching teams
Advanced class for Scrum Masters
For leaders and managers of Agile teams
Professional Scrum Product Owner
For Product Owners
Professional Scrum with Kanban
For anyone interested in learning about implementing Kanban principles within a Scrum team
For those interested in learning how to scale Scrum with Nexus
Both public and private classes are available. To learn more, contact Mary Iqbal.
Comentários