The Alternative Burndown Graph is one of the more useful Agile graphs. It’s especially useful for communicating outside of the team, with stakeholders, senior management, etc. This is because it’s can be used to show three important pieces of information; 1. how the team is progressing, 2. changes to the baseline of the Product Backlog, and 3. can be used to determine a completion date. It is a graph that’s generated at the start of every Sprint and shows how work is being completed Sprint over Sprint.
Here’s what the Alternative Burndown Graph looks like.
I’m frequently asked if I have a version of the graph that I can share, so I created a Google spreadsheet to generate a simple and useful version of the graph. You can get a copy of my Google Spreadsheet here.
Understanding the Alternative Burndown Graph
The Alternative Burndown Graph is started by adding up the total amount of work remaining in the Product Backlog , and plotting this initial value. There after, any work completed by the team is taken from the top of the graph. By drawing a trend line through the tops of the graph we can show how the team is making progress Sprint over Sprint.
But what about work being added to the Product Backlog? With this style of graph, any work added to the Product Backlog is added to the bottom of the graph. And, by drawing a trend line through the bottoms of the graph we can show how the baseline of the Product Backlog has been changing Sprint over Sprint.
Finally, we can then use all this information to help calculate when we think the team will have completed the work in the Product Backlog. The intersection of the two trend lines is where the Product Backlog will give us the most likely time of completion of this Backlog.
Creating the Graph in Google Spreadsheets
It’s a very easy graph to generate with any simple spreadsheet application, but I’m frequently asked if I have a sample version of the graph that I can share. So, here’s a version as a Google spreadsheet.
The spreadsheet contains two tabs. The first tab contains the data necessary for the graph, and the second tab contains the graph. The graph is generated using the data in the rows titled Series A and Series B.
To start using this graph,
- Make a copy of the Google Spreadsheet
- Enter the total of the teams estimates in the product backlog into the first column of Series A.
- There after all you need to record is the total number of the teams estimates completed at the end of each Sprint, and
- The total number of the teams estimates added to the Product Backlog (by the Product Owner) during the sprint.
So, there you have it. A nice simple Alternative Burndown. Let me know if you find this useful.
 Teams will seldom calculate the total amount of work for the entire Product Backlog … because this might be a large amount of work especially for very large Product Backlogs. It is more likely that the Product Owner and team will select some subset of the Product Backlog (say the top 20%, or perhaps sufficient work for the next release) and use then generate this graph for that subset.
 That fact that we need to ‘add up the total amount for work remaining the the backlog’ is often interpreted as an implication that we need a numerical scale. This is not so; we can easily use an abstract scale although it’s something most people are uncomfortable with. To make it easy to generate this graph many teams will adopt a numerical sequence, but its important to remember that it doesn’t matter what scale you use, provided that you’re consistent.