Wednesday, March 14, 2012

How to create a User Story Map

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

32 comments:

  1. I was at your discussion at Prairie Dev Conn last week on this. I never got the chance to ask you: how would you apply this to a re-write project of a legacy application?

    Quite often our clients have the feeling that "I don't feel comfortable releasing this into production until we can do everything that we can do now in our legacy system". As a result, we are often forced into a "big bang" release... our day to day practices still follow agile methods, but we're not able to release something into production until we've delievered at least what they have now. This usually results in the less iterative approach (thinking of the Mona Lisa example).

    Maybe this is a much large discussion on applying many other agile practices to rewrite projects, but it all starts at the base. Are there any tips you have for using story mapping in this situation?

    ReplyDelete
  2. Hi Yogi, thanks for the question, and yes it is a much larger discussion. The answer depends on your situation, but let me tell you two re-write stories. These stories aren't necessarily about user story mapping, but about trying to release to production as soon as possible.

    Story #1. We have a VB6 application that is well used but is becoming increasingly difficult to maintain and improve upon. The organization decides that it needs to be converted to VB.Net in order to make the application more maintainable for the future.

    Our team considers two options for re-writing the application. Option A is to re-write all the code over 1-2 years. During that time we might have a code freeze, or we might allow only minor emergency fixes. The project ends up taking 2 years to complete during which time the business has received no additional value from the application. After 2 years we finally start the next project to add additional functionality.

    Option B is to use a tool to convert the code to VB.Net over a matter of weeks. The code is still ugly by current standards, still uses old patterns, and is still hard to maintain. However, we now pick some smaller projects and improve the code base little by little over time while delivering value. For example - one of the requests in the project queue is to add some new business rules that will trigger some data to be sent to PeopleSoft. This involves touching two screens and creating a new interface to PeopleSoft. We completely re-architect only the two affected screens using a 3 tier architecture, automated tests, etc, and then deploy the change. This allows us to deploy more frequently and provide value sooner. We still have a lot of 'old code' hanging around, but we change it over time whenever we have to touch it.

    Story #2. We have a large legacy COBOL system that has been targeted for conversion to Scala with a noSQL database. The team is super excited about using these new technologies and the business is hopeful about the results. Once again, the team looks at two options.

    In Option A, the team decides a big bang approach is required due to the incompatibility of the technologies. We estimate a 3 year effort and start re-writing the application. Since this application is core to the business they cannot freeze enhancements during that 3 year period and they continue to make changes to the COBOL code base. The 3 year project grows to a 5 year project as each new enhancement request is added to the conversion effort.

    In Option B, the team decides to convert one piece of the application at a time and write some conversion routines to keep the data in sync between the old DB and the new noSQL DB. They begin by converting their CRM screens and data. This allows their sales reps to begin accessing this data online and opens up possibilities for projects such as mobile access and better tracking of sales funnel information that the current system doesn't support. We deploy the new CRM module after 4 months and turn off editing in the old system while providing real time one way data conversion from the new system to the old. We now duplicate this upgrade pattern until the whole application is converted.


    For each of these stories there are other options to consider and the decision making is never simple, but the key question that was considered for Option B of each story is this: How can we deliver value to the user as soon as possible? In my opinion and experience, multi-year projects simply contain too much risk and delayed value - I would ask you to look at most 3-6 months ahead.

    (Any resemblance to your stories are purely coincidental ;)

    ReplyDelete
    Replies
    1. So swinging this back around to the story Mapping, in order to do option B, in your opinion, would story mapping be a good way to identify which parts of the system to tackle first in order to deliver value to the user asap

      Delete
    2. For sure. There are other options of course, but visualizing the different tasks and activities is a nice way to help you understand the system at a glance, look for dependencies between the pieces, and then make decisions about priorities and strategies based on that visualization.

      Delete
  3. Excellent post Steve, thanks.

    ReplyDelete
  4. I like the examples in the comment at least as much as the post itself.

    Do you enter the information from the user story map into a computer after it is created, or what happens with it?

    ReplyDelete
    Replies
    1. You can use cardmapping.com to enter the map if you like, but in general the map is put on the wall in your project room and is kept up to date manually.

      Delete
  5. I have a question on the stories themselves. It seems that the activities in each map would be for a single user (or possibly multiple as some activities span across multiple users). Would you then suggest that a story map be built for each "persona" or would it be better to map each activity like this (blue stickies)

    Title of map - Email

    As an administrative assistant, I need to access my bosses inbox and send / respond to email on behalf of him.

    As an executive, I need my administrative assistant to setup appointments on behalf of me.

    VS having one map for an admin and another map for

    Tile of map - Administrative assistnt - email
    Titel of map - Executive - email.

    Any thoughts? I'm sure both are ok, but i wanted to see what others are doing

    ReplyDelete
    Replies
    1. I use one map per project regardless of the personas involved. Quite often the first row of the map (orange post-its / user activities) are specific to one persona, but not always.

      The two stories you wrote above are interesting. You could re-write each as an administrative assistant or as an executive and they wouldn't change scope would they? Example:

      "As an executive, I need my admin assistant to setup appts on behalf of me" = "As an admin assistant I need to setup appts on behalf of my executive".

      I can't think of any examples where having two maps would be beneficial for one project. Having everything in one map gives you the benefits of visualization, etc. Having two maps would diminish that wouldn't it?

      Delete
  6. Hi Steve,

    Thanks for the post.

    I'm not sure exactly why, but each time I see story maps, I can't help but think that they're just another way of visualizing a gantt chart.

    By placing stores into release two and three, are we trying to display to our customer that we're able to accurately predict the future?

    (sorry, feeling particularly curmudgeonly today, I blame the heat).

    Ta.
    Steve Porter

    ReplyDelete
    Replies
    1. No problem Steve - I guess you could abuse any tool or agile/lean technique eh?

      Personally, I try to identify only one release at a time. The second release starts to take shape once the first release is in progress and everyone agrees a second release is necessary and what the purpose of that release will be. This just become more information that we *could* use to look into the future and make some better guesses.

      Also, just to be clear - a release may be to 'production' and it may not. It could be days long or weeks long. A first release might just be confirmation that we can technically solve the problem, that our architecture is effective, that our requirements assumptions are correct, etc.

      Delete
  7. I know I am a little late to this discussion, but this sounds like Business Analysis to me.

    ReplyDelete
    Replies
    1. Hi David,

      When I talk to my wife (not involved in software at all) about agile/lean her response is often: "all of this just sounds like common sense to me - I don't get why people aren't doing it."

      It sounds like you agree with her assessment.

      Delete
  8. User Story mapping is a feature I would like to see in agile project management software like On time, hope this article inspires ISVs, thanks!

    ReplyDelete
    Replies
    1. Hi Carlos,

      Story Mapping is a great approach to plan the road map and keep track of the big picture.
      There is a plug in for JIRA, a project management software available. Have a look at this:

      http://bauer-information-technology.com

      cheers,
      Florian

      Delete
  9. Any hint about a software which allows you to create user map to be integrated in an electronic document? I tried cardmapping.com but you cannot save it locally on your PC. Something resulting in image like the example one in Steve's article would be very nice.

    Thank you

    ReplyDelete
    Replies
    1. Sadly, I created those images in PowerPoint... I work mostly with non-distributed teams so the map itself is only represented with post-it notes on the wall and not in a tool. In fact, with local teams I don't yet see the benefit of using a tool for the map.

      I know there are vendors working on integrating mapping into their tools (see the JIRA plug-in above) but I haven't personally taken a look at the market. If anyone impartial wants to do so, or has done so, I'll edit the post to add the results.

      Delete
    2. I did not find an easy cheap user map presentation tool, so I also ended up with PowerPoint :)

      Delete
    3. BTW, cardmapping.com does allow you to save maps locally. When you create a new map, check off the "Import / Export to Spreadsheet" checkbox. I've used the export for backing up a map and the import for making changes to a map.

      Delete
  10. Looks like this tool can help distributed teams to view story maps http://toolsforagile.com/silverstories/

    ReplyDelete
    Replies
    1. Looks like it does indeed - check out this link for a visual: http://toolsforagile.com/site_media/website/images/screenshots/2_story_map.png

      Delete
  11. Trello can be bent as a storymapping tool.

    ReplyDelete
  12. Steve, thanks for an inspiring and great post.
    I've tried the story mapping technique a couple of times and the power of it in order to find a releasable path in the backlog is amazing.

    ReplyDelete
  13. perfect article and really good input... i still try to figure out in which software / app the example was made in (email client competitor) - these sticky notes look really nice! i could not figure out if it was just a layout or an actual app... would be nice it you could claryfie that since i am looking for an app like this. all i found out there were those online things like JIRA (atlassian) or such... but these not only cost to much for the NPO i am working for - i also only need a small and easy way to display the slices etc. - no need for such sophisticated tools...
    maybe you have an idea also on that... (mac osx would be nice!)
    steve: thank you so much for all the effort!!!
    great work!
    daniil

    ReplyDelete
    Replies
    1. Hi Daniil,

      I created the example in MS PowerPoint but I wouldn't recommend that for your projects. The best maps are analog with post-it notes. If you have need for a digital map, check out some of the links in the comments.

      Delete
  14. Hi there,

    You can try this new tool for story mapping: http://www.featuremap.co, it's free
    Please also share your feedback & comments on the tool.

    ReplyDelete
  15. Great article, Steve! I have one question on dealing with multiple users in a map:

    Let's say for example, that we're building a (real simple) trading website, where:

    Customers can:
    -Login (if they are new to the system they can create an account)
    -Place buy/sell orders and check them

    Brokerage administrators can:
    -View orders
    -Cancel orders

    That's it for now. Using story mapping, what I still need to understand is how to deal with:

    a) Multiple users (in my example, customers and brokerage admins have their own sequence of actions, and the actions one does can be indepedent from what the other does, meaning what a customer does not necessarily is a previous step for what a brokerage admin does).

    b) Conditional actions:if an user does not have an account, he/she can create one, so each step (login, create new account) would become a separate story? Should they follow a sequence in the timeline?

    Comments?

    Thanks!

    ReplyDelete
    Replies
    1. Thanks MegaBlue,

      First, don't get too bogged down on the sequencing - use it where it is helpful and if your app doesn't always follow a sequence, organize your map for the most common sequence or one that makes sense for you and your team.

      Second, from your brief description, I see the first two rows of your map might look like this:

      Manage Account:
      - Register
      - Login
      - Maintain Account
      Manage Orders (Customers):
      - Place buy/sell order
      - Check orders
      - etc
      Administer Orders (Brokers)
      - View Orders
      - Cancel Orders
      - etc

      This orders the three user activities left to right - You have to register and login before placing an order and a brokerage has to wait for a customer to place an order before they can administer that order. Also, within each user activity, the user tasks are ordered left to right - you have to register before you can login, etc.

      Delete
  16. Hi Steve,

    Great article and useful comments as well. I want to follow up a little more on megablue's example. We have more than one persona, actually close to a dozen, and some of the tasks is shared between them while others are not. Is it useful to identify all the possible users on the tasks/activities? In addition, this is not a new product, but we are still introducing a lot of new features into it. How do you construct a story map in release 13 of an enterprise product? Would it still be useful to map out the existing functionality in case there are gaps? Would that be a waste of time?

    thanks in advance

    ReplyDelete
    Replies
    1. Thanks for the Questions Patrick.

      1. "Is it useful to identify all the possible users on the tasks/activities?" That's hard for me to answer for you - I would suggest you try it, see if it is useful, and then let us know in the comments. Personas and User Scenarios are often partnered with story maps - so that might be another alternative in order to put the focus on the users and what they need to accomplish.

      2. "How do you construct a story map in release 13 of an enterprise product? Would it still be useful to map out the existing functionality in case there are gaps?" I say go for it - the steps don't really change.

      3. "Would that be a waste of time?". Not in my opinion - story maps are great for bringing together a common understanding, etc.

      Delete
  17. To add to the useful comments here, Dave Rooney wrote a great user story slicing post on his blog that I think you will all find useful:

    "How Thin is Thin?" An Example of Effective Story Slicing
    http://blog.practicalagility.info/2014/08/how-thin-is-thin-example-of-effective.html

    ReplyDelete