A user story is a brief description of a feature of the system. Stories are small, taking only a week or two to develop. The best stories provide direct business value. When stories are too big, they must be split. Consequently, it may take multiple stories to provide business value. In this case, the individual stories need to demonstrate to the customer that the team is making progress toward the desired business value.

There is no need for a lot of detail in the description. The details will be flushed out when the acceptance tests for this story are defined. Typically, XP user stories are written on small index cards, one story per card.

Each user story will have a set of conditions or acceptance criteria to fulfill before it is considered done. Basically, an acceptance criterion defines an interaction scenario between the user and the system. There is usually more than one possible scenario or acceptance test criterion for a typical story. The acceptance test criteria are converted into automated customer tests when the story is being implemented.

For simplicity, the test criteria are often written natural language. However, this makes them prone to misinterpretation. To address this issue, some teams provide simple tools that allow the customer to write the acceptance tests criteria in a form that can be executed directly by application-specific acceptance test framework. Ultimately, it is the responsibility of the customer to provide the customer tests