Evil Burndown Charts

January 26, 2009

This post is in response to Tim Ross’s post on ‘Are Burndowns Evil?

Tim asks how useful a Burndown chart is, especially in the case of a new team with a new or unknown code base. A burn down chart (with an ideal line) for a new team immediately gives a team ‘schedule pressure’. Some may say that pressure instantly kills creativity and induces a ‘get it done’ mentality. I’d like to disagree, just a little bit. I think what little pressure a burn down gives at the start of the iteration can be a good thing. Every team needs a little hustle. Indeed in the case of a new team after a few days of a flat line bundown, this could well start having it’s negative affects, but this is down to the team. Should the team’s first call of action be to abandon all quality, that for me is a people problem. A fresh new team with no idea of it’s velocity should be made aware that the burndown for them is very much an indicator. I think this indicator is always a good thing. It tells us early, if we’ve overcommited and vice versa. It can inform your decision on changing and new requirements.

When a Burndown is used by project managers or anyone else to see how much work is done, you’ve got a small problem there. As Tim notes this just plain aint true. If you’re strict and award your points only when a task is ‘Done Done’ (and not half the points for half the work) you could misinterpret the burndown as saying no one’s done any work. Again its indicating how much of the work, maybe a better way of putting it would be business value, you committed to has been delivered, and perhaps even is ready to ship.

Breakthroughs, insights, and epic refactorings. You can consider these to be big chunks of work that go toward improving the code base and potentially not adding any immediate business value. Now let me stress here that these types of changes go a long way to a maintainable code base. No one likes working with a big ball of mud, and it’s not just a selfish emphasis. From a purely business focused view allowing the time for these kinds of things early and often plain old means you get more for your money in the long run. Code changes get cheaper and code changes. (period).

Burn-downs don’t reflect the value a team gets from such activities very well, and indeed this could lead to a vicious circle of teams never getting to implement these insights, which would be plain wrong. I think the key thing here is to note that the burn-down would actually allow you to make a slightly more informed decision as to when to take on these tasks. Some would say later is always the wrong time to do them, that they would get neglected and forgotten. Now I’m sure small easily lost refactorings should come in to your normal work flow and therefore velocity, so I’m not including them in this. The larger pieces, well they may well need to wait, perhaps even in future iterations they can be thought about and planned for, assigned points. Some what of a technical story, but when it’s presented and it’s value weighted and dare I say it costed, this is something quite more powerful to present to people that pay the bills. The automatic notion that these things should be done as soon as they’re discovered is almost a form of premature optimisation in my opinion.

To summarise, indeed a burn-down charts use can get lost for a new team, and it shouldn’t be the focus of morning stand-ups, it’s an information radiator, not an information altar. Use it effectively, and don’t let it make you feel so bad so easily!

If you’d like to know what good a burn-down chart is for a team that has a velocity, search the Internet.

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

%d bloggers like this: