Burndown User Stories, Rather Than Tasks

Get insights in your inbox

I was very interested to read this blog post from Ron Jeffries about burning down user stories rather than tasks. Excuse the pun, but this is a hot topic for me at the moment 🙂

If it’s possible to avoid the time spent in Sprint Planning, breaking user stories into tasks and estimating them in hours, this would reduce the overhead of planning iterations in too much detail. This is something I am sure any development team would probably welcome.

Estimating only in points also allows a team to realise the full benefits of Velocity, which causes a team’s estimating to be self-correcting. Otherwise there’s a tendency for people to try to convert points into hours and reconcile them with the time available, which in itself can cause some problems (see here for examples).

Having said that, this would only really work if the user stories are small, e.g. 1 or 2 days. Otherwise, longer stories would tend to complete towards the end of the Sprint, meaning the burndown chart would not provide early feedback and visibility of progress throughout the Sprint. Personally I find the burndown chart an extremely valuable and powerful tool, so I think this is very important.

One of the comments on Ron’s post suggests that a team must be multi-skilled – all capable of working on everything – for this to really work. I don’t really believe that’s the case. If the user story is small, I don’t see that it would really need to be broken down for a team to collaborate and complete it. Say you have a designer, front-end developer, back-end developer and tester on the team. I’m sure they can figure out how to divide the work to complete the story based on their skills, without necessarily going through the process of breaking down every story in the Sprint Planning meeting.

I do, on the other hand, believe there is real value in the Sprint Planning meeting and completing much of this meeting as a team. But I think the most value is in the first part of Sprint Planning – understanding the user stories and clarifying requirements.

I’ve heard and read various different views on this. I’d love to hear your comments on it?