Get certified - Transform your world of work today


The Burn-Down Chart: An Effective Planning and Tracking Tool

7 August 2013

Nitin Mittal

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:
Sprint Duration – 2 weeks
Team Size - 7
Hours/Day – 6
Total Capacity – 420 hours
On Day 1 of the sprint, once the task breakdown is in place, the ideal burn-down will be plotted as below:
Figure 1
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:
Figure 2

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.
Figure 3

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.
Figure 4

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.
Figure 5

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.
Figure 6

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:
Figure 7
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.
Scope management: Tasks represent the overall scope of the sprint. Anything that is not part of the task list is out of scope for the sprint.
Schedule management: 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.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.9 (41 ratings)


Bhoodev Singh, CSP,CSM,CSPO, 8/7/2013 11:03:28 AM
Business and stakeholders prefer either a typical dashboard/bars BD over lines BD charts.
Zach Bonaker, CSP,CSM,CSPO, 8/7/2013 2:29:20 PM
Personally, I like burndown charts for sprints and burnup charts for releases. The burnup makes it easier to communicate changes in backlog points (e.g., the "a total points" line increases/decreases).
Bhoodev Singh, CSP,CSM,CSPO, 8/7/2013 4:06:39 PM
Release burndown charts are pretty useful too :-)
Kim Poo Gan, CSM, 11/29/2013 2:08:40 AM
Great article. concise and easy to understand.
Martin Le Brun, CSM, 3/5/2014 2:08:05 PM
I have found that estimating and tracking hours has not been accurate. I also don’t think it is in the spirit of agile practices.

While there is no single authority on scrum, from Jeff Sutherland at

"For new teams, breaking down the Sprint Backlog into tasks and estimating in hours is done but no longer recommended."

The team I work with is using the compromise of burning down tasks within a story, as our stories are not small enough yet to only burn down on their own. If you replace "hours" with "tasks" in the article, you can achieve this.
Hao Zhu, CSP,CSM, 7/18/2014 11:35:52 PM
For Scrum, it is recommended to do size based estimate instead of time based estimate, so burndown chart would be better used to track the status of stories instead of remaining hours.
Sylvain MAHE, CSP,CSM, 8/1/2014 2:05:09 AM
If the remaining hours are plotted at the beginning of the day(my preference, during the daily stand up), the X axis goes from day 1 to day 11 ! (not 10).

(because this is only at the beginning of the 11th day that there is no remaining work)
Rajesh Gawade, CSM, 11/15/2016 2:52:53 AM
'Working software is primary measure of progress' is the principle which team will violate if teams track progess in terms of efforts logged or efforts remaining
Sathish Kumar, CSM, 7/20/2017 5:37:00 AM
Very Useful Article Nitin, to know the importance of Brundown Charts. Thanks for writing us a detailed article.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up