10

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: enter image description here
or
enter image description here

  • What problem are you trying to solve by creating the story map? What value does the story map exercise provide in your ability to start development of the website you mention? – WBW Aug 5 '15 at 23:06
  • Starting from users, i believe, is just a guidance as it helps you concentrate on the problems that you would solve from the end-users perspective (similar to personas). – Nikhil Gupta Aug 6 '15 at 8:11
  • @WBW I think I need the story map for the following reasons: I want to have an overview of what needs to be done, I want to be able to monitor progress, I want to have multiple releases with the first one containing only the necessary things that make it work, I want to prioritize things based on what is needed most quickly, in the case I am unable to finish it I want to provide an easier transition to the next person(s) taking the project. I have previously started the development(coding) of this project and was forced to stop and rethink a lot of my work. That was done with little planning. – Cristian Aug 6 '15 at 13:29
  • 2
    User Stories Applied- Mike Cohn and User Story Mapping- Jeff Patton are the two books that cover this all. They are the books all agilists reach for when learning how to do this. Anything I can provide would be a poor start to just tell you "Go Buy These!" – Joel Bancroft-Connors Aug 6 '15 at 20:28
  • It's hard to tell what you're really asking. Are you trying to figure out how to do breakdowns in a particular tool, or are you asking for help decomposing stories, or what? No one else can write your features for you, and you'll need to articulate your core question better if you're asking something else. – Todd A. Jacobs Sep 24 '15 at 18:19
3

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.

  • Gotta say. This answer just made it clearer on how to think about user stories. However, the facts that I should not consider them as requirements kinda throws me off a bit. Is there something I am missing? How or where should the requirements be placed? – Cristian Oct 30 '15 at 17:54
  • @Cristian You don't. Requirements documents are never part of a user story within an agile process. User stories describe features within a context; implementation details are left to the discretion of the development team. Always think "what," not "how." – Todd A. Jacobs Oct 31 '15 at 15:30
  • To extend your great example: give Jane a persona e.g. because she is the rampaging type, she checks out without registering. Then create another persona for a different path to profit e.g. Peter is the type of person who registers on the site using his Google account and creates buzz for the company by raving about his tank on social media. – onedaywhen Jul 29 '17 at 11:02
0

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.

0

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

0

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!

0

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"

0

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 Sample Story Map

  • So far the two approaches that i found are the one you propose starting from users or the one starting from actions. My issue with starting from users is that i have many actions that are shared by users and I will have to keep repeating myself. My issue with the other approach is that if I start with actions I will not see well that big picture of users. – Cristian Sep 30 '15 at 11:30
  • At some point I assume that the repetition would help you have a complete big picture for all the scenarios of your project. In turn it can help to identify all the common modules & the conditions which can help you a lot in further planning – Surbhi Mahnot Sep 30 '15 at 12:06
0

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?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.