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 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.
|