How to convert user stories to tasks

Every Agile team needs to convert, as part of its work, user stories to lists of tasks.

• User stories are stories that describe how the user wants to act on the system and what happens as a result. Implementing a user story can span over many days for the whole team. However, it is preferred to narrow a user story if its estimation exceeds the agile iteration time.
• Tasks on the other hand, are coding + testing missions for one programmer (could be two in cases where pair-programming policy is used by the team). They normally do not exceed one day of work. 

During the iteration planning time it is the team’s responsibility to convert the list of the user stories given by the product owner, to lists of tasks. This is done for the following benefits:

• By splitting user stories to smaller tasks the team is forced to discus implementation issues and to understand better what is needed, and agree how it should be implemented.
• It is much easier to estimate a small task than the whole user story.
• It is possible to track the progress of the team when the team members work on day or less long tasks, this can help the team coach to see and handle problems soon.

Now the question is how does one split the user stories to tasks?

In my team we are working on software that spans over modules. We have a database, business logic servers and a client application.
Most of the user stories involve coding in all modules. Thus, at first, we used to split the user stories with respect to those modules, each user stories became 3 tasks -- database, business logic and client.

It seems natural doesn't it?
Well apparently it is not. Although the team shares the same room, we spent much time on integration. And most of the time, even after all of the user stories tasks were done, the user story itself was not done yet.

Recently we started to create tasks by functionality instead of modules, with this method each task implements part of the functionality required by the user story (maybe even simplified one) but it spans over all modules.
At start it seemed like we are doing more work (instead of working on the database until all work is completed, we now implement in iterations), but this is not true, working like that has a lot of benefits.

Among these benefits are:

• Less integration issues.
• System tests can be a part of the task (Done definition).
• Testing can start earlier.
• If the user story is not finished by the end of the iteration, some times it is still possible to ship 

the part that is done.

In my opinion, what frightens teams from working like that is the fear that newer tasks will create regressions in early tasks.

I see this fear as another benefit since it forces you to write good system tests for each task and insist on the done definition.