Go Up Not Downon May 31, 2012 in Agile, Software Development Process by Lawrence Owusu
Burn down charts are used a lot in giving a visual idea of the velocity of team; what has been done, what is yet to be done and an estimation of what we are likely to achieve by the end of the project.
However, there seems to be a major flaw with this chart. Refer to Fig 1.0 below (click on the image to see the full chart). You will notice that with this chart, we start with a scope (total number of story points) and then based on our estimated velocity we try to determine what we expect to do by the end of the project. However, the whole idea of scrum is to say that we do not know how long this project is going to take, but we have made an estimate of how big the project is and are willing to update this as we go through sprints, because of the in-built feedback mechanism.
With the burn down chart, we start with a fixed number of points and it seems to contradict the whole idea of scrum (learn and improve as we go along).
Fig 1.0: A typical scrum burn down chart.
It is possible to alter the scope of a project while it is in progress, but it’s difficult to represent this on a burn down chart without explicitly labelling the change. Imagine that when the scrum team reaches a point where there are 60 story points remaining, the business adds 10 points to the scope of the project. If the scrum team completed 10 points of work during the sprint, they would finish exactly where they started – with 60 points left. This would create a flat line on the progress chart, giving the impression that the team had not done any work!
However, a burn up chart seems to be a better chart and it is rich with more information. Refer to chart 2.0 below (click on the image to see the full chart). We start from zero and as we complete a sprint we update the chart.
If the project is bounded by time we can easily tell how much work we are likely to complete by drawing a vertical line to represent the end of the project and extending the estimated burn up line to meet it. Likewise if the project is bounded by scope we can simply draw a horizontal line from the required number of story points and extend the burn up line to get an estimate of how many sprints will be required to complete the work.
We can also easily tell how many more sprints we need if more scope is added in the middle of the project by raising the scope line.
Fig 2.0: A burn up chart showing more information than Fig 1.0 above.
In conclusion, although the burn down chart has been useful to many an agile team, using the burn up chart allows more flexibility and shows more information. Give it a try!
NB: Many thanks to Adam Shone who contributed to this article.