Scrum Glossary – Burn-up Chart

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 one of these terms in the Scrum Glossary: The Burn-up Chart. The glossary has the following description:

Burn-up Chart: a chart which shows the amount of work which has been completed. Time is shown on the horizontal axis and work completed on the vertical axis. As time progresses and items are drawn from the backlog and completed, a plot line showing the work done may be expected to rise. The amount of work may be assessed in any of several ways such as user story points or task hours. The amount of work considered to be in-scope may also be plotted as a line; the burn-up can be expected to approach this line as work is completed.

Seems really similar to the Burn-down Chart doesn’t it? Because of these similarities, I will take extra caution to ensure the differences are well described while writing this article. For anyone unfamiliar with Burn-up Charts the difference will already be somewhat more clear through a couple of examples used by teams:

Let’s break down the description of the glossary:

a chart which shows the amount of work which has been completed.

This might feel like a repeat from the previous article about the Burn-down Chart. However, note how this sentence talks about the amount of work completed. What different information does this give us? Well, it looks at the past. Hence, why it does not say anything about future work still coming and effort needed as it does in the Burn-Down Chart. This is quite literally exactly the amount of work the team has completed when looking to the past plotted on a chart.

Time is shown on the horizontal axis and work completed on the vertical axis. As time progresses and items are drawn from the backlog and completed, a plot line showing the work done may be expected to rise.

Time vs Work Completed. Here’s why, from a distance, a Burn-up Chart looks like a vertical mirror effect has been applied to a Burn-down chart. The plot line is expected to go up as more work is completed! Note: We are still tracking work done, which means work is to be considered finished before the plot line moves up. Although more rare, a plot could move down or remain the same even when work is being finished. In my experience this is for a single reason: Work that was considered finished in the past, through insight gained, was actually not finished at all and is removed from the Burn-up Chart. It should be clearly communicated how the team handles this, as I’ve seen alternatives where the team decided to keep the previously tracked done work on the chart. This could potentially result in a wrong image of the past as it will distort historically data on actually finished work overtime if the unfinished work is not flagged in any way.

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

The way the amount of work is assessed introduces the same anti-patterns you might see with a Burn-down Chart. It’s, as described previously, about work completed. This means the Burn-Up Chart can be updated as soon as an item has been completed, and shouldn’t be updated when X hours have been worked on an item. Doing so, or even worse, evaluating performance on amount of hours completed on a Burn-up Chart would introduce all sorts of behaviour to game the system. Scrum is dependent on finishing work to properly apply empiricism to our Product Development. Hence, why done work could be tracked in any way, but it should still only be on done work for a Burn-up Chart.

The amount of work considered to be in-scope may also be plotted as a line; the burn-up can be expected to approach this line as work is completed.

If you’ve never seen a Burn-up Chart this sentence makes very little sense. However, this plot line showing amount of work considered in-scope will be a plot line at the height on the Y-axis plotted to the scope of Product Backlog items in the Product Backlog considered in-scope for this release, milestone or product even (the latter which would make it the entire Product Backlog).

We would be able to look at the amount of work completed and where the in-scope plot line is to get some information for a possible forecast as to when the team would be finished. As this is still all in the realm of uncertainty due to this being inherent to Product Development, it will remain a forecast only. If we continuously see the in-scope plot line moving up, or even moving up faster than amount of work done plot line is moving, there’s an interesting conversation to have here. In the first scenario it means more work is being added to the scope. This isn’t necessarily a bad thing, it could just be through gained insights. What it does show is the possible impact on the forecast on time when it’s finished. However, if the in-scope line is moving up faster than the amount of work done it means the team, with the current amount of work being added to the in-scope Product Backlog items every Sprint, will never be able to finish everything if this consists. A Product Owner might make decisions on whether to remove existing Product Backlog items and/or decline new Product Backlog items from the scope to at least somewhat match the speed the team is able to finish work.

Conclusion

As you can read in the article the Burn-up Chart is eerily similar in description and looks at first glance to the Burn-down Chart. The purpose is different altogether though. Where the Burn-down Chart is used to continuous adapt a plan to reach a Sprint Goal, milestone or release by looking at our current understanding about what needs to be done, the Burn-up Chart is used to forecast and make adjustments based on historical data. Something important and commonly misinterpreted in both charts is that we are only looking at units finished work in the sense of Product Backlog items at the lowest level. Effort can be estimated at a lower level, through hours, tasks, story points or anything really, but they will only be tracked per item to prevent anti-patterns where the team stops focusing on finishing work.

I hope this article has been useful to you in explaining the Burn-up Chart a bit more. Any experiences your have with them? Want to share other pitfalls I haven’t mentioned yet? Next time we will be discussing the concept of Coherence. Hope to see you there!

LEAVE A REPLY

Please enter your comment!
Please enter your name here

*