Burndown User Stories, Rather Than Tasks
by Kelly Waters
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?
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
Photo by ViaMoi
14 January 2009 13:36
Working for VersionOne, a tool that supports breaking down user stories into tasks, I often ride the fence on this issue.
My ideal situation is one where the team can plan their work, commit to the iteration, and show a reasonable burndown within the sprint... all without doing task breakdown.
As an Agile Project Manager, what I really care about is throughput iteration over iteration.
Task burndown can give me a great leading indicator within the iteration, but ultimately it is not necessary if the team is good at making and meeting commitments.
If a team is struggling to understand what is required to deliver the user story, needs more discussion about the nature of the work, have tasks that need to be completed my more than one individual - breaking user stories down into tasks (and subsequently burning down those tasks) can be helpful.
Either way, I tend to look at project velocity as a means for the organization to understand how the team is making progress. It is an external metric.
The iteration/task burndown should only be used by self-organizing teams to manage their commitments. It is for the team, so ultimately the team should decide.
My $0.02.
BTW - You seem to be posting more frequently, nice to have you back... keep it up!
14 January 2009 21:30
Thanks Mike, very interesting. This definitely seems to be a point that people have very different views on. I think I agree with your comments and that it's somewhat dependent on the maturity of the team.
Kelly.
15 January 2009 16:53
Maturity of the team is an important consideration. My team has been sprinting for 7 months and I don't think we're ready for no task burn down. Although this time next year I definitely believe they will. Good Article.
16 January 2009 09:45
There are 2 reasons why I believe the team should divide stories to subtasks during the planning:
- story points are an estimated measure of relative story sizes, this estimate tends to change during closer inspection,
- the process of dividing itself provokes lower-level discussion among team members, the tasks are better understood by the team and often this is the moment when most of the design is agreed upon.
From my experience, it is much easier to make the right commitment when the stories are divided. The iteration also seems to go smoother due to better understanding of all stories.
19 January 2009 18:11
I often wonder how to shorten IPMs. The teams I work with are often hungry to get started and start seeing how the stories play out in the iteration. I asked my current team and they suggested that talking about the tasks was useful. Further they suggested that the tasks estimates are not really useful because pairs reconsider the tasks when they begin a story. The consensus is then given small stories, a well gelled team, and pair rotation often this would be worth trying.
4 January 2010 17:28
A definition I find useful: Stories are what teams commit to. Tasks are what individuals commit to. The comment about team maturity is spot on. Immature teams tend to not understand all the work that is really required to complete a story. Tasking not only provides raw data for a task burndown which is useful for the team (story burndowns are not useful unless there are a lot of stories, sort of like tasks!) but helps the team learn what the work really is and to account for all of it. Teams notice tasking patterns for stories and can task quite quickly. If they can not then they do not understand the work or their architecture or both.