Aligning Organizational Stakeholders With User Story Mapping

Tobias Jensen at UXDX Europe. Video: https://youtu.be/lRRYfAQ5A_M

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and Blackboard Insurance

[00:00:01] Hi, everyone. My name is Tobias, or "Tobias" as you would say it in Danish. I live in New York City; I've lived there for the past two years. With my background of working for the government and on apps and websites, I'm a person who's constantly trying to think about how we can use design as a discipline to change really complex stuff out there in the world. Story mapping has become one of my favorite tools to use, because I've found that story mapping not only helps align people and get them on the same page about what you're building and why you're building it. It also achieves an alignment across the entire organization on what it is that we want to do.

[00:01:01] Before I get started, I want to know a little bit about you guys as well. Who has ever heard of user story mapping? Okay, that's great, awesome. Who's ever used user story mapping? And who's used it successfully? Okay, we narrowed in a little bit. I won't say that I've always used it successfully, but hopefully I can give you some tips on how to use it in different phases of the project to make it a more successful tool throughout the product development process.

[00:01:50] A little bit about me first. I'm Tobias, and I work in New York City as a product designer. I guess we just went over this slide, actually. I try to use design thinking to solve these common problems out there and figure out how we can create valuable experiences for people. This leads me to the next slide, which is why I work for this company called Blackboard Insurance. This is probably one of the least known companies of all the speakers at this conference. It's also a very new company; it's about a year and a half old now.

[00:02:30] We work on insurance. We are one of those insurtech companies. We're trying to see if there's any way we can rethink or reimagine the super, super archaic industry of insurance. We try to do that with a customer-value and data-centric approach, meaning: is there a new way we can look at insurance so that we make it interesting for people, maybe even a good experience, and maybe less boring?

[00:03:00] Insurance is an industry that has the reputation not only of being boring and tedious for people. It's also an industry that has absolutely no trust. You don't ask a person and hear, "Oh yeah, I love my insurance company. They only do whatever is best for me." There's always this mistrust of the insurance company trying to rip you off and make more money off you. So this is our mission: we want to get this asymmetry out of the picture and see if we can make insurance more available for everyone.

[00:03:40] Story mapping is going to be part of that. As I said before, I've found story mapping to be a super useful tool for aligning everyone in your organization on what you're building and why you're building it. I'm going to go over why I think user story mapping is needed now. I'm going to give a quick introduction to the problem we see with the current way we build software. Then I'm going to go over what user story mapping is, and then how we can actually apply it in our own organizations.

Building software is like the telephone game

[00:04:20] Before I get started, has anyone seen this video, just by looking at this frame? Does everyone recognize this video? I guess you didn't raise your hands. Okay. Have you seen it on LinkedIn? This is a video of the classic game called the telephone game. We have a few people here who are not from the US or an English-speaking country, so does everyone know what the telephone game is? I'm just going to go over it quickly.

[00:04:49] The basic rules of the telephone game are that you sit down with a group, and the first person starts saying something, or enacting something, or maybe even drawing something. Then they pass that on to the next person in line, and that person is supposed to say or draw or do whatever they just saw. Then that is passed on to the next one in line, and the next one, and the next one, and eventually, after maybe eight people, you compare the result after the message has gone through all these people with what was there in the beginning.

[00:05:31] This is an example of that, so let me just show the video. In this video, the guy with the ball does an action, and then he shows it to the person next to him, who then shows the next one. Let me show that video first.

[00:06:01] I sped up the video. It's 12 minutes long, and I wanted to spend more time talking about story mapping. Everyone does the thing they see from the person before them. It's a very long line of people, and here's the end result. So if you all line up right here now... I'm kidding.

[00:06:31] This is all fun and games. It's funny, it's hilarious. We can definitely see why it doesn't really work. Even though the guy in the beginning was very elaborate (I've never seen anyone drive a scooter like this), and he was really trying to exaggerate what he was doing, there's still this big difference between what was started and what was seen in the end.

[00:07:01] Why am I showing you guys this? Why am I talking about the telephone game and about people misunderstanding each other? The reason is that most often, when you build software, it can feel like the telephone game. I'm not sure if anyone would agree with me at this point, so let me try to make it a little bit clearer. We write these documents (I'll go over the document format afterwards), then we pass them on to someone else, and we expect that person to read the document exactly how we intended it. We write the document and say, "Here, this is what I want," and then we expect that person to know exactly why we wrote it and what its purpose is.

[00:07:49] Then that person will look at it and say, "Oh, that person wrote it because of this," and they'll pass it on to the next person. Eventually you get to a point where it's not a video of drawn [?] people doing this anymore. It's actually real-world software development, where people don't really get the idea of why we are doing stuff.

