On-Site Customer

According to the textbook the on-site customer is part of the XP team (variants). The typical task of the customer is to specify his requirements using user stories. For each of the user stories, he also creates acceptance tests, which help to decide whether a user story has been implemented correctly.

Another important task of the on-site customer is to server as an information source, should there be questions regarding user stories. For the planning game, user stories are described only to a level, which is necessary for estimating the effort. Once you want to start the implementation of the user story it is normal, that additional information is required.

Example 1:
The user story is: "When a customer places an order with a value of more than 80 US-$, shipping will not be charged. If the order has a value of less than 80 US-$, the customer will be charged 10 US-$ shipment costs."
For estimating the effort, this might be sufficient. However, for implementation it is not. In that case, you would have to ask, what should happen if the order has a value of exactly 80 US-$.

Example 2:
You don't believe this is a real life example? Here is another one. Once there was an airplane model, which had a intermittent failure of one of the engines during take off. It took a long time to find out, that the software controlling the engines handled the cases for a speed of 'less than 80 mph' and for a speed of 'more than 80 mph'. The software however did not handle the case of a speed of exactly 80 mph. The defect was intermittent because the speed was not measured continuously, but only every quarter of a second or so. Therefore in many cases, the speed was 79.8 mph and then in the next sample it was 80.1 mph.

The following example shows, what could happen if a customer is not available for a few days:

The user story was: "After pressing the Modify-button, selected fields loose their read-only status and can be modified." The customer was not available immediately, and so the programmers read "selected" and made the assumption that the use has to select with the mouse the fields, which he wants to modify. Then he would click the 'Modify' button and the selectd fields would then loose their read-only status.

Unfortunately, the customers intention was completely different. After he was available again, he discovered the discrepancy between his intent and was actually implemented. The correct behavior would have been, that there would be some fields, which would never be modified by the user, e.g. the creation date of a database record. After clicking the 'Modify'-button all other fields would be editable.

The example also shows, that the damage was relatively small, as the customer was not available for only one day. It also has to be noted, that the discrepancy was not detected at the end of the release cycle [link?] (which happens quite a few times with traditional approaches), but right after the programmers had finished the user story. The issue was solved immediately, and the work continued as usual.

Variants

Although the solution described above is the optimal solution, in practice it might not be possible to have the customer on-site in some cases. Then you have to think about alternatives, taking into account that each of the alternatives has disadvantages compared to the textbook solution. Generally spoken, the communication effort will be significantly higher.

One possibility is selecting a person from the XP team, which acts as a proxy for the customer. Again, there are different incarnations of this solution. In some companies the product manager will be used for this role; other companies prefer that the programm manager assumes this position. Finally it is possible to simply assign the task to one of the programmers.

These variants will be of particular advantage, when you are working on a system, which will be purchased by huge number of customers or which will be used by huge number of users. Generally, it would be very impractical, if the vendor of a word processor integrates all users of that software.

Tips

• If it is not possible to have an on-site customer, you should at least have some sort of proxy in your team.