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


  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?

  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 ;)

    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

    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.

  3. Excellent post Steve, thanks.

  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?

    1. You can use 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.

  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

    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?

    2. Please where do you write stories like
      As a user i want ... on the story board.
      because it seems like everything here is cut down. i really prefer the as a user i want.... format

    3. How do you now place stories with the standard format "As a user i want..." on the story seems all you are doing is cutting them down too short, i really prefer the standard format though i like this, but there should be a place to write the stand format and also confirmations.

    4. Hi Paul,

      The yellow post-its in the example map are the user stories. You can absolutely write them in the "As a.." format if that is helpful to you and your team.

      In the examples, I describe each story with as few words as possible. If you are using the "As a" format, you could consider this a "title" for your story. Using fewer words makes it easier to visually scan and find the story you are looking for in the map.

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

    Steve Porter

    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.

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

    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.

  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!

    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:


  9. Any hint about a software which allows you to create user map to be integrated in an electronic document? I tried 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

    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.

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

    3. BTW, 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.

  10. Looks like this tool can help distributed teams to view story maps

    1. Looks like it does indeed - check out this link for a visual:

  11. Trello can be bent as a storymapping tool.

  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.

  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!

    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.

  14. Hi there,

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

  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?



    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.

  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

    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.

  17. Still great article Steve!
    For those who are looking for an online tool there's another alternative I recommend trying out:

    (disclaimer: I'm one of the developers)
    We've made it because we wanted a tool that we'd really love to use with our clients on product backlog grooming/release planning sessions where big whiteboards are not reasonable.

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

  19. Hi - I just completed a user story mapping session and your post was very helpful in helping me facilitate this meeting. We are a global organization with teams in Belgium, Switzerland and US. Do you have any ideas on how this story map could be distributed to these teams? Also, the example story map that you have as an example, can you please let me know what tool you used to create the diagram?

    1. Thank you! I'm glad it was helpful and if you have any questions please feel free to reach out to me.

      Unfortunately, I manufactured that picture using PowerPoint so I'm not sure it would be helpful for distributed teams...

      However, as you can see from some of the comments, a few tools are starting to emerge that support story mapping. My favourite so far is Smart View ( The team that created that application was distributed between Canada and Argentina and they used their own tool to handle that coordination.

  20. My team have used and is really great!


  21. Thanks for the great post and abundance of materials you have shared. I know these techniques arose in software development, but I’m having trouble applying it to the work we do in Data Warehousing and Analytical Reports.

    We are building a data warehouse and have to ingest data, apply business rules, and build reports. The user story mapping exercises I have seen focus only on the application / reporting functions, but just focusing on the user needs (i.e. reports) won’t provide you with enough details about the data ingestion or business rules. So my question is, how can you apply the user story mapping exercise to ensure you understand and account for the data ingestion and business rules details of the Data Warehouse?


    1. Hi John, great question. Here are a few ideas & questions:

      It sounds like the flow of your app from a development perspective is : "ingest data, apply business rules, and build reports". What would the flow be from the user's perspective? If you asked them to list the “things people do” in this system, would it be the same?

      Sometimes, it is helpful to think about what the first horizontal slice might be. Is there a particular (and minimal) set of data/rules/reports that you could start with that would provide some initial value to your users or at least validate that your system works end-to-end?

      I recently worked with a team with a similar question. In their system they did very little coding and lots of 'configuring' in the different data ingestion, business rules, and reporting systems. They built their map with those 3 user activities and their first slice was a smaller but important set of data that helped them move a significant way towards proving the project goals & mission.

      Hope this is helpful - if not, feel free to continue reaching out.

  22. Hi thank you for this information. I have a question for anyone who can help, I don´t know if I need to start in gathering requirement with the skeleton or backbone. For your experience which one do you recommend? or if you have more information about your experience in gathering requirement? Thanks.

  23. really helpful post, quick question. Where users can complete the same actions in multiple different ways what is the best way to map this. For example I am working on an e commerce site. Depending on how the user enters the site they will be prompted to login/sign up at different stages depending what they do. The screen they are taken to is the same in every case.

    So for instance
    User Logs in when entering website
    User enters website, makes orders, goes to Payment page and is asked to Login/Create account
    User is able to click a login link on any page they are on at any process during the transaction and on logging in will be returned to the page they where on when they decided to log in.

    How do you define these different actions on your user maps? Would you specify the logion step in each action or would you define all the places the user can login under the login action?

    Thanks for the support

  24. Hi, Steve,
    thanks for sharing your explanation of story mapping.

    I got confused though when I looked at the picture with the story map for the email client. One common criterion for user stories is that they should follow the INVEST criteria. Independence of the user stories is one of those criteria. From my point of view, in the example, the yellow user stories for Compose Email are not independent. There is no "set mail priority" before "Create basic email". So are these gooed examples for slicing user stories or not? I'm unsure here.

    1. Thanks for commenting. Here are some thoughts:

      1) INVEST is a great model for thinking about user stories but I prefer treating it as a guideline and not a rule.

      2) Regarding "Independent": Story mapping is a fantastic way to think about independence. Generally, the first thin slice of your map creates the major dependencies left to right. You need to create an email before you can read it, etc. Your first slice also creates the first dependency top to bottom. You have to complete "Create basic email" before you can build "Set email priority" or any of the other stories below that.

      In summary, story mapping helps you identify and visualize those first dependencies (that first slice) so that you can now follow the INVEST rules a little more closely.

      Hope this helps.

  25. Question - possibly a dozy one - about large, multi-year projects. We're revisiting a story map built six months ago for a three-year move to cloud while improving old legacy system project. (Similar to your 2012 discussion with Yogi, above.) We left a bunch of activities below the paper to pull in later. And now it's later.

    With limited space, as we pull some of the 2018 activities into the sheet, what to we do with the stickies representing work that's done? Don't want to lose sight of the work flow, but there's only so much space on the wall.

    We can post photos to collapse the first two releases, but there may be a more elegant way.

    We worked hard to convince them a paper board would be more meaningful, and they like the paper board. So I'm reluctant to bring in a tool at this stage. This is all (sort of) replicated in Jira, of course.

    1. Great question, thanks for asking. When I've run out of board space, I've either asked for more boards on the wall, or I've done what you did and took pictures to capture the previous releases.

      Perhaps taking your goal ("don't want to lose sight of the work flow") is something you could ask the team? They are the ones who are likely to be most invested in the solution. If you come up with something that works, please let us know!

      Thanks - Steve

  26. It is nice that you do not write about the structure of user stories but precisely describe the process of creation. Thanks!

  27. Wow that was unusual. I just wrote an extremely long comment but after I clicked submit my comment didn't show up. Grrrr... well I'm not writing all that over again. Anyway, just wanted to say fantastic post!

  28. Hello thanks for these articles about user story mapping. I have some doubts:

    - I think that Jeff Patton says that a user story map represents the journey of the user when using the product. But there may be many journeys arent there? How do you represent more than one journey in just one map?

    - If the product is composed by several bounded contexts, you have a map for each BC? or a map for the whole product and a journey has user stories from several BCs?

    Thank you.

    1. It's a similar question that Cory.Scrummaster asked above. Check out that part of the discussion and tell me what you think.

  29. awesome read, many thanks! see a lot of similar ideas to Craft approach to user story mapping

    are you familiar with those guys?

    1. I haven't, but I'm supportive of any story mapping tools :)

  30. Thanks for this.

    It was really helpful to understand the real process of story mapping and the main goal behind it.