[00:08:12] Most often we get to a point where, and maybe you guys have also seen this before, we're both standing here looking at the same thing on the ground, but one person says, "Oh no, that's a six. I'm definitely looking at a six." Another person says, "I'm looking at a nine." I was also thinking about bringing in the dress example, of people believing it's gold and white or black and blue. But the idea is that when people look at something, they have their own perspective. They have their own idea of what they're looking at. Just because you share a document, just because you share something, doesn't mean that people actually understand the things you're sharing with them.

The problem with written user stories and flat backlogs

[00:09:07] This is the document I'm talking about. I'm sure most of you are hopefully familiar with this format. For the people who are not used to seeing it, this is called a user story. It's a classic format, the most used out there right now. I wouldn't say it's the only one; there are a lot of different variations. It goes like this: as some kind of persona, I want to do something, so that I can do something. As a persona, I want to be able to get something done, so I can accomplish this task. I have this goal in mind.

[00:09:56] The reason this came about was that we needed a better way to think of features from a user perspective. Suddenly you frame a feature from a user's perspective. So what's wrong with this? There shouldn't be anything wrong. Well, if you get a user story like this, the idea gets completely lost. I'm not sure if you can see this, but I'm going to read it aloud: "As an admin, I want to filter users by their job title, so I can filter users by their job title." This is basically a snake biting its own tail. You don't really explain anything. You just say, "I want this feature because I want the feature."

[00:10:47] This is where you eventually get to the point where, if I pass this on, even though I, as the designer or PM or someone else, know why we want to filter users by job title, because I couldn't formulate in the "why" section why that's important, someone else won't be able to understand it. I shouldn't expect someone else to look at it and say, "Oh yeah, I know exactly why they want to filter by job title."

[00:11:13] Even worse is if you put it in a format like this, which I'm also sure most of you have seen before, where you basically just list out all these features or user stories and divide them up into chunks. You get to a point where I have questions like: what are we actually trying to accomplish here? What should the system do for the user? Why in this particular order? What's important about this order? How do things relate to each other? Why do we put this here? Is it related to that one up there? It gets super hard to even understand why we are building this.

[00:11:57] I'm not sure if you share the same frustration. And it's even worse when you have something at the bottom of the backlog where you just throw all the cool stuff, but you're never going to do it, because you don't really know how or why it's going to fit in. The problem is there is no real clear vision.

[00:12:16] It goes all the way back to what we should actually use a user story for. Jeff Patton says in his book, User Story Mapping, that the real value of stories isn't what's written down on the card; it comes from what we learn when we tell the story. This is exactly what we need to be better at. When we talk about user stories, we need to go back to basics and say: this is a story. It's not a different way of writing a requirement. This is actually a story about a user, and we need to be able to tell this story to get people to understand it.

[00:12:55] Another point I want to make is that stories don't become stories until they're told by someone. So we shouldn't expect that when we write something down on a piece of paper, someone will be able to understand that story. Eventually we want to get to a point where we can look at the same thing and have a shared understanding of what it is we're looking at. We want to be at a point where there's no real argument about what we're looking at. We all agree. Maybe these guys are still yelling, but maybe they're yelling because they're so happy they agree. We want to get to this point of pointing at the same thing and seeing the same thing.

What a user story map is

[00:13:36] So how do we do that? This book is, I wouldn't call it my bible, but it's definitely my go-to book when I struggle to figure out how to integrate my UX work into development processes. It's written by Jeff Patton, and also Peter Economy, but Jeff Patton gets all the credit. In his book from 2014, he talks about story mapping and why he thinks it's super important. I'm not going to go too much into this book. I just want to say that if you haven't read it, please read it. A lot of people said they had read it, but if you haven't, do it.

[00:14:13] In his book he talks about a story map. What is a story map? A story map is a tool to foster conversation between people in your organization. It's a map. It's a way of taking what you would call a big story, like me going to a conference to speak, which is super large, and breaking that story into smaller parts. Later on I'm going to use that example to show you how important it is to think about the bigger picture first, think about the bigger story, and then break it into smaller pieces as you get more detailed.

[00:14:55] By having people look at features, story maps and user stories this way, you get a shared mental model. Look at these three people: they're all looking at the same thing, they're all talking about the same thing, and it's all grounded in the user's journey. It says steps and details. The steps are the steps of the journey, and then you have the details, which specify what happens within each step.

[00:15:30] Let me go on to the next slide, which is blank, and go through the anatomy of a user story map. A user story map will always look at the persona involved in the story. In the conference example, I would be a persona in this story. Maybe also the conference organizers would be people involved, and maybe the other speakers at this conference would also be involved in this process.

