Can You Feel the Burn(down)? How to Use Burndown Charts for Good, Not Evil.

As a ScrumMaster, some of my teams resented the burndown chart and me for pestering them to update their time. Sometimes, teams feel the updating of hours and the burndown are ways to make micro-managing easier. And, sometimes, that’s EXACTLY what it is used for. It’s sad but true.  So, what happens when this “evil” scenario is true?

1. Managers have a false sense of security that all is right with the delivery team. They really like that. As managers, it’s a bragging point.
2. Teams don’t get a sense of what might be “off” easily.  This means a delay in realizing there’s a problem. This is good when teams don’t want their managers to know there is a problem.
3. The environment teams work within doesn’t improve enough to foster honesty and transparency. This means no one really wants to learn about problems much less prevent or fix them.
4. The evil cycle continues because, without transparency, you can’t build trust. A good burn down isn’t, by itself, a reason to trust. Also, teams who have managers who manage to the burndown may have a hard time trusting their manager. Does the manager REALLY want to know about, care about or help fix a problem?
5. The Principle “Working Software is the Primary Measure of Progress” isn’t ever true. I mean, as long as the burndown is pretty, who cares about working software? No ONE b/c the burndown is perfect!

When managers show value for the burn down rather than meeting the Sprint Goals and the team commitment, the team will ensure what the manager values looks AWESOME thereby completely missing the point. The burndown is a great tool when used for good and a ScrumMaster can help educate teams and managers on the goodness.  Frankly, when a burndown looks too good, I’m a little skeptical.

A daily burndown is an easy, quick, daily graphical representation of how the team is doing against their plan. The key word there is THEIR plan. If something looks off, it’s a signal for all of them to take a look.

Burndown Smoke Signals

Time is being added at a rate equal to or greater than time is being burned. There’s something taking longer than they thought. Perhaps the team isn’t updating their work rendering the burndown inaccurate. There are other possibilities as well but, the point here is the team needs to take action.

They own their commitment, right? They also own the plan. If something is taking longer, what is it and what can be done – now – to correct it? There’s no need to wait for retro. They can jump on it and get back on track. It could be scope creep introduced somewhere. It could be an impediment they’re spending too much time trying to resolve and need to escalate beyond the team to get help. It could be something they’re making more complex than it needs to be (perfect is the enemy of good).

Time being added faster than the burndown. This means they’ve learned more as they dove into the story further and there’s more to it than they thought. They can work with the PO to see what modifications to scope can be made. They need to re-visit their plan quickly to correct and let the PO know what has changed and what it means.

The team isn’t burning their time down. This could be because they don’t see the value as a result of never having used it for its intended purpose. If teams aren’t using it and aren’t taking action to refine and adjust as they go, surprises await the PO and stakeholders at the end of a sprint which is no good.

Helping the team see the value and teaching managers to value of accuracy rather than the ideal is a good first step. The team demonstrating their value for it through the actions they take – when necessary – to address it builds trust with the PO and the managers. Reminding managers of the true goal – WORKING SOFTWARE–and the importance of hitting the established sprint goals rather than the burndown is preferred.

I like to leverage demos to do this. Review the sprint goals with the audience. Speak to the target and actual velocity. Show the burndown and walk through the learning points of the sprint with everyone. If the burndown looks good but the goals and target velocity were missed THAT is what managers need to spend time on. I also like all of the above to use in Retro too. Let the team consider the data to inform their growth opportunities and actions coming out of retro.

Burn downs are good…unless they’re obsolete and not used correctly. Then, they’re evil and can impede Agility.  Manage to the burndown chart and you will get a pretty burndown. Manage to the team’s ability to deliver working software and meet sprint goals, and you will get a team who cares about their commitment to adding value seriously.

***This post was originally published on Valerie’s blog, AgileYammering.com.***

If you need help establishing solid Agile practices (to use for good), you can explore our Agility Tune-Up service. This service helps your organization fine-tune your Agile practices so you can stay focused on achieving business outcomes.