Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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:

  1. How do we represent added scope in the release burndown chart?
  2. 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?
  3. 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. Mike Cohn's burndown

share|improve this question
add comment

2 Answers

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:

  1. How do we represent added scope in the release burndown chart?
  2. 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?
  3. 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 Burndown chart 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) 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.

enter image description here

(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.

enter image description here

(From http://www.agilekiwi.com/earnedvalue/charting-change/ )

The release can be extrapolated out from the percent complete.

enter image description here

(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.

share|improve this answer
    
MichaelT thanks for putting up comprehensive answer. The dropping/raising floor technique and the Earned Value Management/Charts are very interesting. Will take the time to understand it. I do agree that having added scope as jagged peak does mess up the velocity visibility when we it is examined as straight line. However, in many cases, I think there is a value to highlight it and probably visualize the velocity by other means (like explicit numbers). –  Kulawat The Eidos Jan 17 '13 at 3:31
add comment

This is currently how my colleagues and I solve the burndown problems in the Agile tool that we are building

enter image description here

  1. The added scoped is represented by the vertical line just like Mike Cohn's graph. We also emphasize this with the light-grey bars.
  2. 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.
  3. 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 :-)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.