Is The Burndown an Indicator of Team Maturity?

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.

 

Advertisements

2 thoughts on “Is The Burndown an Indicator of Team Maturity?

  1. I totally agree! I always warn my SMs against sending out “context-free” metrics. If you’re going to send out a burn-down, send out some context. Are you burning down points, tasks, or hours? If points or tasks, did you have some “big rocks” that couldn’t be broken down well, resulting in a plateau followed by a drop-off? What impediments might the team have been working through that slowed their progress?

    Of course, providing that much context makes reporting take longer, to which I pose the question: If you have to add a bunch to a metric to make it useful that can’t be automated, is it worth it? There are other metrics – like complete versus committed, average spill-over, escaped defects, technical debt, etc. – that can be communicated after each sprint, are largely automatable, and require little context to be useful.

  2. Mike – My question to you would be….Why is it being sent? Why not post it and encourage people to come on by? Sometimes I feel like we (unintentionally) make it easy for people to NOT engage meaningfully with teams. I stand by the idea the burn down is really for the team and the other indicators you mention to look at are much more useful for those NOT on the team. Thanks for the comment!

Please leave a reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s