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.