A User Story is a short description of the behavior of the system from the point of view of the Customer. They are in the format of about three sentences of text written in the Customer’s terminology without technical jargon. In simplistic terms, user stories are the response to, "Tell me the stories of what the system will do. Write down the name of the story and a paragraph or two."
The conversation takes place during Iteration Planning, at which time the Programmers ask questions of the Customer in order to flesh out the details of the Story, and then brainstorm the Tasks required to implement it.
Typically, the stories are written on 3" x 5" index cards, although an electronic copy may be used. Since index cards are somewhat small, they automatically limit the amount of writing that can be put on them (which is a good thing). This forces the Customer to focus on making the text clear and concise, while being as simple as possible.
Story cards are a great conceptual tool. When they are laid out on a table, the Customer can visualize the entire system. Since the cards can be easily moved around, the Customer can 'see' the system from different perspectives. They also work well during development, providing a very concrete reference to how much has been completed, and how much work is left.
Once the Stories have been estimated and the initial Project Velocity set, the Customer can make tradeoffs about what to do early and what to do late and how various proposed releases relate to concrete dates.
There has to be at least one story for each major feature in the system, and it must always be written by the users. The programmers shouldn't write the stories, but they have conversations with the users that are then attached to the stories together with pointers to supporting documentation.
A typical misunderstanding with user stories is how they differ from traditional requirements specifications. The biggest difference is in the level of detail. User stories should only provide enough detail to make a reasonably low risk estimate of how long the story will take to implement. When the time comes to implement the story developers will go to the Customer and receive a detailed description of the requirements face to face.
Another difference between stories and a requirements document is a focus on user needs. Details of specific technology, data base layout, and algorithms should be avoided. Stories should be focused on user needs and benefits as opposed to specifying GUI layouts.
How z user story different from use Cases ?
One approach that has been suggested is to define the Stories during the Planning Process, and then create a Use Case for each Story at the beginning of an Iteration. This allows the deferral of specifying the details of a Story until they're really needed. Some would argue that Use Cases aren't really needed, although it may be a requirement for your organization. At any rate, Stories and Use Cases aren't mutually exclusive.
