Tag Archives: burndown

Burndown Charts That Suck #1

Over the past year or so, I’ve collected some burndown charts that illustrate some team problems. I don’t want to tell tales on past clients, so no names will be revealed by me. And for that matter, people always mean to do their best, but sometimes it’s an emotional challenge to fix things (see the second to last paragraph below).

For each image, I’ll list a few ideas I have about why the team’s progress looks as bad as it does.


  • mis-use of an agile tool (stories weren’t “in” the sprint when the start button was pushed)
  • stories not broken down into small enough pieces
  • probably not really using daily meetings to report progress.

  • mis-estimated some of the work, or actually had done work before the sprint started
  • …and then somehow managed to get stuck on the remaining work
  • meanwhile, a points worth of work failed at the end of the extended sprint–why wasn’t some qa-like work done earlier?

Screen Shot 2014-11-18 at 9.38.34 AM

  • Oh please. Admit that you didn’t meet the commitment, and move unfinished stories into a new sprint. Figure out why you struggled, and fix that problem.

I think there are two themes that pop out here. The first is using and relying on a tool before fully understanding the underlying principles. That first image, where all the scope of the sprint is added after the sprint has begun, illustrates a simple “record-keeping level” problem. But there are larger problems with tools. They’re built for some specific requirements, requested over time by people using the tool. But those people are not you or your team. You and your team will look at all the fields and dropdowns and buttons on the tool’s interface and decide you have to use them, even if you don’t know what they are for. Before figuring out what is important for you to track, you are puzzling over how to use someone else’s idea of tracking. This just leads to confusion and losing your focus to things that are actually meaningless to you.

When coaching, I really do prefer to start teams using paper and pens. Using simple manual tools forces simplicity. Simplicity gives you the chance to understand the process you are creating before it grows.

The second is a more emotional issue: teams are uncomfortable to admit failure.  Look at that last image. It is the map of a massive failure of some sort. “Extending” the sprint is much less confrontational than saying “something is broken.” But as hard as it is to admit failure, admitting failure is the first step in fixing the causes of that failure.

I don’t know if I heard this phrase somewhere else, but I’ll use it now: “Fess up when you mess up.” Then use your retrospective to make some improvement, somewhere in your process, or your team organization or your client/product owner relationship. Don’t let your burndown charts look like these.