The Scrum Glossary is an often overlooked page on Scrum.org that goes a bit deeper into terminology commonly seen in relation to Scrum. These are not always a mandatory part of doing Scrum, but are often common terms seen used by teams using the framework. I feel that the glossary takes away a lot of misconceptions that the Scrum Guide does not always take away, due to it not being Scrum and therefore not mentioned or for the sake of brevity. I am not going to explain the use of practices or parts of Scrum as these have been described over and over. These articles have a different purpose, which is to instil deeper understanding about aspects of or related to Scrum for the practitioner.

Today we are going to talk about the first of these terms in the Scrum Glossary: The Burn-down Chart. The glossary has the following description:

Burn-down Chart: a chart which 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. Also see: Burnup Chart

For anyone unfamiliar with Burn-down Charts. Here’s a typical example used by a Scrum Team for their Sprint Backlog:

Let’s break down the description of the glossary:

”a chart which shows the amount of work which is thought to remain in a backlog”.

This already addresses an antipattern I commonly see happening for Scrum Teams that use Burn-down Charts in Scrum. They would be looking only at the work completed and patting themselves on the back for the amount of work they have finished. However, this is not the purpose of a Burn-down Chart. In Scrum we use the Sprint Goal to set the Development Team a committed common purpose they work towards to create an Increment. The reason we do this, and not just commit to a set of Product Backlog items sits in the reason we do Scrum: Product Development means we have to work from assumptions and validate these asap. This means our plan to create something will inevitably change, even within a Sprint. This is the nature of Product Development. So there’s a good reason to keep an eye on amount of work left to create our Increment since this will most likely change not only because we are finishing things, but also because of gained insights, impediments and other changes on the path towards the Sprint Goal. As this is continuously happening it’s good to understand that we are looking at the amount of work which is thought to remain in a backlog and not what we have already delivered.

Note how it only says “backlog”. I just explained how this works for a Development Team in a Sprint. A Burn-down Chart might just as well be used on a Product Backlog. It’s use might be the same, albeit over a bigger scope, but the burndown could be towards a release or a milestone.

Time is shown on the horizontal axis and work remaining on the vertical axis.

This statement is deceivingly simple. Time vs Work remaining right? However, Work remaining in this single sentence is a vague description at best and Time, although less, can be subject to misinterpretation as well . It’s very important to clarify in your axis what we mean by both, so we can create a common understanding of what the Burn-down Chart represents. Time is commonly portrayed on the X-axis per working day in the current Sprint, or per Sprint over a Product Backlog. There’s differences between teams using it in a current Sprint, like showing non-working days or not, which makes it even more important to clarify this (as no work will probably be finished on a non-working day, resulting in a natural flatline). Work remaining is represented on the Y-axis and I’ve seen it represented in Product Backlog items in the Sprint Backlog, complementary practices like Story Points or other relatively estimated points left in the Sprint Backlog or even estimated working hours. In the case of a Product Backlog Burn-down Chart, I have most commonly seen it tracked in Product Backlog items. Again, important to make crystal clear what we are tracking here.

As time progresses and items are drawn from the backlog and completed, a plot line showing work remaining may be expected to fall.

This describes how completing items will be expected to influence the plot line showing work remaining. Key word is: Expected. If it doesn’t fall when using it on the Sprint Backlog and the Development Team is completing items, something interesting is going on. The amount of effort they think is needed to reach the Sprint Goal is apparently increasing overtime. This could be for a numerous amount of reasons: Through gained insights about complexity the Development Team added more work needed or increased the effort of certain items. Impediments could be slowing down or blocking the Development Team from completing their Sprint Goal and they need to fix these first. Not seeing the expected fall in work remaining makes for interesting conversation during a Sprint.

If it doesn’t fall when using it on a Product Backlog and every Sprint items are finished, more work is either coming in, or through gained insights the work remaining is considered more effort than before.

The amount of work may be assessed in any of several ways such as user story points or task hours.

We just discussed how work remaining is represented on the Y-axis already. However I would like to inject a common misinterpretation here which is especially relevant when using the Burn-down Chart on a Sprint Backlog. It says “task hours” here, which could be interpreted as the amount of hours we already spent on the work. I commonly see teams “burning down” worked hours on their Burn-down Chart and in the end having a chart be at 0 remaining hours and the work still not being done. What went wrong here? Well, the Glossary described that we are looking at Work thought still to remain the backlog. So this means the team is actually tracking the wrong things. Through insight, even in hours effort estimated items will need to be readjusted.

A secondary concern is that the team is not actually looking at finished work, but just the hours they spent. Worst case scenario: the Burn-down Chart will be showing only 10% work left and nothing has actually been finished yet, because everything is at 90%. Only burn down when an item has been finished, because we are using the Burn-down Chart to determine if we need to adjust our plan to reach the Sprint Goal we need to focus on finishing work, not working hours.

Work remaining in Sprint Backlogs and Product Backlogs may be communicated by means of a burn-down chart. See also: Burnup Chart

This sentence confirms again that we look at work remaining when using a Burn-down Chart. It’s a common tool used to communicate this to fellow Scrum Team members, Stakeholders and anyone who would find the information relevant. It should provide us insight on the current understanding of the amount of work left vs the time left to do it to have a conversation on feasibility of actually finishing the work and provides some more data to vouch for adjusting the plan to reach a Sprint Goal, a milestone or a release if needed. The Burnup Chart that is mentioned refers to a tool used to look at work completed which is where it differs from the Burn-down Chart.

Conclusion

I hope some misunderstandings about the Burn-down Chart have been clarified after reading this article. Myself, I actually finally realised the Burn-down Chart is also useable in Product Backlog context. This was new to me, as it’s not commonly used from my experience. Next time we will be looking at the Burnup Chart, the second term in the Glossary. If people feel this is useful, I’m planning to do all 33 terms from the Scrum Glossary so expect more in the near future. What do you think? Seen the misunderstandings I’ve seen? Have you been applying this complementary practice to Scrum? What’s your experience? Comment below and I’m willing to talk and discuss with you guys.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

*