Burn Down Chart Tutorial: Simple Agile Task Tracking
Posted under: 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 |
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:
|
| 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
51 Comments + Add Comment
Got anything to say? Go ahead and leave a comment!
Popular Posts
- MVVM vs MVP vs MVC: The differences explained
- Burn Down Chart Tutorial: Simple Agile Task Tracking
- Algorithms and Data Structure Interview Preparation Guide
- Interview Questions for Software Developers
- .Net Interview Questions 4: Multithreading
- Explanation of the stack, the heap, and recursion leading to stack overflow
- .Net Interview Questions 7: WPF
- Solving Traveling Salesman with Ant Colony Optimization in JavaScript
- MVVM vs MVP vs MVC: The concise explanation
- .Net Interview Questions 3: Framework Core
- 3 Rules of SDK Design
- .Net Interview Questions 5: Management & Leadership
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
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.
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.
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
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.
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.
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.
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.
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
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
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
I have updated the docs and the first link at the bottom is now available for everyone again
When using the spreadsheet everytime I change the start or end date it causes all other fields to fail (?NAME in most fields)
Hi Jason,
I don’t have this problem. Can you give me some examples of the dates you are trying?
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
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.
Very good template. However, any reason why the dates are a day out? (Christmas 26th and Boxing day 27th)
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.
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.
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.
You are right. Thanks for catching that for me.
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
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.
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.
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
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.
Thanks Joel.
Another question was related to the units of estimation.
Is it hrs or days?
It is in days
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
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.
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!
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.
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?
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.
What would be the best way to incorporate scope changes into the graph?
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.
An amazing excel… simply superb.
Good effort Joel.
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!
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.
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
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.
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
Awesome, thanks!
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
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.
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.
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).
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
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).
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?
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.