Focus on Value: How to Create Value-Driven User Stories

Transcription

1 ARTICLE Focus on Value: How to Create Value-Driven User Stories by Chris Sterling Scrum Alliance Feb. 25, 2008 Traditionally, software development projects started out with an idea and then tried to identify all the requirements needed to make that idea complete for the intended users. This long process was expensive (and sometimes ended in a no-go decision only after a great deal of money was spent) and did not place enough emphasis on value returned for the investment made. Agile has a tool that can help organizations re-focus on return on investment: valuedriven user stories. Value-driven user stories are created specifically to link features with their users and the value the features have for their users. They can be created from a list of high-level features or a list of values and users centered on a general idea. Value-driven user stories are useful in three main situations: Generating an initial product backlog from the product vision: A Product Owner has an idea for a product. She has not detailed specific features which would make the product come to life. Instead she has an idea of the value she is looking to provide for a specific customer base. In this scenario, we know the value that the product will provide and have identified the intended users of the product. Generating user stories from descriptions of larger and mostly ambiguous features that have risen in priority on the product backlog: We have an existing product backlog that contains smaller user stories, easily consumed by the delivery team, listed as highest in priority. Just a bit lower in priority on the product backlog are larger, more ambiguous user stories, otherwise known as epics. As the smaller, higher priority user stories are pulled from the product backlog by the delivery team, the upcoming prioritized epics become higher in priority and must be broken down into smaller user stories consumable by the delivery team in an upcoming iteration. In this scenario, we will need to identify the value each epic will provide to users that are most interested in that epic. Generating user stories from a product roadmap s next release: A product roadmap is a plan for multiple releases and usually includes high-level descriptions of features, which can be thought of as epics. In keeping with the just-in-time elaboration concept, we focus on the next release in the product roadmap. The epics contained within this release will each be broken into smaller user stories to better understand the release. In this scenario we will need to identify what value each epic will provide to the intended users of the features delivered in the release.

2 To create value-driven user stories for these scenarios, we will need to perform a valuedriven user stories exercise containing the following steps: 1. Brainstorm value statement from product vision, product roadmap, or epic. 2. Identify interested user roles for product vision, product roadmap, or epic. 3. Generate user stories for each user role and value statement we ve identified in Steps 1 and 2 in breakout sessions. 4. Debrief as a group. 5. Capture and prioritize user stories in product backlog. The following sections will describe the setup, suggested practices, and artifacts to be created for each step of the exercise. A preparation guide can be downloaded at Step 1: Brainstorm Value Statement The Product Owner starts the meeting by introducing the product vision statement, product roadmap, or epic that is driving the exercise. The participants may direct questions to the Product Owner throughout the introduction to gain better understanding. When the participants feel comfortable with their understanding it is time to brainstorm value statements. The facilitator for the exercise stands up in front of the participants with either a white board or easel pad to scribe for the group. The facilitator asks the participants: What values or benefits will this [product, release, or epic] provide to a user? As the participants brainstorm value statements vocally the facilitator writes them in a single column on the white board or a sheet of easel pad paper. If the facilitator or any participant believes that a particular statement needs clarification, a mini-discussion commences. When the participants are no longer generating value statements, it is time to go onto Step 2, identify interested user roles. Have a designated facilitator; either the project ScrumMaster or third-party facilitator. Allow enough discussion for the participants to feel comfortable with the product vision statement, product roadmap, or epic. If introducing a product roadmap, focus only on the first release. If introducing a product vision, write down some high-level capabilities the product should have. These may become epics to help drive the exercise. As facilitator, try to evaluate each value statement by asking yourself, Is this statement a value for the end user or a technically assumed value? I have found

3 that in many cases people in software assume certain technical capabilities are valuable to a customer. It is usually best to capture value from an end user s perspective rather than non-functional aspects that the end user is not aware of immediately. List of values that the product or epic will provide Step 2: Identify Interested User Roles In Step 1, you created a list of values that the product or epic will provide. This list is used as a backdrop for identifying user roles who are interested in attaining these values from the product. The facilitator asks the participants, Who is interested in attaining the values that are being provided by this [product or epic]? As the participants suggest user roles, the facilitator writes them in a second column on the white board or on a separate piece of easel pad paper. Allow the participants to make user roles more specific or generalized through discussion. When the participants are satisfied with their list of user roles, it is time to move onto Step 3, generate user stories in breakout sessions. Facilitator should make sure that each user role is reiterated back to the participants for confirmation. Ask the group if they are satisfied with the user role list when the rate of participant suggestions slows down. List of user roles interested in attaining the values that the product will provide Step 3: Generate User Stories in Breakout Sessions Now that we have a list of values the product will provide and user roles interested in these values it is time to generate user stories. The facilitator asks the participants to choose a partner for the breakout session. Ask each pair to choose a user role from the list created in Step 2. Each pair will generate user stories from this user role s perspective for each of the values listed in Step 1. Some of the value statements may not be appropriate for every user role, but they should be evaluated before moving onto the next value statement. The group may not be large enough to cover all of the user roles at once, so each pair should continue to choose a new user role until all have been chosen and their respective user stories generated. (Conversely, if there are not enough user roles, form larger breakout session groups.) It is important that all user stories are written using the Mike Cohn template:

