Burn Stories Not Tasks

by Chris Sims on Jan 12, 2009 |

Developers commonly break user stories into tasks to facilitate distributing the implementation work across the team, and allow tracking of progress at a finer level of granularity. Unfortunately, a story can explode into a list of non-trivial tasks so large that the story is not deliverable by the end of the iteration. Ron Jeffries suggests: Do stories as a unit, not broken into tasks.

In order for this to work, the stories need to be small enough that the team can understand and estimate them well. One approach to decomposing a story is to list the acceptance criteria, and then look at each of these and find the ones that can be stories themselves. If the particular acceptance criteria adds some value to the product, is user visible, stands alone, and is testable, then it is a good candidate to become its own story.

Many teams have specialists that focus in particular areas of the product or the underlying technologies, making it difficult to give a whole story to an individual engineer. A long-term solution is to cross-train developers such that they can work in the various parts of the system and with all of the needed technologies. This creates a team that is versatile and reduces the organizational risk of loosing 'the only person' who is competent to work in a given area of the system. One way to get the work done now, while moving in this direction, is to use pair programming. The person who 'owns' the implementation of the story pairs with the people who have the needed expertise, in order to deliver the whole story.

Ron recommends: "Burn stories, not tasks." When tracking (burning) at the task level, developers can 'do their part', finishing many tasks, without any user functionality being delivered. If the team only tracks story completion, then developers only get the warm glow of finishing something when a story is complete. This encourages a more valuable notion of 'done.'

Do you agree with Ron's approach? Leave a comment and share your views.

Related Editorial

Agile workshops and training

Five Key Practices to Agile ALM

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Agile Maturity Model Applied to Building and Releasing Software

Enterprise-class API Patterns for Cloud & Mobile

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

Agreed! by Dave Rooney Posted

Re: Agreed! by Marcin Niebudek Posted

Agree, but I think it's a false controversy by Charlie Martin Posted

Re: Agree, but I think it's a false controversy by Carl Phillips Posted

Re: Agree, but I think it's a false controversy by Charlie Martin Posted

Yeah, it is the right thing to practice by Rama G Posted

Burning down the house by Mike Bria Posted

Agreed! by Dave Rooney

I've experienced a team that decided to focus on tasks rather than stories, and it wasn't pretty. As mentioned in the article, what occurs is a lot of activity but very little real progress from the business perspective.

That said, tasks are good. They give everyone an idea of how much work is involved, and provide a sanity check for story estimates. I had a business analyst comment once that she was surprisedby how much work went into delivering software after she saw a task list created after Iteration Planning. However, using tasks as a measurement of progress doesn't work.

Dave Rooney
Mayford Technologies

Re: Agreed! by Marcin Niebudek

+1 from me... Tasks estimation and tracking progress using story tasks almost alway leads to tasks becoming pseudo user stories within large and overestimated real stories.

Besides how do you estimate tasks? When estimating stories we encourage developers to use points and to show only relative size of a story within other stories. You can do that because all stories are functionalities from a user point of view, so you can alway say this story might be 3 times harder to implement that the other one. I think it's much harder to do with specific, usually technical tasks - you start judging between activities of different type, for example implementing some component and designing user interface. I think estimating tasks quickly falls back into estimating in man-hours, people micromanagement (as resources) and tracking people instead of real progress.

Surprisingly when implementing our tool (tinyPM) we found the feature request "Tasks estimation" to become the most wanted one, while we want to encourage our users to rather split stories into smaller functional parts and use tasks for stories as some kind of to do list for developers. This way we always know what this story consists of, but still story is done only when all the tasks are done.

Marcin Niebudek
tinyPM Team

Agree, but I think it's a false controversy by Charlie Martin

The point is that you should measure delivery by function delivered and accepted. If you break a story into tasks, and the tasks have a measurable, testable deliverable, then it's okay to work by tasks. But then, those tasks aren't really distinguishable from stories, as Chris correctly notes. If you break a story into tasks that aren't measurable and testable, then don't measure them. Similarly, a story should have a measurable, testable chunk of business value that can be accepted by a customer. If it doesn't have one, it should be refactored somehow to do so.

Either way around, what you should measure is the acceptance of a piece of business function by the customer rep, whether stories, tasks, or fizbins.

Re: Agree, but I think it's a false controversy by Carl Phillips

We have noticed this behaviour in my team, but the reality is that we're often working on fairly complex (read badly designed) legacy systems where the 'cost' of implementing a story or two is so big that an entire sprint is taken up with only 1 or 2 stories. We need the visibility of progress that Scrum affords but unless we breakdown into tasks and cost associate these, we lose that in the burndown. We know it's not the ideal but cant see a way to have our cake and eat it?

Re: Agree, but I think it's a false controversy by Charlie Martin

I guess I have two thoughts.

First, if the problems are telling you that you can only do one or two stories per sprint, it might be you should believe them. There's nothing wrong with two stories per sprint, if the result is predictability and repeatability.

Second, if for some reason, whatever reason, that isn't acceptable, maybe you should change the duration of your sprints a bit. There's nothing magical about a 3 week or 1 month sprint: would you get better results if you did two week sprints and one story per sprint? Or six week sprints with four stories?

Yeah, it is the right thing to practice by Rama G

We have practiced the simlar appraoch. But we also added tasks. It make sense we don't need tasks when we have clear acceptence criteria.

Burning down the house by Mike Bria

(Not sure how I missed this earlier, but better late than never).

I totally agree that micro-tracking anything more granular than stories is missing the forest for the trees, and a ick recipe. I had posted about this here, check it out.

Cheers

MB