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.
Links
- Wikipedia on User Stories - brief, but not too comprehensive article
- User Stories Applied: For Agile Software Development
by Mike Cohn - every book by Mike Cohn is a must read for the agile practitioners. This book tells about what makes a good user story, why they work and how to apply them. (non-affiliated link)
- User stories on Mountain Goat Software - an excellent set of Mike Cohn's articles and presentations on the topic
- Advantages of User Stories for Requirements - a particularly good article with the examples and explanations
- Essential XP: Card, Conversation, Confirmation - the Ron Jeffries' view on how critical user stories are to the Extreme Programming
This page is a part of the Extreme Programming overview
RSS feed
Comments
Post new comment