I admit to mixed feelings about Sprint burn-downs.  I recognize I might be in the minority on this.

In theory, they are useful.  A good burn-down provides a quick at-a-glance view of how the team is progressing within a Sprint toward their goal, and shows where things might be tracking behind and adjustments might need to be made within the Sprint.  Sounds awesome, right?

Sure.  But does it really work that way?  My experience is that it really doesn’t, and so that’s about where my personal tolerance for burn-downs ends. I recognize that, for others, the burn-down is awesome.  If you’re reading this and you love burn-down charts and they are working for you, that’s fantastic.  Keep it up!

The reality of every Sprint, of course, is that work changes as we learn things.  User Stories may be moved in or out of the Sprint, and tasks will be changed as we go. Particularly in the first few days of a Sprint, the burn-down is more likely to look like a child’s drawing of mountains than an actual burn-down. If a Scrum Team successfully identifies ALL work in the Sprint up front, along with every task (correctly estimated), and nothing changes whatsoever, then yes, the burn-down is neat.

When was the last time this happened?  I can honestly say “I don’t remember this ever happening.”  New work is always being discovered, defects are being found as QE starts testing the functionality being added to user stories, and the Sprint Backlog is a living artifact of work.  If the Sprint Backlog is written in stone on Day 1 of the Sprint, there’s probably something going on that the Scrum Team is missing.

In fact, I have seen clean burn-down charts once ever, and that was when everyone was just making it up and burning hours off tasks at random to account for a full day’s worth of work at 100% utilization.  If you don’t know why that is bad, refer back to the very first post here!  We would talk a lot about transparency, and then produce the most opaque — and false — charts ever to make sure we looked good.

From that, you might guess that I’m not exactly a fan of the burn-down chart.  I might have been overheard several times saying “I don’t care about the burn-down.”  They’re mildly interesting at best (to me). Most of the time, I ignore them completely.  I’m more interested in the discussion the Development Team is having about their progress toward meeting their Sprint Goals, than what the burn-down chart looks like.  Toward the end of a Sprint, the burn-down starts to gain importance as it provides a clearer picture of how close the Dev Team is toward the ultimate goal of a working increment of Done software, but even then, it’s not the tell-all.

The true story lies in what the Development Team is talking about during their Daily Scrum, and in the conversations they are having with the Product Owner about moving toward Done.  Actively listening during these conversations will answer your questions far better than a burn-down chart ever could.

Let me note that this is just Sprint Burn-downs!  Product and Release burn-downs — and burn-ups — are far more useful as they show the bigger picture and the day-by-day anomalies that often happen during a Sprint balance out when looking at velocity over time toward a larger goal for the product.  I absolutely use burn-ups to forecast when a team will hit product milestones, and what the cone of uncertainty looks like.  

Don’t focus on the pretty chart.  Focus on what the Team is saying, and you’ll find you have the best information possible.