Burndown charts are a great visual way to track the remaining work on a Scrum project. You can track story points completed to get an indication of how your velocity is performing, or effort (in hours usually) to see how your expected completion date compares to your actual/probable one.
Burnup charts are used for a similar purpose, but they hold a key advantage over Burndown charts that not everyone new to Scrum/Agile is aware of. Personally, I love to use Burndown charts because my brain seems to be wired to see project work reduce over time, rather than see it start at zero and build up (with completed points) over time. Nevertheless, I have to concede that Burnup charts are a better tool and I will show you why.
Here's an example of a typical Burndown char:
You can see from the graph above that our project started with 100 story points, and that we expected (blue line) the project to be completed after 10 Sprints or iterations. Or in other words, around 10 points per Sprint. Our Velocity is therefore 10. The actual Velocity (red line) however tells a different story. We can see that is traveling slower than the expected target. In fact, the project completed after 12 Sprints.
Notice Sprint 7. The red line is almost flat. This can only mean that something happened during the Sprint to make the team slow down their Velocity. But what could it be? Did a team member go on holiday? Was someone sick? Did the Product Owner dump a bunch of work on the team which they accepted? Did the team come across a technology problem? Was the Scrum Master unable to remove an impediment to the team? Were there too many distractions from stakeholders? Was the estimation of stories not realistic? Perhaps the team just didn't fill in their completed stories yet?
This chart still tracks points and velocity, giving us the same information as the Burndown chart. However, notice the green line? That is the scope (number of story points etc.) in our Scrum project. During Sprint 7, a further 10 story points were added to the project.
Remember that our Velocity was 10? Well, assuming that the team has done 10 points again during this Sprint (so on target with their Velocity), on a Burndown chart, this would have been displayed as a completely flat horizontal red line, even though the team did the same amount of work.
Both burndown and Burnup charts are great for the team to track their progress; burndowns more at the Sprint level, and burnups more at the Release level. However, Burnup charts are still great at the Sprint level.
We can see from the graph above that the team did very little for the first couple of days, and then picked up steam in the next few days to complete 38 story points worth of work. Notice the red scope line didn't change, but it could have, and we would have been able to see if very clearly. This information can be compared to existing Velocity and even placed on the Release burnup/burndown graph alongside points completed and other metrics.
So does all this mean throw away the Burndown chart and replace it with the Burnup chart? Well, not exactly. The Burndown chart has its place, and as long as you don't need to visually display if a slowdown in Velocity was due to an increase in scope, then a Burndown chart is fine. Yes there are Burndown charts that display histograms with bars that fall below the X axis. I personally can't stand these as I am old school; what is above the X axis and to the right of the Y axis stays there.
Given that OCD stipulation, the Burnup chart is in my view the best visual tool between the two.
Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!
