A Burndown Chart Can Do a Lot More Than Just Monitor Progress
Project managers are control freaks; I should know I have been one for well over 15 years. Part of the control fetish is to have the finger on the pulse and, therefore, on the project metrics and forecasts. To enable us get to this “place of enlightenment” we need to look to the burndown chart.
In this article, I take a detailed look at the burndown chart and see how it can be used to monitor team velocity through the release plan and then on into the sprints. Not only is the burndown chart a useful tool, but it is important to note that it forms part of the fundamental set of artifacts in a Scrum delivery.
So what is the formal definition of the burndown chart? The Scrum Alliance says the burndown chart is produced to “… show work remaining over time. Work remaining is the Y axis and time is the X axis. The work remaining should jig up and down and eventually trend downward.”
To enable the project team to monitor their progress against the release plan they must maintain a release burndown chart after each sprint.
The X-axis of the release burndown chart shows the sprints; the Y-axis shows the amount of work remaining at the start of each sprint. Work remaining can be shown in whatever unit the team prefers–story points, ideal days, etc. I prefer to use story points as they tend to focus the team as to complexity as opposed to task related time units.
In the simple example shown in the diagram on the left, there are 8 two-week sprints. The total number of story points for the release is 240 and the team’s velocity has been estimated at 40 story points.
The first sprint went to plan and the team reduced the number of story points by 40 leaving 200 story points remaining at the start of sprint 2. In the second sprint, the product owner added more work (30 story points) and added a further 20 story points worth of work in sprint 3. In sprint 5, the team had under-estimated some work and only managed 10 story points. And in sprint 6, the product owner removed 40 story points worth of work from the release. The remainder of the release progressed well, completing the release at the end of sprint 8.
For the average project, this type of burndown chart gives the right amount of information to the team, product owner and scrum master. There are however situations, especially when dealing with projects that will involve significant change, where there needs to be an alternative view because without the extra information that I told you in the previous paragraph there would be no way that you could extrapolate that type of detail out of the graph.
Mike Cohn defines an alternative burndown chart that presents the information in a clearer format. I use this format a lot as it can quickly be interpreted and highlight any issues during the release and identify any significant deviations within the release plan.
The standard Scrum release burndown chart tends to present a fairly one-dimensional view on how much work there is remaining. In the majority of cases, this view is sufficient to monitor the project but on the more complex project there may be situations where issues are being masked by too simplistic a graph.
Just looking at the original example above we cannot tell what events happened to deviate from the planned delivery. We expected the team to deliver at a velocity of 40 story points per sprint. In the second sprint however, they only delivered 10 story points and in sprint 3 they delivered 20 story points. Had the team under-estimated a task? Did the product owner introduce new work? To represent this level of detail more clearly, the burndown bar chart can be used.
In this form of burndown chart, progress is shown above the baseline and change in scope is presented below the baseline. On this burndown chart, the height of each bar represents the amount of work remaining in the release. Taking the previous example the new chart shows a release with 240 story points planned in it as of sprint 1. The team completed 40 points in sprint 1, leaving 200 to go as of the start of sprint 2. Before sprint 2 the product owner added 30 story points worth of work and before sprint 3 he added a further 20 story points worth of work. This additional work is shown at the bottom of the bar for both the second and third sprint. During these two sprints the team still delivered 40 points each sprint.
Sprint 5 shows a decrease in the teams velocity to 10, due to underestimating a task. Prior to the start of sprint 6, the product owner removed work. As with an increase in scope, a decrease in scope comes off the bottom of the bar. This applies even if the work removed was initially planned or added during the project.
The overall chart does give a far clearer picture of what has happened during the release and eliminates any conjecture but it is a more complex view and does need a bit of practice.
In this article I have covered the release burndown chart, the exact same format can be applied to the sprint burndown chart where the data is based upon the tasks and not the stories. It is just a matter of granularity, but the same approach can be used.
A word of warning, it is so very easy to get carried away with spreadsheets and data, and it can easily consume valuable time. If you do not learn anything from your data that can be applied to the next sprint or release then you have probably gone too far. Always check yourself, I am constantly reviewing what I do.
A Burndown Chart Can Do a Lot More Than Just Monitor Progress
Research & References of A Burndown Chart Can Do a Lot More Than Just Monitor Progress|A&C Accounting And Tax Services
Source