User Stories
A User Story is a short description of the behavior of the system from the point of view of the Product Owner. 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.”
Another way to view a Story is that it’s a reminder for a future conversation between the Product Owner and the Development Team. There should be enough detail in the Story to allow everyone to remember what the Story is about, but no more. The conversation takes place during Iteration Planning, at which time the Programmers ask questions of the Product Owner in order to flesh out the details of the Story, and then brainstorm the Tasks required to implement it.
A good mnemonic to remember is Ron Jeffries’ 3 C’s: Card, Conversation, Confirmation.
Often, 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 Product Owner 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 Product Owner can visualize the entire system. Since the cards can be easily moved around, the Product Owner 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 Product Owner 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.
By initiating and using this process, the balance of power between the Product Owner and Developers is much more even. The Product Owner needs to feel ownership of and take responsibility for the care and maintenance of the Stories. This allows them to feel comfortable making priority decisions about the Stories, add new ones, and add new detail to existing Stories as development progresses.
User Stories also drive the creation of the Acceptance Tests. One or more automated acceptance tests must be created to verify that the user story has been correctly implemented.
Different than Traditional Requirements
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 Product Owner 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.
Different than Use Cases
Use cases tend to be complex and formal such that the Product Owner doesn’t want to touch them. This leads to development asking all the questions and writing down all the answers and taking responsibility for the resulting body of work. The Customer is reduced to sitting on the other side of the table and pointing. Using stories provides a form of expression that is more approachable than a formal use case.
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.
These posts may also be interesting...
Smaller User Stories?We are the Borg
Every little thing
What problem are you trying to solve?
There’s a new look around here
Product Management
comments powered by Disqus