Stories or User Stories is the XP practice of thinking about software in terms of units of customer-visible functionality. A canonical form of a user story looks like "As a <user-type> I want to a <goal> so that <reason>". For example, "As a Frequent Flier, I want to rebook a trip so that I save time when booking trips I take frequently" (from Mike Cohn's User Stories applied). When possible it is also a good idea to attach the acceptance tests to user stories.
This form of expressing the requirements helps not to loose the focus on the actual reasons for having the feature implemented. Going further it is recommended to keep your stories physically written on a paper index card - natural place for the acceptance tests is on the back of the card. The paper card makes the requirement very tangible and its relatively small size keeps the team from the temptation of over-detailing the requirement in advance. Unlike the traditional requirements user stories are a "promise for conversation" that has to be detailed together with the customer or the customer proxy when the work on the story is being started. Many teams find it useful to track the work progress by moving the user stories on the big board in their Informative Workplace.
This page is a part of the Extreme Programming overview