As is defined by Mike Cohn Scrum encourages teams to breakdown stories in the Product Backlog into tasks which are 8-16 hours worth of effort and which become a part of the Sprint Backlog. These are the tasks which the team commits to completing at the end of a Sprint (which can be 2-4 weeks).
The problem with breaking a good user story into tasks like "Create the UI", "Develop the Service", "Test the Service" etc... and maintaining them separately in a backlog , is that it encourages Scrum Masters to allow different people in the team to pick these bits of tasks of a big user story. So a scenario where Bob (and his pair ?) works on the "Create the UI" task and Ron (and his pair? works on "Develop the Service" in parallel, in order to finish work fast is encouraged in the team.
Scrum templates like those proposed by Ken Schwaber, take it even further by asking people to track hours logged on these tasks. Not only is tracking tasks like these unnecessary, but if a developer does not develop a story end to end, he completely misses out the bigger picture of the architecture. This is where a team ends up with UI experts who know only JavaScript/HTML with no clue of the services layer and Services experts who just develop services without knowing their consumers.
The problem with breaking a good user story into tasks like "Create the UI", "Develop the Service", "Test the Service" etc... and maintaining them separately in a backlog , is that it encourages Scrum Masters to allow different people in the team to pick these bits of tasks of a big user story. So a scenario where Bob (and his pair ?) works on the "Create the UI" task and Ron (and his pair? works on "Develop the Service" in parallel, in order to finish work fast is encouraged in the team.
Scrum templates like those proposed by Ken Schwaber, take it even further by asking people to track hours logged on these tasks. Not only is tracking tasks like these unnecessary, but if a developer does not develop a story end to end, he completely misses out the bigger picture of the architecture. This is where a team ends up with UI experts who know only JavaScript/HTML with no clue of the services layer and Services experts who just develop services without knowing their consumers.
To me, a good user story which has business value, is the only unit of work I would like to track. Developer pairs in a team should be encouraged to work on complete user stories so that they understand the architecture end to end , and have the satisfaction of adding business value to the product they are working on. This is extremely important but unfortunately I have seen many adopters of Scrum mislead by popular Scrum literature available.