Educating the Customer | Testing Extreme Programming

This is an area where you want that ounce of prevention. Educating the customer so he has reasonable expectations is essential. Before you back the XP car out of the garage, talk with the customer about how you'll handle issues. Make him read the defect-handling chapter in Extreme Programming Installed. Better yet, produce your own XP owner's manual that describes your own team's development process and helps the customer get the most value out of the project. Your owner's manual could cover topics such as

Planning. Describe story creation; explain that you defer in-depth discussion of each story until it's selected for an iteration or until it needs to be clarified for the purpose of making an estimate.
Iteration planning, story selection. Outline the negotiation process involved in selecting the stories for an iteration that are both high priority for the customers and make sense for the programmers (in terms of dependencies between stories, creating an initial framework, and so on).
Acceptance tests. List the input expected of the customer as she helps write the tests and the process for running and verifying results before the end of the iteration.
Defect fixes. Define the policy on handling defects. You may choose to classify them into those that must be fixed to call the story complete and those that can be deferred to a future iteration. Fixes that will take up significant programmer resources must be written up as stories for the next (or a future) iteration. Whatever policy you decide on, make sure you and the customer agree on it.
Realistic expectations. Set realistic expectations for the relatively low level of documentation and status artifacts generated as a byproduct of XP. If the customer feels lost without certain metrics or documents, you may be able to find a creative way to provide them without adding excessive overhead. XP is all about being flexible.
Communication tools. Review what's available with the customer. For example, you might have a wiki (see Chapter 30) where he can learn about the status of the project and other general project information. Some teams capture information about iterations, tasks, and stories (as our XTrack system does) that can be used to generate reports of various metrics.