Getting to the real work

At this point we have broken down user stories into iterations. Can we assign stories to developers to start coding immediately?
In short, no.
First, some user story may require the completion of other user stories!
Second, your work is more granular than your user stories. User stories are for your user—they describe exactly what your software needed to do, from the customer’s perspective. For coding purpose, each user story is really a collection of specific tasks—small bits of functionality that can combine to make up one single user story.

Tasking the user stories

A task specifies a piece of software development work that needs to be carried out by one developer in order to construct part of a user story.
Each task should have
- a title so you can refer to it,
- a rough description that contains details about how the development of that task should be done, and
- an estimate of time needed.
At this step, you have to break your user stories into tasks.
You can use the poker game technique to get the time estimates for tasks like for the user stories.
You can use sticky notes to write down the tasks.
Eask task estimate should be between 1/2 and 5 days in length. A short task, measured in hours, is too small. A task lasting more than 5 days can make the developer lose focus.

Now add up the time estimates for the tasks of each user story. Do the task estimates add up to the estimate of its user story?
If the estimates don’t add up to the user story’s estimate, go by the tasks’ estimates. They are more reliable.
That is why it’s recommended that tasking the user story should be done early—at the time when you do the user stories if possible.