The daily burndown is an excellent, simple tool for a team to use as a visual indicator of their progress against their original plan to meet the sprint goal. When used by the team effectively some good conversations and re-grouping can take place. The important point to note about the burndown (to me) is: It’s for the team. Granted, it’s also nice for anyone strolling by to get a quick indicator about how things are going, but it won’t tell the whole story.
A burndown won’t tell you if a team is high-performing or not. It won’t tell you their code is good. It won’t tell you “how” they are. Somehow, sometimes people want to measure a teams maturity based on their burndown…daily. Really?
The important element of the burndown is the discipline it teaches the team:
1. Determine a plan
2. Execute and measure your progress against the plan
3. When things look hinky, TALK about why
4. Foster accountability within the team
Frankly, I have seen teams who have a perfect burndown. Everything is going exactly as planned. Riiiigghhhhtt. It makes me suspicious. Management would probably be ecstatic. I say the team learned what was being looked at and figured out how to game it. Management would say they’re mature. HA!
I’ve had teams get to the point where the burndown always looked hinky but it wasn’t indicative of their performance. It was indicative of their maturity. They didn’t require it any longer. At the end of the day, what matters is: Are they shipping working software that is defect-free or not?
Though tempting, using the burndown as an indicator of maturity is misguided and can actually drive bad behavior. Teams should be assessed against the ultimate goal. You want to deliver value faster NOT have teams execute exactly as planned. That’s, well, not Agile.