Friday, November 27, 2009

What unit to use in burndown?

What unit do you use for plotting your Burndown Chart? Do you use “Remaining Hours” of the tasks? Or perhaps “Story Points” of the stories in the sprint backlog? Or something else?

Up until recently I’ve taught Scrum teams to just sum up the number of remaining hours for all tasks on their Scrum Board, and plot that sum on the burndown chart. That has been my default approach and I haven’t really experimented with it.

Why even bother breaking down a Story into Tasks?
The immediate answer to this question is of course that we do it to be able to sum up estimated Remaining Time. Duh :-). But I think there’s more to it, because a Story is more than just the sum of its Tasks. The real reason, I believe, is to get the team thinking; to get the team to reflect over what challenges the Story hides so that they maintain an as clear picture as possible of where the implementing is heading and how the sprint is progressing. This implies that breakdown of a story shouldn’t be done just once (e.g. at sprint planning). The view of what tasks a story contains changes as the implementation progresses and things are discovered. It’s natural that the contents of the story vary over time. Nothing of what I have written here is controversial. It’s all part of Scrum.

What happens in practice?
Plotting a burndown based on the sum of Remaining Time obviously requires that the team first breaks down the Stories into Tasks. This, in my experience, has always been somewhat of a challenge; for the team to actually end up with useful tasks. A good breakdown of a scope into User Stories is hard enough, and then to also successfully break a Story down into good Tasks … Well, it is hard and it requires lots of practice. I’ve always struggled getting teams to continuously reflect over their breakdown and about how to improve it. But in the end, tasks often seem to end up saying more or less meaningless things like “Implementation”, “Testing” and “Review”. Fail.

Failure in Task breakdown like this effectively prohibits the team from having any use of it. A breakdown like this doesn’t say much about the Story and consequently there is little or no use in continuously reviewing the breakdown to try to learn more about the Story as implementation progresses. The only remaining purpose of the breakdown, then, is to force a daily re-estimation, so that numbers can be summed up and plotted on the chart. The burndown and the estimation of Remaining Time becomes an end in itself.

We started counting "Number of remaining tasks"
My team, being in the situation described above, felt that the daily task re-estimation was (more or less) meaningless, and proposed that they should try and completely skip the estimation all together. If nothing else, it would save them that estimation-time that was borderline waste anyway. But they also realized that the burndown has an important purpose (yesterday’s weather, indicating progress, early indication of problems, etc) so they felt that they still needed burndown. But if they don’t estimate Remaining Time, then what do they plot on the burndown chart? Well, they agreed to try to plot the number of remaining (not done) Tasks. Simple! And not completely new; it’s a fairly common practice, if I’m not mistaken.

Interesting consequences of this change
This change in the process had a very interesting side-effect: all of a sudden the Task breakdown produced a large number of highly meaningful tasks. Instead of just saying “Implementation” the tasks that the team now produce actually describe what needs to be done, in pretty deep detail. The number of tasks produced both at the sprint planning and on the Standups is significantly higher now than before, and they say a lot more about what needs to be done.
It just seem to come more naturally now. The only difference is that we no longer estimate the tasks afterwards. That’s it. I think this is very interesting. It’s like if there was a mental block before, that has now been removed once the team doesnt have to bother estimating the tasks. I don’t know, but whatever the reason, I think it's great. The team is satisfied with the change. I feel that the quality of the task breakdown of the Sprint backlog is much higher now, and consequently the understanding of the team’s progress is much better (both for themselves and for me as a stakeholder). The project is more transparent.

The drawback of this change might be that the burndown probably is a little less accurate, because the size of tasks vary a lot. On the other hand, how accurate was the burndowns before, when we were estimating remaining time almost as an end in itself? Hopefully the accuracy now is not much worse. And if it is, I think it is outweighed by the gain in insight and increased feeling of progress.

Let me know how you work with tasks, and why… As always I’m curious to get some feedback.

3 comments:

  1. Interesting post! I see a potential danger, though, in that without estimation the team member might not feel the same "pressure" to get the task done when there is little time left ... thus bringing the team back to a stage where the different tasks are just stuck for no one knows how long?
    IMO, one of the great benefits of the burndown is to show the future in shape of remaining time (it's also easier to calculate and plot into a sprint unless the team is proficient in estimating effort as story points and knows the time associated with this) and that advantage is removed here.
    But the again, I am relatively new to Scrum, only two months as Scrummaster under the belt, and I am always eager to learn more :-)

    ReplyDelete
  2. yes, i see the point, and that is also what I used to believe firmly; that estimating remaining time of tasks is good because it forces the team to think about what lay ahead and thereby adds some pressure and increases validity/accuracy of the burndown.

    So, there may indeed be a risk that skipping the time estimation alltogether introduces room for "lazyness" in the team's daily review of what is remaining. However, so far, the team's burndown has had the same use and result as before - with the added benefit of the tasks being more meaningful, and the daily's go a little faster). So, so far, I'm happy about the change. And if we deem it doesn't work, we'll change back (or to something else).

    The original point with my post was that this change had a surprising effect: the quality of the tasks is substantially higher now - and the only difference is that we no longer estimate remaining time. That is something I sure didnt expect when the team decided to stop estimating.

    ReplyDelete
  3. I agree with you that remaining Hours is not the best thing to track in a burn-down chart. The purpose with a sprint is not to consume hours but to develop running Stories for your customer. In this spirit, remaining Stories should be what we should track in a burn-down. However, this can be a little rough. A more fine-grained follow-up could be remaining Tasks. I have used remaining Tasks in my Sprint burn-downs, and it is a good indicator of the sprint progress.

    You just need to make sure that you complete the Stories during the sprint as well. You could end up in 90% of the Tasks completed at the end of the sprint, but 0% of the Stories are complete.

    ReplyDelete