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.
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 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 is 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?
The burndown chart below is from the fictional case study in the appendix of classic Mike Cohn’s Estimating and Planing book.
0
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
release.
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.
1
This is currently how my colleagues and I solve the burndown problems in the Agile tool that we are building
- The added scoped is represented by the vertical line just like Mike Cohn’s graph. We also emphasize this with the light-grey bars.
- Unestimated stories are calculated based on current average velocity (of estimated stories) times number of unestimated stories. They are shown in the darker-grey bars. Estimated stories are shown in the darkest-grey bars.
- Projection is based on the velocity of the last three iterations but we give more weight to the later iterations.
The graph does not look like it is burning down but it does reflect the reality that the scope is being added along the way and there are number of stories not estimated. We think this is a Really Useful Burndown Chart, at least for our internal projects, and we certainly welcome feedback 🙂
0