Comments on: Burndown User Stories, Rather Than Tasks

By: jmckenna

jmckenna — Mon, 04 Jan 2010 17:28:18 +0000

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.

By: Anonymous

Anonymous — Mon, 19 Jan 2009 18:11:00 +0000

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.

By: Slawomir Ginter

Slawomir Ginter — Fri, 16 Jan 2009 09:45:00 +0000

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.

By: Derek Mahlitz

Derek Mahlitz — Thu, 15 Jan 2009 16:53:00 +0000

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.

By: Kelly Waters

Kelly Waters — Wed, 14 Jan 2009 21:30:00 +0000

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.

By: Mike Cottmeyer

Mike Cottmeyer — Wed, 14 Jan 2009 13:36:00 +0000

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!