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
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
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
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 ?
Top comments (3)
I have never considered burn up charts before but I think they do a much better job of telling a story. I have never seen anyone really take burn down charts seriously, and at most places I have worked, there is a big period of stagnation for the first few days while everyone fixes stuff from last sprint and then 60% of the work gets done in the 48-72 hours before the demo.
I think the utility all depends upon how effectively an organization uses Agile. If you pressure the team to make stupidly optimistic estimates in order to look good in front of the client, you're going to have a hard time explaining that away no matter what. If we need several days of remediation every single sprint, does that mean we never are actually completing a sprint successfully?
You did an excellent job making the case for burn up charts, and in organizations where people are valued over process, I think it provides a lot more context.
Haha, I know what you mean !
Thanks for the input.
I think that burnup charts are a valid alternative, I think you made some good points. In addition, if possible, I would reserve some time (maybe 20%) for “slack”, i.e. time that you don’t plan in advance. If something unexpected happens, you use that slack time. Otherwise, you use it for refactoring, bug fixing, learning or communicating what you’re doing to the rest of the org.