Getting Started!
The following suggested steps will help you get started with capturing requirements as user stories:
-
Start with identifying user roles.
-
Repeat the process until all user roles are identified.
-
Capture user roles on index cards, sticky notes, or in a computer file.
-
Schedule one or two brainstorming sessions with team members and stakeholders to capture stories.
-
Remember that the goal is "quantity over quality."
-
Put everything in a visible place (use sticky notes or index cards with push pins).
-
Keep discussions at a high level.
-
Capture everything.
-
Stick to the allocated time (1 to 2 hours per session)
-
Limit negative feedback and avoid lengthy debates.
-
Schedule additional sessions to refine and revise stories.
-
First, combine user roles.
-
Next, group common stories together and refine them.
-
Update user roles after each refinement.
-
Keep all earlier index cards until you have finished the process.
-
Identify large user stories (epics) and dependent stories.
-
Group user stories into themes.
-
During sessions, look for nonfunctional requirements.
-
Many can be expressed as "constraint stories."
-
Others cannot, so you might need to expressed some stories in another appropriate or traditional way.
-
Then put automated tests in place and run them every day.
These steps can be performed many times. You can identify a user story and start adding a few confirmations.
Then you can refine it and add a few more confirmations. Next, you can identify another user
story, refine it, add two more user stories, go back and add a confirmation to an existing user story, and so
on.
If you use this practice with the iterative development practice, you automatically get iterations, and you
will repeat these steps (in other words, the tasks of this practice) for each iteration. For example, the team and
stakeholders can identify all user roles and user stories (to the best of their knowledge) at the initial
iteration of the project, and then refine user roles and user stories at each iteration so that the prioritized user
stories get detailed, developed, and tested during the iteration they are assigned to. You can also identify new user
roles and user stories throughout later iterations as the team and stakeholders learn from user stories that are
delivered at each iteration.
User stories compared to use cases
User stories tend to be relatively informal and incomplete, leaving details to be resolved during implementation. They
work well when a complete, detailed requirements specification is not required or desired. If a detailed requirements
specification is needed, alternative techniques, such as structured use cases, may be preferable. It is also possible
to combine techniques, for example, by using high-level use cases to provide context and to organize primary goals of
the system and user stories to define the increments in which use cases are delivered.
Common pitfalls
Watch for these problems:
-
When user stories are dependent on other user stories or functionality is duplicated in different user
stories, it makes prioritization of user stories more difficult. Try to remove duplicate functionality and
avoid, as much as possible, dependencies between user stories, or use a traceability mechanism.
-
When there is no ongoing communication with stakeholders, it becomes difficult to create valuable user stories at
the right level of detail to capture the essence of the stakeholders' needs. The lack of communication
also makes it hard to negotiate user story priorities with stakeholders throughout the project.
-
When the scope of user stories is too big, it is harder to estimate them and assign them to be completed
in one iteration or cycle, which makes it difficult to develop user stories in a timely manner.
-
When user stories do not clearly describe ways of being confirmed (or tested), it becomes hard to make sure that
tests match the intention of the user stories and that the solution meets stakeholders' expectations.
|