Burn Down Chart Tutorial: Simple Agile Task Tracking

Nov 13, 2010 by Joel

Posted under: Linked In, Software Development

Eventually I became frustrated with Gantt charts. Sure, they had served me reasonably well for a number of years but I had a few problems with them. First, I found them time consuming to maintain whenever changes to a task’s timeline occurred. Second, the charts require tasks to be put in some sort of order at the beginning of an iteration which often isn’t representative of when tasks will actually be preformed. Third, Gantt chart project management software included so many extra features that just creating and maintaining basic charts seemed to require some sort of certification. I longed for something simpler.

The solution for me was to use burn down charts. It is just a graph that shows how much time is left in a project vs how much work is left to be done (as shown below). This article provides an overview on how to effectively create and manage burn down charts using nothing but a spreadsheet.

Figure 1: Burn down chart

Contents

Terminology

If you have heard of burn down charts before, then likely it was in the context of agile software development. In this article, I will try to describe burn down charts in a manner such that they can be applied to a number of different types of projects, not just software projects.

One term to be familiar with is iteration. In a software project, an iteration refers to a set period of time where the various stages of the software development process are preformed to provide some sort of release. Iterations are preformed over and over, each time refining the product closer to a final release. However, in the context of this article, an iteration will just be a specific amount of time with an assigned set of tasks.

Reading Burn Down Charts

Burn down charts provide a method to track your progress on a daily basis. The axis on the left shows the remaining effort required to complete the iteration and the axis on the bottom contains the number of days until the iteration deadline. The remaining effort is determined by summing the time estimates for incomplete tasks.

In figure 1, the blue line shows the ideal scenario if your team performs exactly as predicted by your task estimates and the red line shows the actual performance. At day 0 (the first day of the iteration), the remaining effort is at its highest because nothing has been completed. At the end of the iteration (day 20), the sum should be 0 because there are no tasks left to be completed.

You want the red line (your team’s actual performance) to be close to the blue line. When it is above the blue line, then your team is behind schedule and when it is below the blue line, your team is ahead of schedule.

Figure 2: Chart showing areas above the blue line as being behind schedule and below the blue line as being ahead of schedule

If the actual remaining effort line is above the blue line for an extended period, then it means adjustments have to be made to the project. This could mean dropping a task, assigning additional resources, or working late, all of which can be unpleasant but because of the burn down chart, at least you can deal with it sooner rather than just before a deadline.

Not only are burn down charts intuitive to read, but they also require no adjustments when task scheduling changes which makes them easy to maintain as well. Priority and task start/end dates are never referenced when generating the graph so within an iteration, task priority and start/end dates can be changed without affecting the burn down chart at all. This significantly reduces the amount of time spent spent on adjustments when compared to other progress tracking methods.

Creating a Burn Down Chart

Step 1: Track Tasks

The first step in iteration tracking is creating an issues log to manage tasks. If you have a separate issues logging software, it is probably suitable for a lot of the details. The required information for burn down chart generation is just the task id and the time estimate.

Table 1: Issues log

Notes on filling out the issues log:

Adding tasks: For example, complete a requirement, or correct a bug, etc
Estimating task time: This should be for an average team member (not you), and should have team consensus when possible. I generally estimate at an accuracy of 0.25 days so that simple tasks do not get excluded.

Important: If tasks are longer than a few days, break them into sub tasks. As you will learn later in this article, partially completed tasks do not result in any updates to the burn down chart so performance resolution is proportional to task length.
Prioritizing: Prioritize each task in groups of 10. The highest priority is 10, 20 is lower, 30 is lower still, etc. Incrementing by 10 seems like an odd choice at first but it is likely that some tasks have been missed or need to be split so having a second digit available is handy for task insertions.

Step 2: Track Iterations

Using the issues log, it is now possible to generate a burn down chart based on the template shown below. After the template is created, only the green cells need to be adjusted for new iterations.

Figure 3: Burn down spreadsheet template

2.1 Iteration Setup

The goal of this section is to determine how many tasks you can fit into an iteration, and find equations for the number of man days used each day and the ideal remaining effort line.

Table 2: Iteration setup

