I want address a couple of common questions surrounding sprint burndown charts:
1) Is the burndown adjusted based on all tasks remaining in a sprint backlog or only those tasks that are in process?
2) During a sprint, if a bug is discovered on a user story being worked on, should we add additional tasks to the sprint backlog and should we adjust the burndown for those tasks?
These questions and many like them ARE EASILY ANSWERED if we remember the purpose of the sprint burndown chart. A sprint burndown chart shows only one thing: How much work remains.
To figure out how much work remains, we need to sum the estimates of all remaining tasks of the sprint. If we're using a task board, that means we'll sum estimates for tasks in the "In Process" column along with tasks still in a "To Do" column plus tasks with work remaining in any other columns a team is using. The sprint burndown represents the sum of the work remaining in a sprint. This also means that a change in the estimate for a task still in the To Do column will be reflected in the burndown value.
Why might a team change an estimate for a task that hasn't been started? (In other words, one that is still in the To Do column.) Perhaps the unstarted task is similar to a task that has been started. In starting the one task, a team member learns that it's going to take longer than expected. If the tasks are similar, it's likely the unstarted task will also take longer than expected and so its estimate might be increased.
If a bug is discovered during a sprint, the ideal situation is for whoever finds the bug to yell to me, "Mike, there's a bug in your code when I do such-and-such" and for me to fix it immediately. In that case we wouldn't see a new task in the sprint backlog and we wouldn't see the burndown chart go up. However, if I can't fix the bug immediately (perhaps because I'm deep into something else), the bug should be added as a new task in the sprint and an estimate quickly assigned to the task. When the burndown is next calculated this extra work should be included when work remaining is summed.
The answers to the questions at the start of this post and many others like them are easily addressed when we remember that the purpose of a sprint burndown chart is to show the total amount of work remaining.
