How to properly create story maps? (user stories)

Question

I have a website that I need to build and want to properly create story maps. I am just learning how to do this so I would love a bit of help.

My setup: Users:

• admins
• customers
  • personal
  • business
    • type1
    • type2
    • type3
      1. type3 subtype1
      2. type3 subtype2
    • type4

My app needs the users to be able to: Register, Log In, Display Profile, Search, Create Posts, Manage business (admins) and so on.

I've been advised to create the story map starting with the users. But I cannot seem to understand how to start. What about starting with the "processes" like my first example?

EDIT I would also be interested in understanding if I should have one or multiple or story maps in a project? Does it makes sense to split them into different story maps? Like registration, search, and so on.

Here's what I tried so far:
or

Answer 1

TL; DR

User story mapping is about describing a narrative and creating structure for conversations, not for defining a pile of requirements.

User Mapping in Detail

User story mapping is not directly about building a Product Backlog. It is about building a narrative for your product to encourage discussions about what to build, and what the minimum viable product really looks like. Specifically, you should approach user story mapping as an exercise in describing the flow of user experience rather than getting bogged down in implementation details.

Consider this excerpt:

• Stories aren’t a written form of requirements; telling stories through collaboration with words and pictures is a mechanism that builds shared understanding.
• Stories aren’t the requirements; they’re discussions about solving problems for our organization, our customers, and our users that lead to agreements on what to build.

— Jeff Patton. User Story Mapping (Kindle Locations 477-480). O’Reilly Media, Inc..

A Worked Example

Instead of focusing on features, your story map really out to strive to tell a story about the experience of using the product. For example, you might decide to tell Jane's story:

1. Jane wants to buy an M1 Abrams tank from our web site.
2. Jane finds the tank in the catalog.
3. Jane adds the tank to her cart.
4. Jane tries to check out in one of two ways:
   • Jane checks out without registering.
   • Jane checks out with optional registration.
5. Jane creates buzz for the company when she goes on a road-rage rampage in her new tank.
6. Profit!

Once you've told Jane's story in the large, you have refining conversations about what's needed to make each piece of that story a functional slice of product.

Advice on the Emergent Mapping

Don't try to build your map up from user stories. Instead, define your narrative and build your feature list down from the narrative. This is admittedly somewhat of an art, as the story map is really an emergent property of the exercise rather than a formulaic construct.

You may find yourself shuffling stories, epics, and themes a great deal in the beginning. You might also find yourself redefining your narrative several times as a result of the conversations that story mapping is intended to trigger. That's all to be expected.

Remember, the goal is to tell a story about the product. The user stories themselves will emerge as a by-product of the storytelling process.

Answer 2

There is no real need to start with User Roles although once you start adding your high level features, you will find that more features with different needs will develop by using Roles. This can be taken further by describing the Role further with a Persona description e.g.

Casual Site Visitor -

• Visits once a month to check balance of credits only
• Not technically savvy
• only accesses features available on landing page
• often requires easy password reminders

I would personally have one story map per project otherwise you will have a problem determining priority of features BETWEEN maps but that might depend on just how big your wall is.

The best resource so far on User Story Mapping would be Jeff Paton's book: User Story Mapping: Discover the Whole Story, Build the Right Product

Answer 3

I'd recommend the following:

1) Identify all the users that enter the system. 1a) Identify which users are the most important. 2) Do a happy path process map for how each user will flow through the system. 3) Based on the process map identify the features the system needs to support. 4) Look across all your process maps and see if there is a critical feature or features that will need to be implemented to support other features. 5) Take features identified in step 4 and do a simple story map that decomposes the feature (epic) into stories. 6) Stop when you have enough features decomposed that will keep you busy implementing for the next 2-6 weeks.

If you get to step 3 and start thinking that, holy crap that is a lot of process maps, thats OK, just do the first 2-3 process maps to represent your most valuable customers/flows. Then derive your highest priority features/epics off of those maps. Then decompose from there.

The idea is to only generate partial story maps that describe the highest priority stories you want to implement short-term. You will go nuts trying to create an all encompassing story map if the system is feature rich. I'd encourage you to avoid trying to story map out the entire project since you will find that many of the features and stories will change over time as your requirements become clearer.

Answer 4

I see that you´re using storiesonboard.com (I use it too!) to create your user story map. In this tool, you must create the high levels first, and goes down to the low levels, where you have the details (or, best saying, the stories) of each functionality. Usually, a user story map starts with the user stories itself, and then you organize in high levels to get a better picture of your application. From this, you´ll be able to prioritize the funcionalities for the first release. In the storiesonboard.com, I believe you cannot work in that way, since the system requires you to begin with the high level cards, but it´s fine if you don´t get lost. Storiesonboard.com can be a great tool if your work with remote teams.

You can have cards with the business goals intended to achieve with the app to let you remember what is really important and configure the releases accordingly. You can have cards for type of users of the app too, to know the public you will dealing with and define what stories will be handled first. And, most important of all, is not writing the user stories, but understand how it should be use, and reach a state of shared understanding between you and your customer (and others people in the project). So, unless you´re creating a map for yourself, envolve and engage others stakeholders in the process.

Take a look at this link. It´s the sample of the book linked in the answer provided by @ElBauldo.

And good luck!

Answer 5

What I found to work for us is to identify/discuss personas first, take a note of them outside the map and start the map with the processes like in your first example.
Identifying personas helps thinking about tasks these people do, so you can easier map the process.

As Bruno mentioned, you can't start with the second level in StoriesOnBoard. To overcome this I just create one card on the first level and put all the second level cards under that. Later when I can group the second level cards, I create the groups on the first level and move the second level cards under them.
If it's important to see which persona does a given task (and it's not obvious), we write it in it's title: "Admin: Manage user accounts"

Answer 6

I would recommend to start high level with all the identified users and then drill down to stories for all the processes specific to each user.

In case you start with processes there might be certain scenarios where one process could work differently for different types of users. For e.g. a basic Registration process could be different for an Admin user and an external customer. In this case it makes difficult to prepare a clear story map for all the scenarios.

Here is a sample that might help you to get started

Answer 7

I think you've done pretty well for just starting out. You've identified the user activities and done a brief job of decomposing those activities into tasks of varying sizes.

As has been mentioned, Jeff Patton's User Story Mapping is the definitive source to read. It's short, laid our well, and very easy to read.

The main two things this map lacks that you should consider adding are user types and slice outcomes:

User Type who would use the app? What do they get out of it? How would they use it? What's in it for them? Come up with categories that describe each user type e.g. Band Fan, Venue Manager, Performer, Band Promoter. I haven't found a good way to accomplish this work in SoB yet.

Outcome This is the impact the chunk of work is expected to have. Once released, how this change things? For whom? You can name the slices in SoB for outcomes. For example, your first slice outcome from your example could be "Buy our Shiny Product Online." This solves a concrete problem and makes a good candidate for a slice. Remember to work hard with Developers to craft slices that are as thin as possible e.g. buy product without creating account as "guest"

Did that help?