Kane Mar

The Enhanced (or Alternative) Release Burndown graph [1],[2] is a great tool and one of my personal favourites. It demonstrates several things very clearly. It demonstrates:

• The rate at which work is being completed by the team
• The rate at which new work is being added to the product backlog
• And, it can be used to determine a date range for completion.

At first, a Release Burndown graph can appear quite chaotic, but once the trendlines are drawn, the intent of the Release Burndown graph becomes clearer. You can clearly see how as work is completed (top trend line), and how work is being added to the backlog (bottom trend line). Here’s a typical example of a release burndown:

When observing the trendlines there are three interesting patterns, each of which is discussed below.

Converging trend lines
This is the ideal scenario. It clearly shows that work is being completed (top line) faster than work is being added (bottom line). As a result we can project to where the two lines cross, and when the project will be completed.

Diverging trend lines
Diverging trend lines are actually quite common, especially during the first few sprints when the scope of the project is still not fully understood and the product backlog is undergoing major revisions. It shows that work continues to be added to the backlog faster than it can be completed. If the divergent trend lines continue, this may be a cause for concern. Effectively controlling any increase in scope is key to turning this scenario around.

Parallel trend lines
This is intresting because it tells us that work is being added to the project at the same rate as it’s being completed by the team. In this scenario, the team clearly has no end in sight. Teams that are the first responders to critical application failures often have this type of product burndown graph.

References
[1] Mike Cohn’s Enhanced Product burndown graph.
[2] An alternative desciption from the scrumworks wiki.
[3] Agile Estimating and Planning, by Mike Cohn