Burndowns are a key tool for requirements projects; they give everyone an estimate of how much work is left and how long it will take to complete the project. However people will commonly make mistakes in their usage of burndowns and this can lead to all sorts of issues. Here are a couple of the most common burndown fallacies:
How much work have I done?
A burndown cannot be used to track how much work you have completed. People will often say “But I spent 48 hours working last week! What do you mean you can’t tell me how much work I’ve done?!?” The problem with this logic is the burndown is solely focused on the amount of work that is remaining. As you are well aware, it’s rare to be on a project where the task list at the beginning is the same as the task list at the end. If you’ve got 300 hours remaining at the start of the week and someone asks you to complete another task that will take 100 hours on Friday, next week’s burndown is going to show 360 hours remaining (assuming a 40 hour work week.) Taking our original example’s viewpoint, it would appear that we did negative work since we’re projecting an additional 60 hours of work between the 2 weeks!
How long will a task take?
It’s easy to fall into the trap of seeing the estimated hours to completion and thinking that’s how long it will take to complete a task, especially if it is something you have not started. What one has to realize is there is no data in the burndown that is capturing time spent on a task. For example: Sally begins working on a task that has been estimated to take 10 hours on Monday morning. Monday evening Sally records 2 hours left to completion for this task. She doesn’t work on this task until Thursday when she realizes there is a significant volume remaining and the remaining estimate changes to 8 hours that night. She spends all day Friday working on this task and enters a value of 0 hours before she leaves for the weekend. Sally’s manager, John, reviews the data Monday morning and wants to see how long she spent on this task. He takes 10 original hours and subtracts 0 remaining and arrives at 10 hours. This is clearly incorrect as Sally has only entered the amount of time remaining, not her time spent. John would need to speak with Sally to discover the amount of time she’s spent on this task as she could have easily spent 24 hours on this task during those 3 days!
It’s important to realize that burndowns are a forward looking tool that helps plan a project and resourcing. At the same time it’s important to avoid the pitfalls of using a burndown to count the numbers previously spent even though it seems like that information is tracked. With a little practice, you too can avoid these common misuses of burndowns in requirements gathering.
