Home Blogs User Stories Is this a task or a story?

Login Form



Is this a task or a story? PDF Print E-mail
Written by Dan LeFebvre   
Thursday, 29 July 2010 21:44

Recently at a client, there was a lot of confusion about what is a task versus what is a user story. Their product backlog was full of product backlog items that represented tasks in the development process as opposed to stories which represent value from a customer's perspective. I asked them why their backlog was structured the way it was. They said the original story from the Product Owner was too big to fit in the Sprint so during product backlog grooming they had split the user story into smaller items so they would be able to fit in the Sprint. They also said that they wanted to hand user stories to the test team member earlier in the Sprint so that he was not overloaded at the end of the Sprint.

 

They had the right idea but the wrong implementation. The product backlog is for the Product Owner to describe the vision of what is being built from the customer's perspective. Product backlog items are requirements, features, and descriptions of need. User stories are an ideal way to describe these features because they focus on who, what, and why for the features. Tasks, on the other hand, are descriptions of the activities needed to turn product backlog items into working software. Tasks are documented in the sprint backlog, which is owned by the team. By allowing tasks into the product backlog, the team is inviting the Product Owner to describe how needs should be met, instead of just describing what the needs are. This limits the opportunity for innovation by the team and reduces the team's understanding of the customers’ need.

The team was also confused about how teams operate within the Sprint. User stories are meant to be implemented by multiple members of the team; including developers, testers, technical writers, and anyone else who's needed to implement them. The Sprint planning meeting is when the team spends time strategizing how to best implement the user stories into functioning software. This includes discussions on design approaches, components of the system that may need to be touched, how those components could be effectively tested, how the user interface should look, capturing the tasks, and how these tasks can be coordinated so that the user story comes together as quickly and efficiently as possible.

So how do you split up user stories into smaller chunks? First you focus on the main functionality, leaving out the bells and whistles. Then each bell and whistle becomes a separate user story. Some teams have also found it useful to split user stories along the lines of the acceptance criteria so that the first user story passes the first couple of acceptance criteria for the marketable user story, the next one would pass the next few acceptance criteria, and so on. In either case, user stories are split up so that each new user story still delivers value from the user's perspective. These smaller user stories may not individually be marketable, but they are intended to be implemented completely, with high-quality, and when combined with the other stories, produce the marketable value that the Product Owner intends.

So keep tasks where they belong, in the Sprint backlog.

Last Updated on Saturday, 03 March 2012 15:28
 

Add comment


Security code
Refresh

Copyright © 2017 DCL Agility, LLC. All Rights Reserved.
 
Schedule a meeting