 User stories serve the same
purpose as use cases but are not the same. They are used to create time estimates for the release
planning meeting. They are also used instead of a large requirements document. User Stories are written by the customers as things that the system needs to do for them. They are similar to usage
scenarios, except that they are not limited to describing a user interface. They are in the format of about three
sentences of text written by the customer in the customers terminology without techno-syntax.
User stories also drive
the creation of the acceptance tests. One or more automated acceptance tests
must be created to verify the user story has been correctly implemented.
One of the biggest misunderstandings
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. |
Developers estimate how
long the stories might take to implement. Each story will get a 1, 2 or 3 week estimate in "ideal development
time". This ideal development time is how long it would take to implement the story in code if there were
no distractions, no other assignments, and you knew exactly what to do. Longer than 3 weeks means you need to break
the story down further. Less than 1 week and you are at too detailed a level, combine some stories. About 80 user
stories plus or minus 20 is a perfect number to create a release plan during release
planning.
Another difference between
stories and a requirements document is a focus on user needs. You should try to avoid details of specific technology,
data base layout, and algorithms. You should try to keep stories focused on user needs and benefits as opposed
to specifying GUI layouts.  |
