By Pat Guariglia
The burndown chart is one of the staples of Scrum. Many of us use and love it. Its simplicity and straightforwardness makes it an effective tool for project teams, management, and for the passive observer. A well-displayed burndown chart is one of the greatest information radiators you can use. From time to time, however, project sponsors, functional managers, and others on the periphery misunderstand its purpose. They can sometimes view a project burndown as a short-sighted tool that fails to provide insight into how the project’s end date is affected when features and tasks are re-prioritized and/or moved out of an iteration to meet the sprint’s burndown target. Stakeholder education certainly mitigates the risk of this misconception, but introducing “whole” project burndown charts, or release burndowns, seals the deal for upper management.
The effectiveness of my team’s burndown charts is demonstrated daily. Once I started using burndown charts regularly, I became a better ScrumMaster and communicator, plus my teams became more productive and predictable. I became almost proud of the success of using burndown charts on my projects and felt the need to talk about the charts and use them in presentations to upper management. This served me well and poorly at the same time.
The problem started when someone in my organization’s executive management, “Jeff,” took notice of the burndown charts hanging around our project area. Jeff started to review the charts and drew his own conclusions. As he saw it, the burndown seemed like a good way for the team to drop scope at will, without regard for what it did to project dates and costs.
I was unaware of Jeff’s misinterpretation until I gave a quarterly project briefing to executive management. During the briefing, he asked me to explain the burndown chart. I described how the product owner and team move stories out of the sprint if the chart shows us trending above our planned progress line. Conversely I explained how stories could be moved into the sprint when the chart is trending below the progress line.
Jeff explained that while he understood the need to move stories and tasks in and out of a sprint, he didn’t have a warm and cozy feeling about how those actions affected the cost and time for the project. He asked questions such as, "What happens to the duration of the project if something in the current sprint takes longer than you planned and you need to move something out?" and "What happens to the cost of the project if something gets moved out?” Although I was able to answer these questions during the meeting, I realized that I needed to do a better job of giving upper management a picture of the whole project. I decided to start using release burndown charts, which provide a view of the progress of releases throughout the project.
Scrum teams can often get away with a somewhat myopic, or nearsighted, view of their sprints and releases. After all, teams are rightly focused on delivering the functionality in the current sprint. Their metrics, therefore, are also focused on the current iteration. A sprint burndown focuses solely on the current sprint and illustrates progress along an expected path for that time box (as shown in the figure below). At the start of each sprint, the team plans to tackle a subset of the entire project’s user stories. This subset of user stories has an associated story point value. Teams use sprint burndowns for various reasons. They may want to see how much time and work is left in the sprint. Sprint burndowns also help the team understand whether or not stories are at risk within that sprint. If stories are at risk, the sprint burndown may be an indicator that stories should be removed. If progress is greater than anticipated, the burndown chart can be an indicator that stories may need to be added to the sprint.
On the other hand, sponsors, stakeholders, and other members of management who fund the project need to move beyond that myopic view and look at the big picture. They need to have answers to the following questions: How well is the project funded? How much money is left? When will it be completed? What value is being delivered and when? The release burndown provides a more complete picture of value and time. In the figure below, the entire project consists of 750 story points. The team’s velocity (the amount of product backlog a team can handle in each sprint) is 75 story points. The team estimates it will take 10 sprints to complete the work (750 total story points / 75 points per sprint = 10 sprints). Therefore, the release burndown shows ten release bars extending across the chart from left to right. The vertical axis shows show the number of story points. As value is delivered over the course of the project, the story points (shown in a blue bar in the figure below) burndown; as scope is added or as estimates increase, the story points increase as well (as shown by the red bars in the figure below). The trendline shows how the project is trending overall. Release burndowns provide the overall project status and the value delivered to date for each release or sprint.
A release burndown shows, at a glance, all of the project’s sprints and their cumulative effect on the project. Release burndowns allow you to visualize the overall project timeline and calculate total project costs, assuming you know approximately how much each sprint costs. A simplistic example would be as follows: Ten sprints, at a cost of $10,000 each, would equal $100,000 for the complete project. If you add an extra sprint, the project cost goes up by approximately $10,000. Management can also see from a release burndown chart when extra sprints were added because remaining work has been re-estimated or work has been added. They can also see the affect of other factors (such as changes in the team’s velocity or membership) on the long-term project outlook.
Product owners can use release burndowns to take corrective scope action when they see the overall progress line trending in the wrong direction. If they see the team is progressing faster than planned, the project may end earlier or they may have the option of pulling in lower priority work from the backlog. If they see the team is not completing as much as planned in each sprint, the product owner may opt to de-scope some of the project, re-prioritize the backlog, or look to project sponsors to increase the length of the project or add project resources.
Release burndowns are an important tool for communicating the condition of the project, the long-term team velocity, and delivered value. In contrast, the sprint burndown is not intended as a long-term project information radiator; a single sprint burndown can't show you what happens to the project when you move work out of a sprint or re-estimate. A tool like the release burndown is much better suited for this level of communication.
Now that I've been using release burndowns for a while, it's hard for me to imagine running a project without one. What about you? Are you using release burndowns?
