Task Planning

At the start of a new iteration, the developers and customers get together to plan. The developers break the stories down into development tasks. A task is something that one developer can implement in 416 hours. The stories are analyzed, with the customers' help, and the tasks are enumerated as completely as possible.

A list of the tasks is created on a flip chart, whiteboard, or some other convenient medium. Then, one by one, the developers sign up for the tasks they want to implement, estimating each task in arbitrary task points.^[8]

^[8] Many developers find it helpful to use "perfect programming hours" as their task points.

Developers may sign up for any kind of task. Database specialists are not constrained to sign up for database tasks. GUI people can sign up for database tasks if they like. Although this may seem inefficient, a mechanism manages that. The benefit is obvious: The more the developers know about the whole project, the healthier and more informed the project team is. We want knowledge of the project to spread throughout the team, irrespective of specialty.

Each developer knows how many task points he or she managed to implement in the previous iteration; this number is the developer's budget. No one signs up for more points than are in the budget.

Task selection continues until either all tasks are assigned or all developers have used their budgets. If tasks remain, the developers negotiate with each other, trading tasks, based on their various skills. If this doesn't make enough room to get all the tasks assigned, the developers ask the customers to remove tasks or stories from the iteration. If all the tasks are signed up and the developers still have room in their budgets for more work, they ask the customers for more stories.

Half way through the iteration, the team holds a meeting. At this point, half of the stories scheduled for the iteration should be complete. If half the stories aren't complete, the team tries to reapportion tasks and responsibilities to ensure that all the stories will be complete by the end of the iteration. If the developers cannot find such a reapportionment, the customers need to be told. The customers may decide to pull a task or story from the iteration. At very least, they will name the lowest-priority tasks and stories so that developers avoid working on them.

For example, suppose that the customers selected eight stories totaling 24 story points for the iteration. Suppose also that these were broken down into 42 tasks. At the halfway point of the iteration, we would expect to have 21 tasks and 12 story points complete. Those 12 story points must represent wholly completed stories. Our goal is to complete stories, not simply tasks. The nightmare scenario is to get to the end of the iteration with 90 percent of the tasks complete but no stories complete. At the halfway point, we want to see completed stories that represent half the story points for the iteration.