The Task Burn Down Trap: everything finished, nothing done

Serge Beaumont

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.

A Task Burndown Chart

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".

A Task Board with everything In Progress

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!

User Story Burndown - Flat line

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:

User Story Burn Down - Descending

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:

Task Board - With Toploading applied

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!

Comments (4)

  1. Erik Pragt - Reply

    September 19, 2008 at 1:44 pm

    Hi Serge,

    Interesting blog. However, 2 remarks:

    1: throw away the task burn down! It adds nothing, and only produces waste (we don't want that, do we?). This information is already available on the task board, so don't add it again.

    2: I think you focus a little bit to much on the current sprint, while not touching the NEXT sprint (sorry for the uppercase). I think that's worth a blog on it's own, but if you have an hour to spare, check out this movie: http://www.infoq.com/presentations/prioritizing-your-product-backlog-mike-cohn

  2. Serge Beaumont - Reply

    September 19, 2008 at 1:51 pm

    Erik,

    @1: What the task burn down adds is *trend* information, while a task board only gives you a snapshot of the current situation. So there's definitely something it adds.

    @2: You're absolutely right to note that working on the next Sprint is worth a blog post on its own. That's why it's not in this one. 🙂

  3. Erik Pragt - Reply

    September 19, 2008 at 1:56 pm

    @1: Well, if you make your User Stories small enough (which you should) you already have a trend. Why do you want to have two trends?

    @2: I know. Just giving you something to do for the weekend ;). (And a small reference could be made to the next iteration, unless you want to write a blog: 'everything finished, nothing to do next sprint' 😉

  4. [...] “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 Task Burn Down Trap: everything finished, nothing done [...]

Add a Comment