Educating the CustomerThis 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
|
Acceptance Criteria
Remind the customer that she defined acceptance criteria in the acceptance tests. Anything that causes an acceptance criterion not to be met is a defect. This is why you invest time in making sure the acceptance tests are thorough and that the development team has clearly
Prepare the customer for issues that
look
like defects but are outside the scope of the iteration. It's one thing to imagine what a screen will look like and how it will work. When the customer sees the live software, he might wish it worked differently from his original description or might think of things he really wanted that he
This is where your acceptance criteria come in handy. If it wasn't part of the acceptance criteria, it doesn't affect the successful delivery of the story. Fortunately, it can easily be included in the next iteration. The customer won't have to wait more than the length of the iteration, one to three weeks at most. It takes time for the customer to build trust in the XP team. She may be afraid to go on to the
If the customer changes his mind about his standards for quality, those should be included in stories for
|