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
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.
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.
Table 1: Issues log
Notes on filling out the issues log:
Figure 3: Burn down spreadsheet template
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
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
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)
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
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.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.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:
|
| 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)
No comments :
Post a Comment