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 understood the customer's requirements. The customer needs to understand that in spite of the best efforts and best XP practices of the team, some defects will probably be discovered by acceptance tests, and a few may even make it past both the unit and acceptance tests. Explain the options available for handling these defects.

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 forgot to mention. Maybe this iteration's story didn't cover the ability for the system to handle a large number of users, and a large numbers of users causes a crash.

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 next iteration until all defects, even trivial ones, are fixed.

If the customer changes his mind about his standards for quality, those should be included in stories for subsequent iterations, along with new or changed ideas he's had during the iteration.