Extreme Programming Pocket Guide

Chapter 11. Story Cards

The customer’s most important tool is the story card. Story cards answer the question what should be done? Each card describes a desired feature of the software project in story form—a sentence or two from the customer’s perspective. For example, one story may be “Avatars must be able to ride the Ferris wheel.”

The customer communicates business information through story cards during the planning game. All features start as story cards. They’re passed to developers, who estimate the amount of work each card represents. From the stories and estimates, the customer then schedules the stories, arranging the cards in piles to mark their status—completed, scheduled for the current iteration, or unscheduled.

The customer has complete responsibility over scheduled features—only she can create story cards. Developers may suggest stories, but the customer has final say. Along with their estimates, developers should also identify the technical risks of stories, presenting the complete technical picture to the customer. This will help her choose the correct schedule.

Every story must provide the customer with identifiable business value. This rule helps the customer to invest time and resources in the stories that matter. Any story suggested by the developers should have an obvious benefit. This will likely be technical. For example, migrating to a newer database version may make other scheduled stories easier to implement.

Each story must represent a single feature. If ...