Roadmap: How to Adopt the User Story-Driven Development Practice |
This roadmap describes how to adopt the User Story-Driven Development practice.
Main Description
### 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.
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.