Extreme Programming Pocket Guide

Chapter 12. Task Cards

Task cards are the developers’ primary planning tool. They answer the question of how should it be done? Tasks represent the actual development steps necessary to implement a user story. Tasks for the example Ferris wheel story might include “Create a FerrisWheel class,” “Add the Ferris wheel to the park,” and “Add an Employee to run the Ferris wheel.”

Every task card is related to a story card; all development work is prompted by customer stories. Task cards represent developer responsibilities. They’re technical in nature, identifying the story’s implementation details. Task cards communicate high-level design ideas between developers.

Developers write tasks during the iteration planning meeting based on the scheduled story cards. Given a story card, developers break it into tasks, sketching out its implementation details. This design is just enough to estimate the number of ideal work hours each task will cost (see Estimates and Schedules in Part III).

If a story is still too hard to break into tasks, or if a task is too hard to implement, experiment with a spike solution. In a spike solution, one or two developers write a little bit of code to explore the problem. There’s no need to be formal or clean—you’ll throw away the code. The purpose of this exercise is to learn just enough about the problem to be able to write task cards or to estimate the work involved.

Tasks should be small, usually just a few ideal hours. Tasks should be specific. The starting and ...