Sprint charts : Burn down or Burn up ?
Tags: agile, scrum, discuss
Published: 2019-07-21 13:54:30

So my team has been working with Scrum (or at least some scrum-inspired in-house methodology) for a few month now, and I realize that I'm not entirely satisfied with the Burn down charts that gitlab (or most other tools) is providing us. I feel they don't always tell the whole story.

I found that burn *up* charts are a lot more interesting, but I don't see many people using them. So maybe it's just me ? Or maybe we're not planning the way we should ? Let me explain my point and tell me what you think in the comments !

## The "Ideal" Sprint
![](https://thepracticaldev.s3.amazonaws.com/i/bd1trbyfxk5l0s9af03y.png)
<figcaption>An ideal sprint : burn down chart on the left, burn up on the right</figcaption>

Let's consider a pretty perfect sprint above. We determined our team velocity and estimated that as a team we could tackle about 100 points a week. Then during sprint planning we estimated some tasks and put 100 points worth of tasks in our sprint. In this example it worked really well and we were able to complete all the tasks in time at a very steady rate, yay !

Here the two charts are not really that different : The burn down chart on the left starts at 100 points in the upper left corner with the red line representing the number of tasks (or rather points) left to complete, and the goal is to bring it down by following the dashed grey line as closely as possible. The burn up chart is working the other way : The blue line at the top represents the number of points to complete, and the aim is to complete them all and bring the red line up.

In this ideal scenario there's no real advantage to a burn up chart, but honestly I have yet to see a chart that looks like this in our team, so let's move on to other scenarios

## The "Can we just add this tiny task ?" Sprint
![](https://thepracticaldev.s3.amazonaws.com/i/bgcbd1al80dy4gz6pepd.png)
<figcaption>A sprint where we added a task : burndown chart on the left, burn up on the right</figcaption>

That's when things start to go South. In each an everyone of our sprints there's always something that we did not anticipate and that we just have to deal with. So naturally we add a task to the sprint and we try to handle it the best we can. Sometimes it works out, and sometimes it doesn't.

In this case it didn't quite work out as we can see on the charts. But what's interesting is that by looking at the traditional burn down chart we don't know what happened. It just looks like for some reason the team got less productive towards the end of the sprint (which can indeed happen if we hit a roadblock). The burn up chart is a lot more interesting here because we clearly see that the team handled exactly the amount of work that was planned, but we missed our objective because we had to add on to that.

## The "Maybe we don't need that" Sprint
![](https://thepracticaldev.s3.amazonaws.com/i/tsc9uxawrmqnsf1rdyqw.png)
<figcaption>A sprint where we removed a tasks : burndown chart on the left, burn up on the right</figcaption>

This is the opposite of the previous example : At some point during the sprint something was dropped. Maybe we had to wait for something external to the team and decided to move it to a future sprint, or someone changed their mind about a feature, or maybe we just realized we were late on that sprint and decided to cheat a little and remove less critical tasks...

Anyway, the result is that with a burn down chart everything looks fine : We completed our 100 points ! But once again the burn up chart shows the whole story, and we clearly see that we only did 80 points worth of tasks.

## Why does it matter ?

As we saw from the examples, Burn up charts only make a difference when tasks are added or removed mid sprint, so if this never happens in your team it won't make much of a difference. If that's the kind of things that does happen, it can give you a better view of what actually happened.

The goal here is not to put the blame on someone when expectations aren't met, but simply to be able to better adjust our velocity for the next sprints and get more efficient as a team. I feel that if we can better visualize what went wrong (or right), we'll be able to better plan the next sprints.

So what do you think ? Are burn down charts just fine, or is it better to use burn up charts ? Or do you have a completely different way of evaluating a sprint ?