Radiating the Right Message

Different Types of Burn-Down Charts

5 March 2014

Adam Zuzanski
Rule Financial


A while back I was asked to advise how a sprint burn-down chart should be constructed. There was no time for elaborate discussion, so I just replied with my usual "story points left over time." The guy asking the question was not convinced, and he later came back to me with a "proof."

"Here, you see," he stated, showing a graph on his screen. "They are using number of tasks left over time. It's far more granular, so you can find problems earlier. Plus you have all the data from tracking software just like that."

I spent some time with him, discussing the function of burn-down charts. At the end we came to the common conclusion that one needs to be really careful when searching for answers on the Internet. Even successful war stories can lead you to a trap.

Background

According to an excellent Scrum Primer, the sprint burn-down chart should show not how much time was spent in the past but how much work remains in the future. Some sources mention showing hours left (from tracking software), some discuss size of work left, other even suggest counting tasks or stories.

I do not see much value in defining a "perfect chart." Instead I would like to take step back to comment on the purpose of this artifact and, in the next sections, show options I recognize.

The main reason of having a burn-down chart is to radiate information. Be they your clients, managers, or team members, everyone benefits from having quick insight into sprint progress. It is up to you what kind of information you want to share, but it is always good to recognize how it impacts receivers.

When we look at Scrum teams around us, it seems clear that team members are shaped by different backgrounds, and they usually present slightly different behaviors. Despite a ScrumMaster's best efforts, some of them may see the burn-down chart as a metric or, even worse, as a KPI (being over/under the line). This misconception may cause the effect common in the case of ill-defined metrics, namely "fixing chart problems" instead of "fixing sprint problems."

Exactly the same problem can bounce back to you in the case of stakeholders not being familiar with Scrum principles or the ScrumMaster failing to explain exactly what they can expect from such an information radiator.

Options

So what options do we have? I have noticed that keeping a burn-down chart on the user story and story point levels helps to avoid malforming the message. It is hard to confuse virtual units with anything else, especially real time. If someone is not familiar with the idea, she or he will probably ask, not draw wrong conclusions. On the downside, such a presentation can cause unnecessary actions to address nonexistent problems -- all due to relatively low granularity.

Showing an estimate of remaining hours is still popular and supported in tracking software. Such a presentation moves the Scrum team focus from user stories (business needs) to tasks (units of work for one to two team members). While it can keep things going, it can also quickly dismantle the team's sense of the greater goal. Instead of a team committed to deliver the sprint, you can end up with individuals committed to finishing their tasks.

A third option is to measure the number of remaining tasks or stories. This approach, also common in software, can lead you to unexpected problems. Since all units of work (tasks or stories) are treated as equal, you lose any information about their size and impact.

Example

To illustrate different approaches to the burn-down chart, I will use the example of a three-week sprint (13 working days). The data presented is artificial but based on real-life examples.

A sample sprint backlog consisted of exactly 12 user stories, all worth between 1 and 7 story points, summing up to 49. The user stories were split to tasks (39 of them) estimated in hours, adding up to 385. The sprint was delivered successfully.

During the sprint, both story points and remaining hours were tracked. Story points were used for the team, and hours were used for some of stakeholders having interest in them. While I avoid double-tracking if I have a choice, this time it was useful because it gave me perfect data for discussing different types of burn-down.

To add some flavor, I also assumed following:
  • On Day 4, one of the tasks proved to be problematic and was reestimated to a much higher time cost.
  • On Day 6, the product owner asked the team to include a new, emergent user story in the sprint backlog.
  • On Day 9, the team de-scoped one of the low-priority user stories due to the recent addition.
Take a look at how different these burn-down charts for the same sprint can appear:




When you compare count-based charts (on the right-hand side -- numbers 2 and 4) with time-/size-based charts (on the left-hand side -- numbers 1 and 3), you can clearly see that the former are less descriptive than the latter. They are presenting an artificial struggle between being under or over the baseline, which in these cases tells exactly nothing about being on track to deliver the sprint goals. The main problem with such an approach is promoting finishing "any tasks/stories" to get back "under the line."

There are additional traps. Based on the upper-right chart (number of tasks left -- number 2) between Days 1-5, the team could think that everything is going superbly, while the sprint didn't start with quick wins at all. The same goes with Day 8 bringing relaxing news, while in fact the team should double its effort.

On the bottom-right chart (number of user stories -- number 4), the period between Days 5-10 is absolutely misleading, neglecting the fact that the remaining user stories are still quite large.

On the other hand, when you check the burn-down chart based on remaining hours (number 1), you can see how it reflects the events I purposefully added. Day 4 brings slower progress due to the task being reestimated. Day 6 shows no progress due to the addition of the new user story (some hours were added, some removed). Day 9 brings faster progress due to de-scoping.

On top of that, it shows none of the problems seen in previously discussed charts. There is unfortunately information it fails to deliver. If you look on Days 10-13, it seems that everything is going smoothly, while sprint goals are in fact endangered by too many open user stories. They were delivered exactly on the last day.

You can probably see that a story points-based chart (number 3) can show you all the information you need -- the addition/removal of user stories, periods when the team should be especially focused, and an overall feeling how the sprint is progressing. In my opinion, the most positive trait of such a chart is that it does not lie to you. There is no ambiguous message there.

On the downside, the reestimation of a task is not visible at all (Day 4). We can observe its consequence -- slower progress on the following days. One can argue whether this is a good or a bad thing. My personal experience shows that the sprint needs to be extremely stretched for one task to have a large impact on sprint delivery.

Conclusion

With the given examples, you had a chance to compare how the same situation can be presented in different ways. Remember -- the burn-down chart is just an information radiator, and the Scrum team and product owner need to set their expectations when it comes to the message being shared.

While I'm a strong supporter of the story points-based burn-down chart, I must admit that it can be difficult to comprehend at first, for people not experienced in Scrum. My example purposefully focused on a successful sprint that was stretched, difficult to deliver, and for most of the time “over the line.” These messages are not easy to share.

For the remaining hours the burn-down chart can also be useful, but I suggest paying extra attention to the number of opened user stories. You can see great hour-based progress and still fail to deliver much in terms of DoD.

Last, but not least, the number of remaining tasks or user stories is usually a bad indicator of progress. It's faking reality and can bring problems to your team. I strongly suggest avoiding this type of chart unless all your units of work are of exactly the same size.

I hope I have shed some light on how you can radiate information with burn-down charts. Use whatever works for you and keep in mind what kind of message you want to share. Transparency, honest communication about successes or problems, a focus on business needs and delivering working packages, encouraging commitment -- all this will help you with your project.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (3 ratings)

Comments

Gurpreet Singh, CSP,CSM, 3/6/2014 1:18:07 PM
Fully agreed! Scrum is empirical in nature and lets not make it too calculative

You must Login or Signup to comment.