The Task Burn Down Trap: everything finished, nothing done

In the past three projects I’ve been involved in (one as team member, two as agile coach) I’ve seen that the usual Sprint burn down based on tasks leads to a dangerous trap: you might end up with nothing done. In two cases we had nearly zero velocity for a Sprint, while the tasks were 90% done… Luckily there’s a fix: burn down user stories, and toploading.

Work != Results
The first problem with a burn down based on tasks is that it is based on activities, not end results. The underlying assumption is that when you’ve done all the activities, the end result will have been achieved. This assumption is wrong.
Let’s look at a burn-down chart. Looks pretty close to the ideal line, doesn’t it? If you would base your progress report on this, you’d be telling your environment that everything is going well.

Now let’s look at the task board. Do you notice how a lot is done, but nothing is finished? All stories have work in progress or still to do, but none of the stories has every task done. Note that even having everything done is no guarantee: all the work might still not have lead to a real “Done”.

If this is your task board at the end of a sprint, you have some serious explaining to do. So how do we prevent falling into this trap?
The Fix
Inspect: User Story Burndown
First we need to add a burn down line that shows the progress of results. Since user stories describe an end result, they are the logical choice. If we would have tracked the progress of user story completion, the graph for the above situation would have been completely flat. Having this line on the board would have alerted the team of the trap: nothing was really getting done!

The root cause of this problem is that there is too much work in progress at one time.
Adapt: Toploading
Jeff Sutherland once told me that one of the characteristics of hyperproductive teams is that they prioritize their work within the Sprint to achieve better speed. This inspired me to introduce something I’ve dubbed Toploading. Toploading can be defined as follows:
Given an ordered list of user stories, you’re either working on the top item, or else you’d better have a good reason not to. You don’t proceed with another story until your current story is done.
The ideal case is that the whole team is tackling the top item (it’s not called Scrum for nothing 🙂 ), but of course in many cases that’s not practical. So there are some valid reasons not to be working on the top item:

• The top item is maximally loaded: adding any more people does not help or will even hurt progress
• Your expertise and knowledge are totally useless for that story. Note that you could still could participate so you can learn, or that your help is needed a bit later on.

If you can’t work on the top item, you should be working on the next highest item, and all the same rules apply.
Even with the valid reasons not to be at the top, for each and every team member there is one rule that is absolute:
Each team member should be working as high up on the list as they can.
With Toploading and the User Story Burn Down in place you have some good tools to avoid the Task Burn Down Trap!
Inspect again
If you use Toploading, you should see your User Story Burn Down do the following:

The User Story Burn Down shows a different trend to a Task Burn Down in two ways:

• User Stories are by definition coarser than Tasks, so the line will be “blockier” than you’ll see with the more fine-grained Tasks.
• A User Story Burn Down tends to be flatter in the beginning. Again this has everything to do with the coarser granularity. Although it’s good to go for fine-grained User Stories, don’t get hung up on precisely following the ideal line.

A Task Board with a team doing Toploading also has a characteristic flow to it. You could imagine a snow plower coming in from the top and moving the tasks from left to right as it comes down:

This is another way to see if you’re really being effective, instead of just moving any old task across.
So should I throw away the Task Burn Down?
No! Don’t throw away the Task Burn Down! You should be using both. The Task Burn Down gives you information that the User Story Burn Down does not. A flattening of the Task Burn Down can show that lots of team capacity is gone because everybody is off fixing production bugs all the time, or because somebody is ill. It’s the combination of the two Burn Down Charts that gives you the most information.
Conclusion
The User Story Burn Down and Toploading should help you achieve maximum effectivity and to avoid the Task Burn Down Trap. May your Sprints be Hyperproductive!