User Stories

During our meeting with David Hussman last Friday, the team asked "what is in a user story?" Simply put, "user stories" represent the behavior of the system from the point of view of the user of the system. Some things to keep in mind:

• A user story is very similar to a scenario
• A user story is best when written as a scenario from the actor's perspective using the system. The customer writes the stories in her own words--user stories are not written by the PM, analysts, or development. (At RFC, this is were we will have some challenges. Our system will have multiple levels of customers: end users, developers--this is a platform that will be used by developers--and implementers). We did have some discussion around how we should deal with this. More to come on this topic.
• Can be written similar to the traditional “the system shall…”
• Doesn’t need all the detail; it’s as much a promise to discuss a feature as a description of it.
• Writer can attach supporting material (report, UI story-board,…etc.)
• The collected user stories represent the requirements for the project

Litmus test for a user story:

• The story must be testable
• Since the customer is the one writing the acceptance test, this means you must know how to test it.

I found this old example of a user story and I think it is a good one:

Story: Add New Contact

[Allow the Salesperson to add a new contact and associate the contact with a customer. The Salesperson will enter general information for the contact such as name, address, and phone number. The contact name is the only required field. The system will validate the required field entry has been provided, and warn the salesperson if it is not.]