Start Date	The date when work on the iteration starts
End Date	The planned date for when the iteration should end
# of Developers	Note that if one developer is shared between 2 projects, you might want to include him/her as a fraction, for example 0.5 developers
Efficiency Factor	This is a measure of your team productivity and task estimate accuracy. Use 0.7 as a starting point but after the first iteration, you will be able to obtain an updated value from the spreadsheet. It is calculated based on the following formula. (# of task days complete)/(# of man days used) Based on past performance, the efficiency factor adjusts the effective number of days available to work on a project so that your estimates become more in line with reality. This eliminates problems with consistent under estimates or over estimates. It is possible to have an efficiency factor greater than 1. This means that your time predictions are greater than how long it actually takes to perform a task. This does not require any special consideration.
Work Days	The number of work days between Start Date and End Date – For software development, 20 is a good starting point which is one month (5 working days a week for 4 weeks).
Man Days	This is the total number of man days available during the iteration (Work Days) * (# of developers)
Effective Man Days	The amount of time that is available for actually working on tasks. Efficiency Factor*(Man Days)
m – Ideal Remaining Effort	Slope for an ideal iteration(see burn down chart) -(# of task work days)/(Work Days)
b - Ideal Remaining Effort	Intercept for an ideal iteration – This should equal “Effective Man Days”
m - Man Days Used	Slope for calculating the number of Man Days used per day – This will be used later for updating the efficiency factor after an iteration
b - Man Days Used	Always 0

2.2 Tasks in the Iteration

Table 3: Assigning tasks to an iteration

In the last step, we discovered how many days we have available to work on tasks during an iteration (Effective Man Days). Next, tasks need to be assigned to the iteration. Simply add the Id’s for high priority tasks to the Assigned Task Id column until the total time required to complete the iteration matches “Effective Man Days”. If there is some time at the end but the higher priority tasks are too long to fill it, select a shorter lower priority task. Do not try to squeeze an extra day into an iteration.

For the example project, there is an extra task added to the bottom in yellow to cover various tasks associated with closing an iteration. This task can be added to the issues log instead if that is more appropriate for your team.

2.3 Burn Down Chart

The final step is to create the a table for generating the burn down chart as shown below.

Work Date	The date that corresponds to a particular work day.
Work Days (x-axis)	Each day that can be worked – It should start at 0 all the way up to Work Days from 2.1.
Ideal Remaining Effort (y-axis, ideal)	The ideal amount of task time that should be remaining for a given work day.
Actual Remaining Effort(y-axis, reality)	Your team’s actual performance based on the sum of all the incomplete task estimates (Work Days) – (Total Tasks Completed)
Completed Tasks – John	The next set of columns are for each individual to track how much actual effort they have produced. When a task is completed from the issues log, the developer simply puts the estimate in this column. Some notes: Record the task estimate time, not the actual time worked Only record completed tasks. Tasks that are 99% done are still not complete and do not get entered into this table.
Completed Tasks – Sue
Completed Tasks – …

Graphing the Ideal Tasks Remaining column and the Actual Tasks Remaining column against the Work Day column generates a burn down chart as shown below.

Figure 4: Final burn down chart

Tools

Desktop Spreadsheet Software (Excel) – Excel works fine but unless it is hosted somewhere for every developer to edit, the project manager will be required to update all the completed tasks.

Google Docs Spreadsheet – A hosted solution such as a Google Docs spreadsheet (free) is generally the best choice. Google Docs does formulas and charts like excel and it also allows team members to update their own progress. This is good because

Team members can see how they measure up compared to others in terms of productivity. Some people might see this as a disadvantage but I think it helps motivate.
Team members get used to updating the task log with new tasks so the project manager doesn’t have to always maintain it.
All members can see the current iteration status at any time.

Important Summary Points

Start with 0.7 as the Efficiency Factor.
One month is a good iteration timeline for many projects (20 work days).
Only record progress against completed tasks. If a task is 99% done, it is still not complete and cannot be used for a release.
If actual performance is significantly above the ideal iteration line in the burn down chart, investigate and correct the issue by dropping tasks, assigning additional resources, or working overtime.
Avoid task estimates that are longer than a few days. Break long tasks into shorter ones.
Measure priority in tens, as in, 10, 20, 30…
Use hosted solutions like Google Docs for tracking the project.
Never try to squeeze an extra day into an iteration
Use fractions for determining the number of developers if time is split across projects.
Burn down charts eliminate some overhead associated with other methods such as Gantt charts but are obvious not suitable if that extra overhead is required based on other project constraints

Template Download Links

Google Docs Template – Make Copy (IMPORTANT: Do not edit this document! Please just make a copy)
Google Docs Template Master (Original template, not available for copying)
Download Excel Template

Tags: agile, development, management, project management

51 Comments + Add Comment

Enrico December 18, 2010 at 9:25 pm

Hi Joel, found your Agile PM spreadsheet through google. Great job. any idea how I can make it work on google docs. I downloaded the excel, uploaded it to Google docs & then I created a copy for google docs. Now, when I open the spreadsheet in google docs => the graph is missing. Within excel everything is working fine. Any idea?

Thanks a lot,
Enrico

Reply
- Joel January 1, 2011 at 8:49 am
  
  Hi Enrico. At the bottom of the article there is a link to view the spreadsheet in google docs. Go to that link and the click the down arrow on the “Issues Log” tab. Select “Copy to…” to copy it to a different workbook. Once there, rename it from “Copy of Issues Log” to “Issues Log”. Do the same thing for the “Iteration 1″ tab. You may need to fix some of the formulas as the “Iteration 1″ sheet refers to the “Issues Log” sheet but it might be ok.
  
  Reply
Bill April 26, 2011 at 5:40 pm

I really like the concept of burndown charts, but it was getting a little tricky to chart. Your template and tutorial are a great help.

Reply
Andy July 13, 2011 at 12:56 pm

Newbee Question.. How do you add more users into the iteration tab? I have a team of Designers, Content Writers, Developers and QAs with multiple people within each group.

thanks.
AD

Reply
- Andy July 13, 2011 at 1:14 pm
  
  Ok I figured it out. But now i’d like to host it on Google Docs but when I clicked on the link it said that the owner had to approve the sharing of the document. I guess that’s you.
  
  Reply
- Joel July 14, 2011 at 1:54 am
  
  Hi Andy,
  
  I had an issue with the google docs security settings. I believe it should work now. Please let me know if you still have issues.
  
  Reply
Wee August 1, 2011 at 5:05 am

Hi Joel,
I am unable to copy the spreadsheet to another spreadsheet. It seems to be locked? how do i go about doing it.

Thank you.

Reply
- Joel August 1, 2011 at 1:25 pm
  
  Thanks for the message. I have updated the document so that anyone can make copies. However, you must have a google docs account and be logged in.
  
  Reply
Mike August 4, 2011 at 6:38 pm

Joel,
Great chart!.. have a few questions:
1. if i change status nomenclature, will that effect anything? ie(instead of ‘complete’ use ‘finished’ etc..

2. I added a total of 27 issues in issue log and some dont seem to copy to the iteration sheet, just showing blanks

3. if my sprints are 10 days long.. should i do anything with the extra days showing under work dates on the iteration sheet?

thanks

Reply
- Joel August 5, 2011 at 2:32 pm
  
  Hey Mike,
  
  Thanks.
  
  1. You should be able to change complete to finished without any problems
  
  2. Right. The issues don’t copy to the iteration sheet until you assign them. The ones that have already copied are problem the default ones that were assigned from the demo. To assign tasks to an iteration, you add the Id’s to the green box where it says task id on the Iteration 1 tab. There are only 21 spots so if you want to add more than 21 tasks in an iteration, you have to expand the hidden columns (EFGH), insert new rows starting at row 35, and then drag the formulas from row 34 down to the end of your new rows.
  
  3. You can just leave them or even delete them. Once you clear the demo data (in the green cells), those other cells that never get filled will not convey any information. To make it pretty, you may have to do some modifications (delete some rows, etc) to fit your needs.
  
  Cheers
  
  Reply
Bert Fajardo September 25, 2011 at 4:58 pm

Hi,
Great article explaining how to use a Burn Down Chart!

I am a new to Agile and am very interested in leveraging your google docs template for the Burn Down Chart (a link to was on your Burn Down Chart Tutorial) but it looks like I need to be granted access.

Would kind enough to provide me with access to it?

Greatly appreciated,

Bert Fajardo

Reply
- Joel September 26, 2011 at 1:50 am
  
  I have updated the docs and the first link at the bottom is now available for everyone again
  
  Reply
Jason November 8, 2011 at 2:59 pm

When using the spreadsheet everytime I change the start or end date it causes all other fields to fail (?NAME in most fields)

Reply
- Joel November 10, 2011 at 8:40 am
  
  Hi Jason,
  
  I don’t have this problem. Can you give me some examples of the dates you are trying?
  
  Reply
  - Jason November 10, 2011 at 9:02 am
    
    If you open in 2003, select the end date and press enter on the field (you don’t even need to change the date)
    
    It would appear the NETWORKDAYS function does not work, so ‘scuppers’ everything reliant field
    
    Reply
    - Joel November 10, 2011 at 11:41 am
      
      Are you using the excel or google docs sheet?
      Can you give me the cell location (row/col) and the exact text that you are putting in and I will take a look again.
      
      With the google docs sheet, I am unable to recreate the issue.
      
      Reply
Jason November 9, 2011 at 4:06 pm

Very good template. However, any reason why the dates are a day out? (Christmas 26th and Boxing day 27th)

Reply
- Joel November 10, 2011 at 8:43 am
  
  It is because those days are supposed to be holidays from work and in 2010, those days fell on a weekend. I made a mistake when doing this tutorial and put Christmas on the 26th but in 2010, the holiday for Christmas was on the 27th (and boxing day the 28th). I have just updated it to the correct dates. Thanks for pointing it out.
  
  Reply
Bert November 15, 2011 at 10:00 pm

Thanks Joel for posting this. This is terrific and just what I needed for a project I have been working on for some time. Unfortunately, I haven’t done as well as I would like in communicating effort, tasks and issues with my client. I am new to Agile and from what you have shown here it seems that I can take one step at a time. I really appreciate that you made this publicly available.

Reply
John November 23, 2011 at 5:40 pm

Hi Joel,

Thank you for publishing this. I’m a newbie to the burn down chart and have a lot of work to do just to get the underlying data so this is very helpful.

I noticed in section 2.1, Iteration Setup, your description for m – ideal tasks days left says it is -(# of task work days) / (Dev Days Total). Per your template and the example, I think it should be -(# of task work days) / (Work Days Total) .

Thanks.

Reply
- Joel December 14, 2011 at 8:34 pm
  
  You are right. Thanks for catching that for me.
  
  Reply
Hamdan December 4, 2011 at 11:01 am

Hi Joel,

Thanks for this great effort.
The problem I face is that work days at my country are Saturday to Wedenday and we have Thu and Fri as a weekend. So, “Work date” is not calculated properly. Is there any way to modify WORKDAY function to consider THU and FRI as a weekend?

Thanks and Regards

Reply
- Joel December 4, 2011 at 11:15 am
  
  Off the top of my head I don’t know the answer to this although I’m sure there is a simple solution. If it was me, I would just manually calculate the work days in an iteration since you only have to do it once at the beginning of an iteration. Just look at a calendar and count up the work days.
  
  Reply
Octav January 10, 2012 at 7:44 pm

Thanks for the post, excellent explanations.

As a matter of fact people from http://www.burndown-charts.com are referring your post.

They made an online solution to burndown charts.

It’s more group oriented though. It’ll work for solo projects, but Excel sheets are still really efficient for personal projects. We haven’t used it for long but so far so good.

There are a couple of things that we where looking for to save time:

- sharing the urls of the chart without having to create an account
- an easy way to sync and update

Oh, and we can continue using our physical board mixed with
post-its and cards that we all love soooo much ;)

This Excel sheet definitely helped us understand our needs though.

Reply
procyborg February 22, 2012 at 5:08 am

hi joel,
thanks for sharing this great effort.
it is undoubtedly a simplistic burn down approach.

i had a question for section 2.3.
developers would need to edit the green cell and enter the task-estimate-time (from the issues-log) – correct ?

does the developer have to enter it on the day that was completed ? rather does it have to be entered on the cell with the date of completion ?
could you please elaborate this bit please.

thanks

Reply
- Joel February 23, 2012 at 3:01 pm
  
  That is correct. Developers would need to edit the green cell and enter the task-estimate-time.
  Developers can enter it any day after it is completed. However, the graph will not represent the current status until everyone has their completed tasks entered. It is ok to let it slide for a day or two but I wouldn’t leave it too long if the graph started showing the team was behind schedule.
  
  Reply
  - Procyborg February 29, 2012 at 5:12 am
    
    Thanks Joel.
    
    Another question was related to the units of estimation.
    Is it hrs or days?
    
    Reply
    - Joel February 29, 2012 at 7:11 pm
      
      It is in days
      
      Reply
Mohan March 15, 2012 at 12:41 pm

Hi,
I am newbee to SCRUM and it is a great article to start with. I have one question about your comment “Team members can see how they measure up compared to others in terms of productivity.” Lets say every team member is entering the task estimate time once he/she completes the task under date on which he/she completed the task. how it helps to compare the productivity?

thanks

Reply
- Joel March 16, 2012 at 7:06 pm
  
  Each team member has a separate column for tracking the tasks they complete. This means all members see each other’s completed tasks. If a team member continually completes significantly less than other members, than he/she might be a little more motivated. Of course, if someone gets stuck with a bad estimate, then they may not complete as much as their peers but over the course of a project, this type of thing averages out. Ideally, you can expect your senior developers to produce more than the junior ones on these charts.
  
  The counterpoint is that seeing everyone else’s progress could be a demotivator as well since a team member’s value is more than just the number of tasks he/she completes. It is really is about what works for your team.
  
  Reply
Bradley April 11, 2012 at 8:49 pm

Hi Joel –

This chart is already a big help to me as a newbie. Great gateway into thing about agile & scrum. Thank you!

I understand all the formulas, etc. However I’m stumped on some labels.
What do the ‘m’ and ‘b’ stand for in “Ideal remaining effort” and “Man day used”? Thanks for sharing!

Reply
- Joel April 16, 2012 at 9:01 pm
  
  m and b are from the equation y = mx + b. It is used to determine the slope (m) and the intercept (b) of a line as in the case of the ideal remaining effort line. Man days used are the number of man days in a project that have been consumed. For example, if you have a project that is 5 days long and has 2 people working on it, then you have in total 10 man days for the duration of the project (2 people * 5 days). At the end of day 1, you have used up 2 man days (1 day * 2 people). At the end of day 2,you have used up 4 man days (2 days * 2 people) and so on.
  
  Reply
Nash May 6, 2012 at 7:19 am

Hey Joel!

Thanks for a great breakdown into the whole process. I have a question about heterogeneous teams where there are people with different skills and the effort required by each is different. So, for example, Jon could be a programmer and Sue could be a graphics designer. There might be more work required for Jon and Sue, how do you incorporate this into the estimate?

Reply
- Joel May 18, 2012 at 2:22 am
  
  If it was me, I would just two separate burn down charts (one for graphics work, and one for developers), and then just combine them in a 3rd sheet. The way to combine them would be to just add the ideal lines together and also add the tasks completed together (just sum the two graphs). The good thing about this is that it supports the teams scaling since each sub-team can manage their own burn down chart.
  
  Reply
Nash May 16, 2012 at 6:49 am

What would be the best way to incorporate scope changes into the graph?

Reply
- Joel May 18, 2012 at 2:19 am
  
  Hi,
  
  The thing about doing agile development is that you almost never have scope changes within an iteration. An iteration is a small unit of time and the tasks assigned to the iteration should be stable. The burn down chart is only relevant to the current iteration. It is very rare to have a change in scope and if this is something that is occurring frequently, it likely means that either your iterations are too long, or that tasks are being assigned to iterations are too poorly understood.
  
  Ok, so that being said, real world yadda yadda, etc, how do you handle scope changes? The best option is to punt tasks that are changing scope to the next iteration. Between now and that iteration, gain understanding required so that scope can be nailed down for an iteration. If punting is not an option, you can increase the task time estimate (I assume scope is increasing), and punt other tasks that have not been started. I would not recommend increasing the timeline of your iteration because it means that developers are starting to promise more than can be delivered. It is up to stake holders to approve scope changes and then deal with the consequences of those changes.
  
  Reply
Vinod June 6, 2012 at 8:44 am

An amazing excel… simply superb.

Good effort Joel.

Reply
Andrew September 12, 2012 at 6:36 pm

Hi Joel!

Thank you so much for this article and tool for project managment! This is really useful!

BTW, how do you handle (or enter) vacation or sick day here?

Thanks in advance!

Reply
Alfred Nutile January 15, 2013 at 3:28 am

Thanks for all your work on this and for sharing it. Great stuff. I am amazed how simple it can become if you focus on just these points. I track other things too but for real day to day status it is perfect.

Reply
Peter February 5, 2013 at 11:48 am

Hi Joel,

Firstly, thanks for your job, quite useful thing.

I’d like to ask you one thing: How to add/drop tasks in the middle of iteration? When I just add/remove task from task list the whole “Actual…” line jumps up/down. Shouldn’t it jump up/down the day I add/drop some tasks? Did you think about this scenario?

Thanks for your answer,
Peter

Reply
- Joel September 2, 2013 at 6:23 pm
  
  Supposedly, you are not supposed to add tasks in the middle of a sprint. In reality, it does happen on occasion and probably requires some spreadsheet manipulation which I haven’t thought about.
  
  Reply
Martin Lüdicke February 25, 2013 at 10:43 am

Hi Joel,

found this article while I was searching for infos on burndown charts. I like both the hands-on character of your post and the general info/tipps part of it. Thank you for posting it!

I shared it on Google+, didn’t find you over there, but if you’re interested: you can find it at this community: https://plus.google.com/communities/102037532338236982843

Martin

Reply
- Joel September 2, 2013 at 6:21 pm
  
  Awesome, thanks!
  
  Reply
sp_key April 4, 2013 at 4:17 pm

Can someone explain me why we need the following data?
It is still unclear to me.

# of Task Work Days
m – Ideal Task Days Left
b – Ideal Task Days Left
m – Dev Days Used

Thanks

Reply
- Joel September 2, 2013 at 6:01 pm
  
  There is a straight line drawn on the burn down chart that shows how a team would progress in an ideal world. The m and b are just parameters that define that line (y = mx + b)
  
  In the latest version, Ideal Task Days left has been renamed to Ideal Remaining Effort. For the Dev Days, it is used in an efficiency calculation. I think you would have to look at the spreadsheet to get the details.
  
  Reply
Sean May 16, 2013 at 11:03 pm

Hey Joel,

I’m confused by the “Completed Tasks – John” column described in section 2.3.
For a single row in that column, the value may be 4.5 for example.

- What exactly does that mean?
- Does it mean at the end of that work day John completed 4.5 days worth of work?
- Did John enter 4.5 by adding up the time he estimated for the tasks he completed that day?

I’m confused how this influences the burndown chart. I thought the graph would be influenced by entering how much effort remains after day x.

Reply
- Joel September 2, 2013 at 6:05 pm
  
  Hi,
  
  It means that John was working on a story (or stories) that were pointed at 4.5 developer days of effort. When the value was entered in John’s column, it means the task was completed (done done). He did not complete 4.5 days of work in one day. It is just that nothing is counted unless it is complete done. It looks like he completed several stories on the same day (perhaps he was blocked on some dependency earlier).
  
  Reply
Ben June 10, 2013 at 10:25 am

Hey,

just being curious : In the google Doc you created, how do you handle each sprint ?

you create a new sheet for every sprint ?

Thanks for this document by the way, it is a great basis for every project I manage.

Ben

Reply
- Joel September 2, 2013 at 5:53 pm
  
  I’ve used jira at work for some time now and can’t recall how I handled individual sprints with the spreadsheet. I likely created a sheet for each sprint (or found some other way to separate them).
  
  Reply
trapti September 24, 2013 at 3:36 am

One thing which is not clear to me from the article, is
Effective man days=28
Work days=20
No of person=2
Total man days=40
Ideally given work should be completed in 28 days then why we are monitoring this work completion cycle for 40 Man days?

Reply
- Joel January 26, 2014 at 10:12 pm
  
  This is because it is generally not possible to make accurate time predictions. Requirements may be fuzzy, or we may have interruptions (like administrative tasks), or people may miss work, etc. Our efficiency factor actually accounts for this based on previous data. So in this case, given 40 man days of work, based on the way the team has been making predictions so far, 12 of these days will be burned by things other than sprint tasks.
  
  Reply