Managing Myopia with Release Burndowns

A CSPΓÇÖs perspective on Scrum metrics.

25 May 2010

Pat Guariglia, PMP
Elegant Agile

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?

Article Rating

Current rating: 0 (0 ratings)

Comments

Henri Stegehuis, CSP,CSM, 5/31/2010 3:10:17 AM
I have been reading and re-reading this article now for a couple of times. I can not fully point out why but my guts tell me that something is not Scrum. I'll give you my thoughts:

1. I know, it is very stupid but presenting a clear message, the red and the green in the release planning. Why is it 'wrong' to add and why is it 'good' to remove?
2. The release burndown is focussing on delivering something on time. There seems to be no freedom to add a few sprints and even worse, to finish earlier. I am wondering how business value is determined. It feels like traditional planning: give somebody 10 hours and at the minimum those 10 ours will be consumed.
3. I am wondering why you are not using a velocity chart and with that in combination with the Product Backlog calculate what the client Will have, Might have and Won't have. The effect, in my opinion, is totally different though functionally the result might be the same. Especially when showing the product owner (and clients) what they Won't get raises the first time the red flag (heavy discussions). After a couple of sprints, when people are used to these three categories, the team output is not under discussion and the Product Owner has become a skilled master in shifting priorities to make sure that certain Product Backlog Items are not in the Won't have region. If the Product Owner feels that there are too much Product Backlog Items in the red zone, there is fundamental discussion possible where still the team output (velocity) has become a fact. Programme Management may decide to add a couple of sprints because on business level the business value is re-evaluated.

Just my 2 cents ...
Henri Stegehuis, CSP,CSM, 6/3/2010 8:57:49 AM
Your article woke me up last night ;) It has kept me busy because the simplicity of a graph for the project overview makes management always happy. The release graph as I understood your article seems to have lost the priority and business value consideration of the individual stories. It seems a stacked pile of all story sizes but that can't be the case because not every story has a positive business value. Am I correctly understanding that it reflects those stories that are needed for a certain release? In other words, the release graph represents those stories that add business value to the product? When removing points does this imply that these stories are considered adding no business value to the product? If this is true then there lies the difference in perception. I work in erratic environments where priorities can change per sprint. Removing stories is unthinkable. In projects I have been working, product backlogs only grow and will result in impossible to explain release graphs. It is not uncommon though that an impressive amount of stories is never realised because of business value decisions. And yes that is the weak spot of these environments because I can't present a quick graph where we are standing or going to. I always have to tell the full detailed story. Ideas or is my thinking wrong?
Pat Guariglia, PMP, CSP,CSM, 6/3/2010 7:19:01 PM
Henri, thanks for reading the article and for the comments. IΓÇÖm sorry it kept you up last night! : )
I prepared a reply that addresses both of your comments.
For the comment on 31 May 10 03:10:
1. The product release burndown chart is not intended to place a positive or negative connotation to removing or adding stories to a project. One of the functions of the chart is to identify the additions/deletions of stories, when they were added/deleted and their potential impact to the release plan.
2. Sprints can be added or removed if needed. The chart is another tool to help point out to Scrum Masters, Product Owners, Sponsors, etc. what the impact is to the overall project timeline when stories are added or removed. Story points represent an estimate of relative size, effort and/or difficulty of each story. The product owner and sponsors can use the chart to visualize whether the project will end early, go longer or end when we thought it would. This is important when a team is only dedicated to a project for a fixed period of time, or there is a fixed budget and sprints cannot be added. If more funding will be needed, this chart can help show sponsors how many additional sprints might be required. Adding sprints to accommodate additional work is ok and so is finishing early.
3. Velocity charts tell us what our past velocity was for completed sprints and how many story points we completed per sprint. We can use velocity charts to help identify future velocity trends while accounting for any future variations in the teamΓÇÖs composition or availability. Those velocity ΓÇ£forecastsΓÇ¥ can certainly be put into the release plan.
For the comment on 03 Jun 10 08:57:
If you look at the second graphic titled ΓÇ£Product Release BurndownΓÇ¥, you will notice that the bar numbered ΓÇ£2.0ΓÇ¥ has approximately 750 story points. Think of this number as the total cumulative amount of all stories combined. At the beginning of the project, you have 750 points and you expect that you will burndown X number in each sprint. Points here are not used to illustrate business value, they are instead used to represent the estimated size/complexity/effort of each story to be built. For example, a 20 point story is bigger (will take longer or require more effort to build) than an 8 point story. In the example here, the team expects to burn 75 points in each sprint. The business value delivered in each release is determined by what features/stories are in that release. Stories that get removed by the product owner are usually removed because they have become less important than other stories, or the project is running out of money or time. Those that get removed are likely to be the lowest priority stories.
Henri Stegehuis, CSP,CSM, 6/9/2010 3:15:01 AM
I understand what the graph is showing (have some years of experience in traditional management). With respect to Scrum though I question the applicability. It is important to express that in this approach stories are removed from the product backlog when considered having no business priority. I am working in erratic multidisciplinary R&D environments where removing product backlog items is considered undesired. Undesired because what one sprint seemed unimportant might be important the next. Because the y-axis, points, is the summary of gained velocity and changes in the product backlog it seems to me that the release burndown is mainly applicable when the Product Backlog has a certain stability ... in erratic environments I see this conflicting. In those situations I expect the fluctuating release burndown to increase restlessness on management levels and for me a lot of work to get it explained. Not that I want to hide changes but Scrum accepts changes as part of the process. I want changes be considered a normal process and this should be reflected in the visual representation.    --  new paragraph  --    Suddenly I realised having seen something that takes away most of my remarks ... the release burndown BAR chart. Mike Cohn wrote about in "Agile Estimating and Planning" (Chptr 19). I have to extend it with Will have, Might have and Won't have colours in the bars (uncertainty on delivery date) but then all fundamental information is in one view. I'd better start re-reading this book with my gained experience over the past few years ... maybe it has some more solutions for issues that are keeping me busy.
Ronald Perich, CSM, 7/1/2010 7:29:49 AM
Thanks for this article. I personally don't see anything that isn't "Scrum". There is a lot of uneasiness from non-Scrum folks about how they will see progress being made, how we know if we are meeting our commitments, how long projects or releases will take, are we on track, is this really a project, etc.

You help to address some of that here.

Thanks!
Vignesh Murthy, CSM, 2/12/2014 2:49:22 AM
Thanks Pat,

I agree release burn downs are very useful to track the progress at project level.

Feq questions: In your example you mentioned release backlog of 750 points.

1. How do you know this at the start of the first sprint ? how do you estimate the entire backlog to know its size.
2. Once the entire backlog is sized, do you allow team to size any independent miscellaneous tasks which is not part of any story ? we did it in one of the projects which resulted in backlog size increase every sprint ?
3. What are the backlog size increases in your example?
(the red ones)


Thanks , Vignesh

You must Login or Signup to comment.