[00:16:07] Then you want to map out the activities that these people go through along the entire story. Again, my story was: I go to a conference and I want to speak on a stage. The activities before this might be getting to the location, in this case Dublin. I have to take an airplane to Dublin. I also have to get a hotel room. I also have to go to the venue, and when I get to the venue with the stage, I have to make sure I get a badge so I can show people that I'm a speaker, and so on and so forth. You have all these activities that define this story.

[00:16:45] Then within these activities you have your tasks. What are the tasks that a user or persona would have to go through to complete these activities? They're more granular, within the activity. And this is where it gets interesting. This is where you start defining your stories. I call them stories, even though the whole thing is a story, but essentially this is what you would call a user story. You get to a point where you have all these tasks. This is the journey you want the user to take. What are the possibilities for the user in each step?

[00:17:23] You see I have multiple yellow ones under one task. That means this would be open, free thinking, brainstorming about how we could, in the best way possible, enable this user to complete this step. This list could be super long. Eventually you're going to have to define what the release is, what we define as the MVP for this solution, and then you're going to slice that map up into more and more releases so you can start figuring out how to prioritize. You look at some stories and say, "Oh, this story is actually super cool, but let's wait with it until later, because what we need now is whatever X."

Defining a viable MVP

[00:18:14] The user story map is super simple. I primarily use it for facilitating workshops. I use it for development processes; I'll go into that later. But the most important thing here is defining what viable means. I'm sure a lot of you have heard this conversation about MVPs: what defines an MVP? Should an MVP be crappier? Should an MVP be the most viable for the business?

[00:18:48] The truth is, in this case, I would recommend that when you define the viability and effort of an MVP in a story map, you always, always go back to what it is that we want to build to understand if we've helped the user accomplish their goals. It's always focusing on what the user is trying to accomplish and how, with each release, we can help the user accomplish those things.

[00:19:15] One more thing I wanted to mention about a minimum viable product is that both "minimum" and "viable" are subjective words. It's someone valuing, "Oh, this is the minimum we need," or "This is the most viable." But until you get to a shared understanding of what you're trying to accomplish, you won't be able to settle on an MVP. That's most often why so many different people have their own idea of what an MVP would be: no one has really looked at something like this and said, "Oh, this is what we need. There's no need to discuss it anymore, because now we know this is what we need for the user to be able to complete their task, or their entire story."

[00:20:00] The key to remember here is that it's all about hypotheses. It's all about how we get this going as fast as possible so we can validate the hypotheses we set up about our users.

Benefits of story mapping

[00:20:17] I'm just going to quickly go over some story mapping benefits. First of all, the operations aspect. By mapping out all the possible solutions for how to enable users to go through these steps, you get to a point where you can prioritize super well. By mapping it out, you can say, "Oh well, this release would be super awesome, but let's wait, because it's not going to be table stakes for the users to be able to get through." You can plan releases. You can even start showing roadmaps and arguing for roadmaps. If you have the entire journey of a user mapped out, with all the different possibilities, and you've settled on those, then you should be able to show the roadmap for your organization as well.

[00:21:07] The second one is that you get people to communicate, which is super hard. You get people from all different backgrounds to come in and share an understanding of what they're looking at. You have a map that enables people to look at it and say, "Oh yeah, I get now why this technology is super important." This is something you don't get that often. You don't often get people to look at something and say, "Oh, I understand why we need this."

[00:21:37] The third one is that it makes you think in outcomes. By having this map of what you want the users to accomplish, and by having the user journey in mind, you think about the outcomes you want to accomplish and how you want to get there. Going back to the hypothesis idea, you want to put up hypotheses for how to reach this outcome, or how to enable the user to reach this outcome, and what outputs you have to deliver to get the user to that outcome. I wouldn't say it's a matter of outcome versus output. It's a matter of forcing yourself not to think about these features as isolated chunks of work, but to think about them more in the holistic view of how we actually enable the user to accomplish something.

[00:22:33] The last one, which I think is super important, is proactiveness. As a designer, you can get to a point where you react a lot. You react to what you're seeing, you react to problems, and you get into this problem-solving mode where everything has to be a problem for you to be able to solve it. By mapping out a user journey and understanding what you want to accomplish in that journey, you get to be a lot more proactive. Of course, a lot of what you're mapping out is going to be reactive to what you're seeing, but proactiveness means: "Oh, look at all these opportunities we have to enable the user to do something. Let's do it. Let's start mapping it out." Then you get into a mindset of using design and product development as more of a proactive practice than a reactive one.

Using story maps across the product process

[00:23:26] Just like John before, I'm going to use the model from UXDX here. We all know that we have a thousand different models for how to carry out product development, but I'm just going to use this one so everyone is on the same page. What I want to talk about is that user story mapping can be used at any phase in the process. In Jeff Patton's book, which I totally agree with, he puts a lot of emphasis on the development piece. He talks a lot about why it's important to look at user stories in the backlog more in a journey format. What I say is that it's super important to use story mapping throughout the entire process.

