1. Iteration Planning
Tasks are a good last check for iteration planning purposes.
….
They can use that information to develop a better, more reliable/realistic iteration plan.
2. Iteration Burndown (what's left <how many hours> to do within a given iteration)
3. Accountability
Defining and estimating tasks makes team commitments to an iteration public knowledge and increases
the sense of urgency of getting better at task definition and estimation. It also can help with maintaining a sense of focus on agreed upon tasks and indirectly trims waste related to gold plating.
4. Shared and Individual Learning
5. Tasking Encourages Better Design
6. Forecasting Velocity
7. Tasks Serve as Reminders
Even a few days into the actual iteration, you'll forget at least part of what you discussed with the user if you don't have recorded tasks and you'll have potentially less access to the user to confirm/reconfirm tasks and/or stories.
8. Talk to the Dog
9. What if you hear, "I can't/won't task."?
If a team or team member simply says they won't task, that's more of a personal discussion. Obviously asking them why they won't task would be a useful starting point, it may ultimately speak more to ego, personality or an underlying resistance to change.
When a team or team member claims they can't task you have more information to work with. A common stated reason is that they "just have to start coding" and don't really know about the tasks until they start working on it. One approach is to say "Fine, then write down the tasks as you uncover them during coding and we'll discuss and learn from those to make you a better up-front tasker.". You can also allow a "research" task (2-4 hours) to allow a developer to spend time looking at the code, database, etc. for purposes of ultimately tasking a user story.
