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