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.