ExtremeProgramming insists on a real customer sitting with the team. But what are the responsibilities of this OnsiteCustomer?

----

''Below is what I found on this in PlanningExtremeProgramming and ExtremeProgrammingExplainedEmbraceChange. -- ArieVanDeursen''

Following ''ExtremeProgrammingExplainedEmbraceChange'' (p. 69), it is the responsibility of the OnsiteCustomer to produce value for the project by
	* writing AcceptanceTest''''''s (here the customer is helped by the Tester, or by scripts that help him to enter tests easily)
	* making small-scale priority and scope decisions for the programmers (required, for example, if during implementation a story turns out to have several alternative implementations with different scopes and estimates).
 
''PlanningExtremeProgramming'' (p. 40) mentions the following customer responsibilities during ReleasePlanning:
	* To define the UserStories
	* To decide what business value the stories have
	* To decide what stories to build in this release 

Moreover, from the ''PlanningExtremeProgramming'' chapter on ''writing stories'':
	* the customer must answer questions from the developers concerning UserStories. The customer should help the developers to understand each story, so that so that they can estimate the effort needed to implement the story.
	* Furthermore, if necessary, the customer must split a UserStory into two or more smaller user stories. The developers estimate the new stories, and the customer prioritizes them. The customer should make the split along priority lines, factoring out some less vital work that can be delayed.

To avoid the risk that the ''customer won't finish'' (i.e., he selects stories that don't result in a coherent system), ''PlanningExtremeProgramming'' (p.128) suggests that it is the OnsiteCustomer's responsibility to present three- to four-month ReleasePlan''''''s to upper management. The big bosses can be good at spotting misfits at a quarterly scale. 

During an iteration, it is the customers responsibility to add stories if there is extra time. Moreover, if there is lack of time, the customer should decide which stories will be delayed. 

During IterationPlanning, the customer reads out the story, so that everyone hears it from the customer's perspective. [''PlanningExtremeProgramming'', p. 87/88]
The customer needs to prepare for the IterationPlanning session by going into more detail about the UserStories (which don't contain more than one or two sentences typically) . For this, the customer can:
	* Give a short talk about the story
	* Produce a written description of the details of the story
	* Provide a full set of AcceptanceTest''''''s for the story.
If the system users report an incident, it is the customer's responsibility to specify new tests to cover this uncaught case [''ExtremeProgrammingInstalled'', p. 163].

During an iteration, it is the customer's responsibility to determine when a particular task is done, and cross it off the list of things to do in the iteration. At the end of an iteration, it is the customer who can demo the resulting feature to the rest of the team -- this also helps the customer to keep up with the work done in the iteration [''PlanningExtremeProgramming'', p.99]

Define business value, decide what to do and what to defer, and define the tests to show that the system works. These are your key responsibilities as the XP customer. [''ExtremeProgrammingInstalled'', p.3]

In short the customer has to steer the project to success [cf. ''ExtremeProgrammingInstalled'', p. xvi]

----
See CustomerCapabilities, WorkshopOnCustomerInvolvement, CircleOfLife

----
CategoryCustomer