4 As a <<user>> I want to <<feature>> so that <<value>>. Place the user role into the <<user>> slot and the value this user role is attaining in the <<value>> slot. The <<feature>> slot is what is generated based on the user role and value to be attained. Make sure participants understand that each user story should follow the template. It will make the group debrief go more smoothly and decrease the need to rewrite user stories before capturing them in the product backlog. Divide into pairs if there are enough participants (5 or more). When a pair chooses a user role, place their initials or some indicator next to that role. Breakout pairs should focus only on one user role at a time. If a breakout pair discovers a new value, they should add it to the master list of value statements. A stack of index cards or sticky notes with user stories written on them Step 4: Debrief as a Group Once all of the user roles have been chosen and the corresponding user stories have been generated, it is time to debrief as a group. The facilitator asks for a pair to volunteer to go first in order to get started. The pair reads their user stories to the group, asking for feedback after each one. If there is no feedback, the user story card or sticky note is placed into a pile in the middle of the group and we move on to the next user story. If there is feedback then the group helps to generate either a replacement for the user story or to supplement it with additional user stories. Once the group is satisfied, the replacement and/or original and supplemental user stories are placed into the group pile. At the beginning of this debrief, the group may suggest features that the pair has captured but not mentioned yet in their debriefing. In my experience, this starts to subside as we progress through the group s generated user stories. After all pairs have debriefed to the group the facilitator should ask if the group is satisfied with the stack of user stories that were generated during the exercise. If they are satisfied, then it is time to conduct a retrospective so that the team can improve next time the exercise is conducted. Ask for a pair to volunteer to go first in debriefing to the group. Allow group to give feedback on each user story.

5 Facilitator should make sure that the process of placing the user story into a pile in the middle of the group is followed. This places emphasis on completing discussion on each user story before moving onto the next. At the conclusion of this step, conduct a short retrospective on the entire exercise to document improvements that should be implemented the next time it is conducted. Conversation with participants about each user story generated New and modified user stories from group feedback Stack of user stories that are to be captured in the product backlog Step Five: Capture Generated User Stories Now that we have a stack of user stories to be captured in the product backlog, it is important that we do not lose them. I have found that spreading out the user stories on a table, wall, or white board and taking pictures of them is a good practice. The pictures will capture the generated content just in case the index cards or sticky notes are misplaced. It is also important to place the user stories into the product backlog immediately after the exercise has completed. The conversations about each user story are still fresh and the product owner has usually been thinking about priority during the exercise. Not all of the generated user stories must be listed together in the product backlog. For instance, the product owner may decide to focus only on one or two user roles for an upcoming release of the product. Conclusion Agile methodologies emphasize delivering value early and continuously so that customers get the highest return on their investment. By including the value provided by our product features and the user roles that are interested in attaining that value, we are able to more easily prioritize to optimize this return. The value-driven user story exercise supports just-in-time elaboration of features based on the value we are trying to provide and user s perspective of that value. The exercise can be used to generate your initial backlog or elaborate high priority epics throughout the project lifespan. About the Author Chris Sterling is a principal consultant, certified Scrum trainer and Agile coach for SolutionsIQ. With more than 14 years of experience in software development and consulting, Sterling leads enterprise integration projects for technology startups, large corporations, and government agencies with a clear focus on enabling architecture. As an Agile coach, Sterling is an innovator and facilitator to increase product delivery consistency and quality in project management, architecture, and software development. Along with his daily responsibilities, Sterling has released multiple free and open source projects and provides thought leadership on the use of open source in the enterprise. He was founder of the International Association of Software Architects (IASA) Puget Sound Chapter and currently supports the Seattle Scrum Users Group.

6 About SolutionsIQ SolutionsIQ offers a full spectrum of services to develop software and fulfill technical talent needs, while improving your Agile knowledge and capabilities. Clients include AT&T (Cingular), Amazon, Corbis, Expedia, Federal Home Loan Bank, Infospace, Key Bank, Nike, Nordstrom, Safeco, US Bank, and Washington State University. A Microsoft Gold Certified Partner, SolutionsIQ is also a member of the Java Community Process, Scrum Alliance, Software Association of Oregon, and Washington Technology Industry Association. Learn more at