As a Scrum Master, some of my teams resented the burn down and me for pestering them to update their time. Sometimes, teams feel the updating of hours and the burn down are ways to make 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 burn down 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 burn down is pretty, who cares about working software? No ONE b/c the burn down 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 burn down is a great tool when used for good and a Scrum Master can help educate teams and managers on the goodness. Frankly, when a burn down looks too good, I’m a little skeptical.
A daily burn down 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. There’s something taking longer than they thought. Time is being added at a rate equal to or greater than time is being burned. The team isn’t updating their work rendering the burn down 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 outside 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 burn down 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 didn’t really take planning all that seriously and 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 the accuracy of it rather than the ideal and actual lining up nicely 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 – and focusing on those rather than the burn down is preferred.
I like to leverage the demos to do this. Review the sprint goals with the audience. Speak to the target and actual velocity. Show the burn down and walk through the learning points of the sprint with everyone. If the burn down 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 impediments to Agility themselves. Manage to the burn down and you will get a pretty burn down. Manage towards a team’s ability to reliably and frequently deliver working software and meet their sprint goals and you will get a team who cares about that, takes their commitment seriously and ensures you are never surprised and are always aware of what’s going on.