April 1, 2015

2256 Views

The Burn-Down Chart: Tracking Tool

Burn-Down charts are amongst the most common sprint tracking mechanisms used in Agile software development methodologies. This article looks at creating and updating a burn-down chart using the effort-remaining approach. It will also be interpreting burn-down under different scenarios, the advantages of using burn-down charts, and some mistakes to avoid when using them.

Burn-Down Chart

A burn-down chart is a graphical representation of work left to do, versus time; i.e. it is a visual representation of the amount of work that still needs to be completed before the end of a project. It displays the effort remaining for a given period of time and is useful for predicting when all of the work will be completed, and whether it will be completed on time.

How to create a Burn-Down Chart using a Spreadsheet

The first step is to break the task into smaller items that cannot be further broken down. This is generally done during the sprint planning meeting. Once the task is broken down, the ideal burn-down chart is plotted.

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 an Excel spreadsheet. The days in the sprint are plotted on the X axis, while the remaining efforts are plotted on the Y axis.

Refer to the example below:
          Sprint duration – 3 weeks

          Working days - 15 (2/2/1015 – 2/20/2015)
          Team size - 7
          Hours/Day – 6

          Total capacity - 630 hours

On Day 1 of the sprint, once the task is broken down, the ideal burn-down will be plotted as below.

The Y axis depicts the total hours which should be completed by the end of the sprint. The ideal progress is shown in the red line, which assumes that all tasks will be completed by the end of the sprint.

The burn-down chart should contain:

  • An X axis to display the number of working days
  • A Y axis to display the remaining effort
  • A trend line as a guideline
  • Real progress of effort

How to Update the Burn-Down Chart

Each member picks up the tasks and then works on them. At the end of the day, they update the effort remaining for the task, along with its latest status.
Refer to the example below. The total estimated effort for Task 1 is 10 hours. After spending six hours on the task, if the developer believes that it requires another 4 hours to complete, the Effort Remaining column (named as “Left”) should be updated as 4.

 

As we progress during the sprint, the burn-down will look like this:

Understanding Burn-Down Charts under different scenarios:

There are only two lines drawn in a burn-down chart, but the situation they describe might have different reasons. There are many different situations. Out of this, some common ones are described here:

Type 1: Sprint commitment met

A burn-down chart in which sprint commitments are met and progress has been smooth over the sprint.

Type 2: Sprint commitment not met

The teams are going at a slower pace and may not be able to complete all the commitments on time. The remaining work then becomes a part of the product backlog and is carried forward to subsequent sprints.

Type 3: Sprint commitment met too fast

It shows that we are going at a better rate and may be able to finish earlier. The stories were probably overestimated; therefore, the team finished them earlier.

Type 4: Team stretched for commitment

The team worked at a slow pace in the first few weeks of the sprint. However, this was observed by them and then pushed towards the end of the sprint, to meet the commitment. 

Type 5: Team is not consistent

The team's performance has not been consistent, even though the commitment is met in the end. 

Type 6: Team is not proactive

The team is probably doing some work, but maybe it does not update its progress accordingly. Another reason might be that the product owner has added the same amount of work that was already completed, therefore the line is straight.

Type 7: Team is non-functional

The team is non-functional on many levels and the product owner does not care about development progress.

Advantages of using Burn-Down Charts

Single planning and tracking tool for the team

The team performs task breakdown, updates the estimated effort, and also updates the effort remaining. The entire team drives planning and tracking using the burn-down tool, which is the biggest advantage of using it. 

Risk mitigation by daily visibility

The burn-down chart provides daily feedback on effort and schedule, thereby mitigating risks and raising alarms as soon as something goes wrong, rather than waiting till the end.

Communication tool for customer and other stakeholders

Burn-down charts provide visibility of a project’s progress on a daily basis. In the absence of an online tool, burn-down can be physically represented using a whiteboard/chart paper.

Placeholder to track retrospective action items

It is a good practice to include retrospective action items from the previous sprint as "functional requirements" in the task breakdown for the current sprint. This way, the team keeps a focus on those action items and they are tracked as the sprint progresses.

Common mistakes of using burn-down charts

  • If the task is too big, then it will make tracking on a daily basis difficult.
  • People get confused with the effort spent and the effort remaining. If these are wrongly plotted then the report insight will be inaccurate.
  • Forgetting to update the remaining time for tasks will lead to incorrect data.

Conclusion

The burn-down chart is an essential part of any Agile project. It is a good way for the team to clearly see what is happening and how progress is being made during each sprint. Finally, for updating the burn-down chart, discipline is needed. The chart should be updated at the end on a daily basis.

Reference