Burn-downs charts are among the most common sprint tracking mechanisms used by Agile practitioners. Though their application and usage varies (some plot a burn-down chart using story points, whereas others use task count), plotting burn-down using effort remaining is the most effective and efficient way of using burn-down charts. This article looks at creating and updating a burn-down chart using the effort-remaining approach, interpreting burn-down under different scenarios, and examining common mistakes to avoid while using burn-downs. We conclude by looking at some of the benefits of using this innovative tool.
How to create a burn-down chart
The first step is to have a task breakdown in place. This is generally done during the sprint planning meeting. Each task should have associated hours (ideally not more than 12, roughly two days' work at six per day), which the team decides on during the planning meeting.
Once the task breakdown is in place, the ideal burn-down chart is plotted. The ideal reflects progress assuming that all tasks will be completed within the sprint at a uniform rate (refer to the red line in Figure 1 below).
Many Agile tools (Rally, RTC, Version One, Mingle, etc.) have built-in capability for burn-down charts. However, in its simplest form, a burn-down chart can be maintained in a spreadsheet. Dates in the sprint are plotted on the X axis, while remaining efforts are plotted on the Y axis.
Refer to the example below:
– 2 weeks
– 420 hours
On Day 1 of the sprint, once the task breakdown is in place, the ideal burn-down will be plotted as below:
The Y axis depicts total hours in the sprint (420 hours), which should be completed by the end of the sprint. Ideal progress is shown in the red line, which assumes all tasks will be completed by the end of sprint.
Updating the burn-down chart
Each member picks up tasks from the task breakdown and works on them. At the end of the day, they update effort remaining for the task, along with its status.
Refer to the example below; the total estimated effort for Task 1 is 10 hours. After spending an entire day (six hours) on the task, if the developer believes that it requires another six hours to complete, the "Effort Remaining" column should be updated as 6.
As we progress during the sprint, the burn-down will look like this:
Interpreting the burn-down chart
The blue line in the figure above shows the remaining effort on a daily basis. If the blue line is above the red line, it means we are going at a slower pace and may not be able to complete all the commitments. If the blue line is below the red line, it shows that we are going at a better rate and may be able to finish earlier.
Type 1: Sprint commitment met (smooth flow)
The figure below provides a burn-down chart in which sprint commitments are met and progress has been smooth over the sprint.
Type 2: Sprint commitment NOT met
In the burn-down chart below, sprint commitments were not met. Work of around 100 hours was not completed in the sprint. The remaining work then become part of the product backlog and was carried forward to subsequent sprints.
Type 3: Team stretched toward end to meet the commitment
In this burn-down chart, the team worked at a slow pace in the first few weeks of the sprint and pushed toward the end of the sprint to meet the commitment.
Type 4: Team is not consistent
In the figure below, though the commitment is met in the end, the team's performance has not been consistent. Probably it is a case of meeting weekly goals by stretching toward the end of every week.
Fallacies in using burn-down charts
Following are some common mistakes that can cause burn-down charts to be misleading:
Multiple stories have a common task.
There are instances when multiple stories may have a common task involved. In such scenarios, if we add this task under each story, it will provide a wrong impression of total hours, and tracking will be misleading. For example, consider "test data set-up." This could be a generic task and applicable for all stories.
A better way to handle this would be to add just one task that is common across stories. This ensures that efforts are not increased multifold. Another way could be to divide total effort for tasks by number of stories and add tasks under each story, specifying divided effort hours. However, in such cases, while updating the task, team members should remember to update it under all stories.
Tasks are too detailed or too big.
If there are too many tasks created, it becomes difficult to track them. At the same time, tasks should not be huge in size (ideally not more than 12 hours), or else daily tracking will be difficult. Generally, if tasks are more than 12 hours, it becomes difficult for team members to assess how much effort is remaining at the end of the day, and tracking may become subjective.
There is misunderstanding between effort remaining and effort spent.
One of the most common mistakes we commit is it to misunderstand "effort remaining" as "effort spent." Especially during first the few sprints or when a team is new, the team needs to be educated on this. While updating the effort column every day, the team should be reestimating the task again and update what effort is remaining to complete the task.
If the team updates "effort spent" rather than "effort remaining," burn-down will initially show downward trending, and as the sprint progresses, the blue line will cross the red line and show an upward trend. It will look something like this:
Discipline is needed to update daily.
It requires a disciplined effort from everyone to update "effort remaining." It should be done at the end of every day. This helps in coming up with a burn-down chart that reflects the correct picture daily.
Advantages of using burn-down charts
Single planning and tracking tool for the team
The team comes up with a tasks breakdown, the team updates estimated effort, and the team also updates effort remaining. This empowers
the team to own the plan. The entire team drives planning and tracking using the burn-down tool, which is the biggest advantage of using it.
Tasks represent the overall scope of the sprint. Anything that is not part of the task list is out of scope for the sprint.
The team plans what it has to accomplish in a sprint and updates the task list. As it updates daily effort details, the team knows whether it is on track to meet the commitment or not.
Risk mitigation by daily visibility
Schedule overrun and cost overrun are two important metrics that get tracked in traditional project management. Mostly they're tracked on a weekly basis. The burn-down chart, on the other hand, provides daily feedback on effort and schedule, thereby mitigating the risks and raising alarms as soon as something goes wrong. For example, if actual progress line (the blue line) goes flat and hovers high above ideal line (the red line), the team knows it is in trouble. Mitigations can be planned right then, rather than waiting till the end.
Communication tool for customer and other stakeholders
Burn-down charts are an effective communication tool for customer and stakeholders. This can be printed and placed in an Agile room or shared with relevant stakeholders every day. This provides visibility of project progress on a daily basis. In the absence of an online tool, burn-down can be physically represented using a whiteboard/chart paper and placed in the team area.
Placeholder to track retrospective action items
It's a good practice to include retrospective action items from the previous sprint as "nonfunctional requirements" in the task breakdown for the current sprint. This way, the team keeps a focus on those action items, and they are also tracked as the sprint progresses.
Burn-down can be plotted at the sprint level or the release level. While sprint burn-downs are generally tracked using effort remaining, it's a common practice to use story points to track release burn-down.
Since its inception, many variations of burn-down have appeared. (Few practitioners find it useful to create "burn-up" charts at sprint or release level.) The Cumulative Flow Diagram (CFD) is another popular tool that provides a greater level of detail and insight into various stages of a task or story.
However, recent studies show that burn-down charts remain the most popular tracking tool for Agile practitioners, due to their effectiveness and simplicity.