Understand Burndowns and Burnups

Many teams that use iteration-based agile approaches use burndown charts, with which they measure progress against time, as shown in the following figure.

Many teams add an Ideal line to their burndown, as shown in the figure. The Ideal line is supposed to be a reality check—it allows the team to measure against time and what it thought it might do. The idea is that the team should make steady progress, completing work throughout the iteration.

In either of these charts, you can see there are times when not much is done. Then, near the end of the iteration, the team finishes more. However, the team members don’t finish “everything” before they run out of time.

An iteration is a timebox, by definition. Regardless of your “done” state on the stories, when the timebox is over, the team ceases its work and demonstrates and retrospects. Regardless of what the team has or has not completed, the demo and retrospective help the team understand what it did and did not do, and why.

These burndowns are from a specific team. When this team saw its original burndown, two interesting things happened. The team members beat themselves up for not finishing. And when they didn’t finish everything, they didn’t always do a retrospective. In addition, the product owner often took the unfinished work and added it to the next iteration’s work. Yes, added—not replaced. That meant they never caught up.

When they tried to follow the burndown chart with the Ideal line, they realized they were “late” and off the Ideal line from Day 2. They felt worse about themselves. They stopped doing retrospectives, which meant they had no idea why they were “late.”

I am emphasizing the word “late” here, because a team might not be late. It may have misestimated, or maybe someone was out sick for a couple of days, or someone got pulled into another project and is not working on the team’s work. All of these problems are causes of “lateness.” The burndown increases the idea of lateness.

A burndown shows what you have completed against time. A burndown with the Ideal line emphasizes what the team did and what the team should be doing.

A burndown is interesting, but not actionable. Think about what happens when you take a trip. You plug your destination into your favorite GPS (or app), and it calculates how long it will take to get to your destination. You know you have driven some number of miles, but to be honest, that’s done. You can’t change what’s done—and you don’t want to. What’s interesting to you is what you have remaining. That’s what a burnup chart helps you see.

A burnup is a way to see what we have accomplished and what’s remaining. I can learn more from a burnup than I can from a burndown. The following figure illustrates a burnup of the same data.

When I see the Story Points Done burnup chart without the Ideal line, I see a hockey stick. When I see a burnup with the Ideal line added, shown in the figure, I can tell by Day 3 that we are “behind” where we want to be. By Day 5, I know we cannot make up the time. As any team member, I can raise this as an impediment in the daily standup. If I am a leader of any sort, I will put this on my list to discuss in the retrospective, if not problem-solve beforehand.

Maybe that’s just the way my mind works. I like seeing where we are headed and what it will take to get there. I’m interested in what we’ve done, but that’s in the past. I can’t address the past except to retrospect. I can address the future and say, “Is there something we can do now to help us accomplish what we thought we could in this timebox?”

This team finally realized—when it changed to burnup charts—that it was trying to cram too much into an iteration. The team made its stories smaller. That put more pressure on the product owner, but then the team realized lack of product owner time was an impediment. The team had thought it was to blame with a burndown. It saw its data more easily with a burnup. Maybe we all had a mind-meld going on.

It doesn’t matter which chart you generate. It matters how the chart makes you feel: what action will you take from your chart? If it’s not prompting you to act early, maybe you need a different chart. One project truism is: You cannot “make up” time. You can choose actions based on what your data tells you.

Your team owns its data. Visualize it in a way that works for the team. I recommend you use a burnup, but that might not fit for the team. If you prefer to use burndowns, check out George Dinwiddie’s great article on burndown charts.^[20]

If the team works in an iteration-based agile approach, consider iteration burnups to help the team see its velocity and its rate of finishing.