I have been in various Agile projects and seen many release burndown
chart styles. Most of them were handled manually since somehow all the tools that I have run across don't produce really useful burndown charts.
A number of tracking systems do produce reasonable burndown charts. Redmine for example has a plugin that will present various charts. Similarly Jira has a burndown chart, too.
In reality, we may not be dealing with all stories estimated and we
just keep burning down. Many times, the scope is added during the
The key here is to separate the "all stories" from the "target release". Not all the stories are in scope for a given release.
Looking at Redmine's roadmap for itself one can see a distinction between things worked on for the next release and things candidate for a future release.
Currently, I am dealing with these problems with the burndown chart
and have questions about the following things:
- How do we represent added scope in the release burndown chart?
- How do we deal with unestimated stories in release burndown chart assuming that there are high probability that we will do it but we
just do not have time to estimate them yet?
- How do you project the end of the release?
Part of the burndown chart is the visibility of velocity of the project. Having a jagged peak approach to the burndown chart means that the added scope messes up the velocity when examined as a straight line on the chart (and to an extent, may also confuse the projected target).
Instead, consider dropping the floor for increased scope and raising the floor for reduced scope. An example of this can be seen in
Where the drop in the blue line shows an increase of scope.
For unestimated stories, there are two options - either do an estimate and refine it later (this is a valid and appropriate estimation technique known as the cone of uncertainty)
( From http://www.construx.com/Page.aspx?cid=1648 )
Or estimate them at 0 initially and regard them as increases in scope.
The end of the release is when the remaining work intercepts the scope.
A chart that I like is known as the Earned Value Chart. Its an "up" style chart rather than a "down" style. The numbers are percents so that both the cost (the total hours used / total hours allocated) and the scope (as a percent of estimates done to total initial estimates) are on the same scale.
(from http://www.agilekiwi.com/earnedvalue/agile-charts/ )
In this example it can be seen that the hours used so far are more than originally budgeted and that the amount done so far is less than the ideal. This project is in trouble.
In this model scope increases are shown as recalculations of the percents.
(From http://www.agilekiwi.com/earnedvalue/charting-change/ )
The release can be extrapolated out from the percent complete.
(Also from http://www.agilekiwi.com/earnedvalue/agile-charts/ )
The realm of understanding this chart is known as Earned Value Management - there is a significant amount of work done in understanding these charts in a number of industries.
I strongly recommend reading the Agile Wiki charting change series - Charting Change and Agile Charts - my linking of the images glosses over a fair bit of the material on the site.