Stories

Stories are XP‘s unit of planning: a piece of customer-visible functionality, named in the customer’s terms, estimated and scheduled by the team.

Ron Jeffries’ formulation from 2001 is the one that stuck, and it is three parts rather than a template:

• Card. “User stories are written on cards.” The card is deliberately too small to hold the requirement; it is a token and a reminder, not the specification.
• Conversation. The requirement actually travels through talk, “an exchange of thoughts, opinions, and feelings” between customer and programmers, spread across planning and the work itself.
• Confirmation. The customer says how they will confirm the thing was done, which is an acceptance test. The story is not finished when code exists; it is finished when the agreed check passes.

The frequent misreading is to treat the card as a small requirements document, at which point the conversation is skipped and confirmation degrades into a demo. The three-part structure exists specifically to prevent that: two of the three parts are not writing.

Naming is the load-bearing part

A story is written in the customer’s vocabulary, which is the same discipline that ubiquitous language asks for. If the card says something the domain expert would not say, the conversation it is supposed to provoke will be about translation rather than about the domain.

Stories feed the weekly cycle: the week’s work is the set of stories the customer picked.

Signal: the conversation about a story happened, and someone can state the confirmation before the code is written.

Sources

• Ron Jeffries, Essential XP: Card, Conversation, Confirmation (30 August 2001): the three Cs, the card as an incomplete record, conversation as the medium, and confirmation as acceptance test.
• Kent Beck with Cynthia Andres, Extreme Programming Explained: Embrace Change, 2nd edition (Addison-Wesley, 2004): Stories as a primary practice in chapter 7, per the published table of contents.