The customer uses stories and iterations to make his schedule. Developers use tasks. Each developer has his own velocity, measured in the same way as the team velocity. If you implemented tasks worth 10 ideal hours in the previous iteration, you can choose tasks that add up to 10 ideal hours for this iteration. Developer velocity takes into account time spent in meetings, in planning, and in pairing with other developers.
Tackle the most important and the riskiest tasks at the start of the iteration. Invest your time and energy where it’s most needed, leaving the easier tasks until the end. This will give you more time to spend implementing, integrating, and testing difficult tasks. It also tends to make the end of an iteration less stressful, in marked contrast to the crunch times that often occur in other projects.
How you choose tasks is less important than working on just one task at a time. Some teams prefer to dole out tasks during iteration planning, having each developer estimate his own tasks. Some teams estimate tasks as a team, having developers sign up for tasks at the end of the planning meeting. Still other teams have each developer choose one task at the start of an iteration. The remaining cards go on the whiteboard and developers choose from the stack as they finish.
Every developer should spend as much time pairing on one of his tasks as he spends pairing on another developer’s tasks. Because tasks are short, it’s easy to form and reform pairs ...