How to create a User Story Map

User Story Mapping Series

* How to Create a User Story Map
* How to Prioritize a User Story Map
* Tips for Facilitating a User Story Mapping Session
* Don't Etch your User Story Map in Stone
* User Story Mapping Tool Review – SmartViewApp
* Story Maps - A Testing Tool After All

User story mapping is becoming a popular technique through the efforts of Jeff Patton and others that allows you to add a second dimension to your backlog. Here are a few reasons you should consider using this technique:

• It allows you to see the big picture in your backlog.
• It gives you a better tool for making decisions about grooming and prioritizing your backlog.
• It promotes silent brainstorming and a collaborative approach to generating your user stories.
• It encourages an iterative development approach where your early deliveries validate your architecture and solution.
• It is a great visual alternative to traditional project plans.
• It is a useful model for discussing and managing scope.
• Allows you to visualize dimensional planning and real options for your project/product.

Want to hear more? I talked about the value and use of User Story Mapping with Richard and Carl on show #750 of DotNetRocks.

To create your own user story map:

1. Form a group of 3-5 people who understand the purpose of the product. 3-5 seems to be the magic number. Any less and you might miss some ideas. If you add more people, it slows the process down and there are diminishing returns on the quality of ideas generated.

2. Start by gathering the major user tasks of the project/application in silence - the “things people do”. Each person takes the same coloured post-it and silently writes down one user task per post-it. Once everyone has finished writing their post-its, have each person read their post-its aloud and place them on the table in front of the group. If anyone has duplicates they should be removed at this point.

• Depending on the size of your application it can take 3-10 minutes to get all the major tasks, but you can watch the body language to see when they are done. You will see that the group goes from huddled in at the beginning to standing/leaning back at the end.
• Likely each post-it starts with a verb. (eg. Compose E-mail, Create Contact, Add User, etc)
• These are the high level user stories called “User Tasks” which forms the "walking skeleton" of the map.
• When they are done, point out to your team that in a few minutes they gathered most of the high level scope and that if they missed a user task or two, someone else probably didn’t. This might be their first ‘aha’ moment for silent brainstorming.

3. Next ask the team to group the post-its in silence. Simply ask them to move things that are similar to each other closer to each other and things that are dissimilar to each other should be moved farther apart.

• Use silent grouping simply because it is faster than grouping them out loud.
• If duplicates are found, remove them.
• Groups will form naturally and fairly easily.
• Once again, body language will help you see when they are done - usually 2-5 minutes.

4. Using another colour of post-it, name each group and put the post-it on top of the group. This step can be done out loud.

5. Arrange the groups left to right in the order a user would typically complete the tasks.

• If the group can't decide on an order between two or more tasks, it probably doesn't matter.
• The groups are called “User Activities” which form the backbone of the map.
• You should now have the first 2 rows of the user story map - something similar to this:

A1       A2    A3          (user activities = backbone)

T1 T2 T3 T4 T5 T6 T7 T8 T9 (user tasks = skeleton & timeline)

6. Now walk the skeleton to make sure you haven't missed any major user tasks or activities. You can walk through user scenarios, or even bring in users and ask them to walk through their job functions to make sure everything is accounted for.

7. With a finished framework for the map, you can add more detailed user stories below each user task before breaking your map into releases. I like to use the same silent brainstorming technique to generate the initial set of stories for each user task and augment it with other techniques such as user scenarios and personas. Once you have a good set of stories, then you can put your release lines in the map and ask your users to prioritize top to bottom.

• I like to put the first release line on the map pretty high on the map so that it only allows for 2-3 user stories per user task in the first release. This has been an effective way to encourage prioritization and scoping.
• Because all the stories end up on small post-its, you can forgo the traditional 'as a' format and just put the story title on the post-its. This will allow you to read the map a little easier.

8. Finally, I like to take all the user stories in the first release and do some serious user story slicing to make sure we have sliced the first release as thin as possible. As a guideline, you should strive to be able to create the whole app (at least one small user story slice for each user task) in the first iteration or two.

"An example would be handy right about now" (Brian Marick)

(click to enlarge)

Here is an example user story map for creating the next email client competitor:

• The second row contains the "things people do" in an email client such as Compose Email, Send Email, and Create Appointment. 
• The first row contains the groupings for those things people do. 
• The first yellow row is the smallest user story slice for each user task. For Compose Email, that means a basic form with To, Subject, and Body text fields plus Send and Cancel buttons. Functionality for RTF support, HTML support, adding attachments, getting email addresses from your contact list etc, are not included in this user story but are included as user stories lower in the map. 
• The small blue and orange post-its on the larger yellow post-its indicate the status of that user story. The blue ones say "done" and the orange ones say "wip" so that you can see your project status flow down the map.

If we now build the first row left to right before working on any stories in the rest of the map we can deliver all of the basic functionality quickly. This enables us to validate our messaging architecture (i.e. Send an email and then make sure you can Read it). It also allows us to test all the basic functionality in the application end to end so that we can make sure it all works together while getting feedback on whether or not it will solve the business problem. If we were building the very first e-mail client, we could release to the public at this time. Notice also that we did not have a user story for "Delete Contact" in the first release - we don't need to deliver functionality for each "User Task" in each release.

Finally, some definitions:

(click to enlarge)

• The post-its you create in Step 2 are the User Tasks (blue post-its in the diagram). 
• The groups and group names in steps 3 and 4 are the User Activities (orange post-its). Jeff calls these top two rows the backbone and walking skeleton of your application. 
• The user stories (yellow post-its) are organized under each User Task in order of highest to lowest priority for that User Task. 
• The chronological order of how users will typically use the application goes left to right (Time).

Subscribe to Winnipeg Agilist by Email