[00:24:14] Even for research, I use user story mapping as the first piece every time I start a project, because by using user story mapping and its format for facilitation, I get everyone on the same page in the beginning. I'm not talking about products. I'm not talking about technology. I'm talking about what the user journey is and what we need to understand to be able to design for it. Even when you start getting findings from your user research, you can start iterating on the map and filling it out: "Oh, now we know even more. There's another step in the journey that we didn't know about before." You can also understand the knowledge gaps you have right now, the aspects of the user journey where you have absolutely no idea what you're designing for while you're designing for it. So I would highly recommend always using user story mapping from the beginning.

[00:25:11] The next step is the hypothesis step. As I said before, hypotheses are super important for understanding what the MVP is that we want to test or validate. By formulating hypotheses from a user story map, by being able to say, "We think this is going to happen after this," you can, per release, start testing and validating these hypotheses even before you get to anything related to software.

[00:25:41] Which brings me to the next point: prototyping. Since I am a designer, I use user story mapping for my design process as well. Personally, there's nothing better than being able to see, "Oh, this is what the user wants to accomplish, this is how I'm going to design the flow." So why not use it in that process? I always make sure that whatever user story mapping work I've done before, and whatever insights we got from the other phases, is fed directly into my design process. I look at the user story map and I say, "Oh, this is the MVP. This is what I can start designing for, and this is what we can even validate before we have anything built."

[00:26:23] I'm just going to cover the blue and light blue phases of this process. When you get to the build, test and release phases, this is where it becomes crucial. I've used it for my agile ceremonies, where suddenly the developers at grooming sessions and developers at planning understand why we're doing stuff. If you can say, "We're at this step in the process, and now we want the users to be able to do this," they won't have questions like "Why are we doing this? Why is this important? This seems unnecessary. This seems like a lot of work for nothing." Suddenly you can tie everything back to the user journey and say, "This is why we need it, this is why it's important, this is why we're putting in the spend at this time."

[00:27:18] It's also really good for release planning. If you want more of a narrative in the way you set up releases and deliver features, use the story map. The user story map will tell you exactly what you want to accomplish per release, so when you deliver it you can say, "These are the features we are actually building for the user, and this is the value they're going to provide."

Tools and takeaways

[00:27:43] A few last things I wanted to talk about: how to do it. I would always recommend using pens and Post-its if you are co-located, if you have everyone there. I would always recommend using it for workshops where you can start mapping out the entire user journey. The reason is that when you have a room to stand in, communication becomes less of a problem or an obstacle than it is over a phone or a Skype call or whatever you're using. So always bring everyone into one room physically if you can, because that will force them to have better conversations and get to a shared understanding.

[00:28:32] If you can't do that, which I totally understand, tools like Mural or Miro are really good at letting you keep an overview of the diagram, the story map, that you're creating. You can also see people's cursors, where they are, and you can vote on stuff. It's super easy to use. I've used that successfully many times as well.

[00:29:02] Once you start going into the development process, I'm not sure if you're familiar with this tool, but Easy Agile for Jira is actually really awesome, in the sense that it doesn't disrupt your normal workflow. You have your normal backlog, and everything looks normal, but now you have an extra tab, which is the user story map. You can move tickets around and do whatever you want in the Easy Agile tab, but it won't mess up your normal backlog or your sprint. So if you just want to test it out, I can highly recommend the Easy Agile plugin.

[00:29:39] If you're curious about doing a workshop, which I also talked about, you can look up this title on Medium. I have a guide for how to carry out, I think it's a half-day workshop, on user story mapping: which people to include, what activities you can do, how to divide up the time, and so on and so forth.

[00:30:03] Before I end this talk, I'm going to finish with a quote, and then I have some takeaways as well. Jeff Patton says, again in this book, "Teams must build a shared understanding and focus on outcomes rather than what to build for their users." The key here is to focus on getting a shared understanding of what you want to achieve, and not just what you want to build. Instead of focusing on "we need this feature and this feature," think about what it is you actually want to accomplish and how these features fit into that.

[00:30:34] I'm going to do my key takeaways briefly. The first one: don't expect people to fully understand your written requirements. When you leave this talk and have your lunch, think about the next time you write a user story. Don't expect anyone to look at it and understand exactly what the person meant. The second one: flat backlogs don't show the big picture, so don't expect people to understand the big picture if you use a flat backlog. Third: collaborate early to achieve shared understanding. That means everyone in the process: developers, other subject matter experts, even users. Try to pull them in as soon as possible to get a shared understanding of what you're building and why you're building it. And the last one: start telling stories, don't just write them. That was my talk.