{{announcement.body}}
{{announcement.title}}

The Ideal Burndown Chart

DZone 's Guide to

The Ideal Burndown Chart

A breakdown of how the "Ideal Burndown" chart is not the best indicator of productivity.

· Agile Zone ·
Free Resource

You probably have heard of the 'ideal' Sprint burndown chart. If you search with Google, you'll find graphs like these:

Image title

The ideal line is going down in a straight line from top left to down right. This indicates a healthy project and a well-functioning Scrum team. Value is being delivered constantly in a linear fashion.

If the burndown chart is a flat line, it is plateauing. This indicates that we have too many features, or have a poor estimation. Your team is inexperienced, in desperate need of a skilled Scrum master, and requires lecturing on the proper ways of Scrum, preferably by an experienced Scrum consultant.

I disagree.

The ideal line is a fantasy. A typical Sprint contains stories of various sizes, some small, medium, and large tasks. The team will jump on the large tasks firsthand if anyone has the capacity, some of the medium tasks. The small tasks are saved for last. This will lead to the following burndown chart.

Image title

Have you ever read how dysfunctional you are as a Scrum team if you have such a burndown chart? Have you ever had it and wondered why? Have you ever wondered where the hidden problems lie? Theory dictates that you are, in fact, a dysfunctional Scrum team, even if development seems to be going fine. Well, the theory is a fantasy based on some ideological belief that value is delivered incrementally in equally sized chunks of work.

A healthy team covers the long, difficult tasks first, and then the medium-sized tasks, and finally the smaller ones. Someone may even have started working on this one critical bug first.

This explains every single drop off in the 'dysfunctional' burn down chart.

Must have, should have, could have, would have (MoSCoW) is at work here. When dealing with uncertainty, and risk, you can't have a perfect estimation, and you manage scope according to priorities. That's business as usual in DSDM and unless you're doing something that you have already done several times before, with the same team and same technology, the ideal burndown chart will not be achieved. Those projects are boring and of low added value anyway, so why even bother?

The ideal burndown chart is an indication that you're doing something of low added value.

It is not you, the theory is wrong.

Topics:
scrum ,project management ,risk analysis ,software development methodologies ,adopting agile ,agile project managament ,estimation practices

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}