By Corrie Kwan, Eric Morrow, and John Murray | Hybrid Cloud Design @ IBM
In part one of our series we introduced you to user story mapping in general and in practice at IBM, and now you probably want to try it yourself, right? Great!
If you haven’t read part one or you want a quick TLDR; of the article below, watch the summary video.
Let’s talk about how to run a working session with your team.
User story mapping is great because you can run it as a standalone session or work it into a broader workshop as well. In this article I’m combining it with a hills workshop for two reasons:
At IBM, hills workshops are regarded as highly collaborative so introducing user story mapping to first-time participants has a smoother buy-in process when it’s worked into something that folks already know.
User story mapping connects design thinking and user-centered design research to agile development. Combining user story mapping with other product planning work reinforces that idea.
There are three parts to a user story mapping working session: pre, during and post-workshop. Nothing earth-shattering so far, but as we talk about each phase you’ll see that there is more than meets the eye. So let’s get cracking!
Pre-work
The common misconception with workshops is that you bring the group together and all the work is done during the workshop. In my experience, nearly half the work is done in the “pre-work” section. Your pre-workshop mantra should be “measure twice, cut once.” First-timers, you’ll need to do a little extra leg work as well by reaching out to stakeholders to get buy-in so we’ll start there.
Stakeholder buy-in
When you decide to do user story mapping for the first time, reach out to key stakeholders before the session. Not only does this help get them interested and excited to participate, but it creates allies who will come to the session wanting the activity to succeed.
The beauty of user story mapping is that you don’t have to come to it with concrete hills, only concrete users.
At IBM, we run workshops with colleagues from our three main disciplines: design, engineering and product management. Before the workshop I make sure to meet with at least one key stakeholder from each discipline. I focus on talking to the lead offering manager, who is usually the product owner and product manager; a development lead, who typically has a birds eye view of the development tasks and backlog; and the design lead or lead researcher, who understands the intended end-user experience.
The proposal and the demo
I recommend breaking up the introduction process into two separate, short sessions. The initial meeting should be for introducing user story mapping and explaining the value and outcomes you hope to provide the team.
If all goes well, which it usually does, the second meeting is where you get the stakeholder to try their hand at creating a user story map. If they create something during that session that you can use in the workshop, then great; but the real goal is to make them comfortable with the exercise. Take the user story map that each stakeholder does and show it to each subsequent stakeholder. Not only does it prove how accessible the process is, but it allows you to build on what other team members have created, which highlights the value of user story mapping’s iterative process.
Come prepared
Alright so you’ve rallied the troops, and everyone is sold on the mission and ready to come to your workshop. Let’s continue our pre-workshop preparations. It might sound like common sense, but the user is at the heart of user-centered design. With that in mind you should always come to a user story mapping session knowing who your user is.
Don’t let stakeholders bring in any potential users that haven’t been validated through research. For you business leads out there, we’re not here to hypothesize about unexplored market segments. If you allow stakeholders to mix unvalidated personas into the group’s work you’re going to get off track. I guarantee it! The group will get sidetracked arguing about the value, context and impact of this new, unvalidated user when they should be focused on the real users they know exist and know they want to reach.
If a new, potential user arises from the working session, make note of them, their possible needs and characteristics and let your researcher validate them after the session is over.
Before you come to the workshop, your stakeholders have three responsibilities:
- Know the user — develop a validated persona
- Know what the user is experiencing — define the as-is scenario
- Know what you want to do for the user — draft a set of hills
Know the user
Most design teams at IBM have a design researcher who focuses on identifying a user, learning their wants and needs and relaying that to the rest of the product team so they can create a quality product. If the team you’re working with has background information about your target user, then use that to generate a persona. There are any number of different ways to create a persona. In the studio we focus on what the user “says”, “does”, “thinks”, and “feels”.
However you generate your persona, the number one rule is to make sure it’s grounded in facts and backed by real user quotes, interviews and feedbacks. If you’re creating a persona but not validating it, then you’re projecting your biases onto your user, and that doesn’t do anyone any good. If your team doesn’t have a persona, then that’s okay. You can create an empathy map, then take it out and validate it.
Empathy Map
Building an empathy map is a great pre-workshop level-setting activity. If everyone knows the user then you can quickly create this artifact and move on, but doing an empathy map before the workshop is a great way to bring assumptions or hidden biases to light. The sooner these assumptions surface the sooner you can discuss, assess, and make plans to validate them.
Know what the user is experiencing
You can’t make life better for your user if you don’t know what the pain points and highlights of their experience with your product are. Before the workshop ask stakeholders to map out the current user experience, warts and all. When you have representatives from all areas of the product involved in the process, you end up with a more well-rounded perspective of the product experience in its current state.
At IBM we use an activity called the As-is Scenario to see what the user is experiencing. We focus on what the user is “doing”, “thinking”, and “feeling” throughout the process. It might help to label steps of the process so that stakeholders have a starting point. Some teams simply dive in and create an end-to-end as-is scenario like you see below.
Know what you want to do for the user
So far you know who your user is and what their pain points are. Now how are you going to make things better for them?
You have a few options. Think small and focus on the user by creating needs statements. Think outside the box by creating big idea vignettes to spark innovation on your team. You could also write mission statements for your release. At IBM, we call them hills. You would be right to choose any of the three techniques, but for this article I’m choosing to focus on hills and here’s why:
User needs statements are quite similar to hills but sometimes stakeholders do better by not focusing on that level of granularity too soon. At times writing dozens of user needs statements can be overwhelming and throw the team off course.
Big idea vignettes are fun and helpful because they let people’s imaginations run free. Writing hills before doing big ideas can keep your team’s innovation grounded in feasibility.
At IBM, hills have three key elements, “WHO”, a specific user; “what”, a specific action or enablement; and a “wow”, a measurable market differentiator.
Let’s look at an example:
If your team doesn’t feel confident about its hills or it doesn’t have any, then set up a hills session. The more concrete the hills are the more time you’ll have for mapping out user stories, but don’t obsess over crafting the perfect hills before the workshop. Take your best shot and come into the session willing to refine them.
Get a facilitator
The last part of the pre-work but something that shouldn’t be taken for granted: getting a facilitator. Get an objective third-party to facilitate your team’s workshop. Here’s why:
You need to be contributing to the workshop. If you’re spending all your time facilitating your own team’s workshop, then you won’t be able to contribute as an active stakeholder so your team is now short-handed.
You can’t maintain the necessary level of objectivity. There’s such a thing as being too close to the source material, and it’s simply not possible to be an impartial arbiter of workshop discussion when you’re an invested stakeholder.
You can’t unsee what you’ve seen. When you bring in someone who’s never heard any of this stuff before, you’re likely to get a new set of questions from a fresh set of eyes, and that’s not something you as a product team member can bring to the table.
Finally, when you’re asking someone who’s not on your team to facilitate, make sure they are familiar with the overall business objectives, market segments, and users of your product. Show them your persona, as-is and hills artifacts beforehand so they can come prepared. Also, let them know about the personalities in the room. It always helps to know who is likely to dominate the conversation or who is likely to derail the session.
During the workshop
At this point you’ve done all your pre-work, and now you’re ready to get the rest of your team together. In this section I’ll be sharing specific examples from a workshop I ran with an IBM team. Showing real work is a great way to explain the process.
Ice breaker
It helps to ease into the workshop with a fun activity. Don’t overthink it. Just pick something to get people loosened up and in the right frame of mind. For remote sessions, we sometimes have participants caption a funny picture. For in-person sessions we like to do Rock, Paper, Scissors.
Hills revisited
The beauty of user story mapping is that you don’t have to come to it with concrete hills, only concrete users. Even if you get to a workshop and find out you need to focus on a different user, that’s okay. User story mapping’s iterative process ensures that once you solve your user dilemma and create hills you won’t ever feel like you’re working on “the wrong hill”.
As you create user stories you can go back and refine your hills and as hills become more concrete you can go back and clean up your user stories. It’s as if you’re calibrating lenses, and as one lens becomes clearer you tweak the others to bring things further into focus.
In this example we asked the IBM product team to take a second pass at the hills they wrote before the workshop.
You can see from the screenshot that the team wrote five lengthy hills. After a second pass they focused on the “c-suite executive” persona and wrote a hill that they felt good about. However, keep in mind that writing a well-crafted hill is only half the battle and there should always be honest discussion around a hill’s potential impact and value.
When it came time to critique this hill, the team didn’t think the “c-suite executive” was the real end user, and they decided to focus on a different user. That’s okay! It is better to pivot now than to build a product for a user that might not exist or build a product that a user might not have any interest in buying. The team decided to focus on a DevOps transformation engineer. Let’s take a look at what they wrote.
Early iterations of your hill will normally sound unpolished. Don’t let that distract you. You can fix the wording later. Stay focused on the hill’s intent. With the hill written, everyone is aligned on the user and what they want to do for the user. Let’s add more detail by creating a to-be scenario.
To-be scenario and user story mapping
Earlier I introduced the as-is scenario. It’s commonly used as a diagnostic tool to identify a user’s pain points. Now we’re going to talk about the as-is scenario’s sibling, the to-be scenario. If the as-is intends to tell us what the user’s experience is like today, then the to-be tells us what the user’s experience will be like after we deliver on our hill or mission statement.
The to-be scenario is a linear process. To get the team headed in the right direction I like to have them label the steps in the user’s journey from start to finish. With our steps laid out, it’s time for user story mapping.
Build the map by asking “what does the user need to do in order to complete this step?” Those become the epics. Below the epics, we will ask “what activities does the user need to do to complete the epics” and “what tasks do they need to finish to complete those activities?” Before you know it, we’ve begun to build out our user story map. Also, we’re starting to lace together the roots of what will later be called the “golden thread”.
Now I know all of you user story purists out there are saying “shouldn’t the user stories the team is writing have a more structured syntax than what I see on these pink notes?” That’s a good question, and many of you are probably used to seeing user stories written something like this:
As a < type of user >, I want < some goal > so that < some reason >.
We prefer to follow Jeff Patton’s advice, the author of User Story Mapping. He said “stories get their name from how they’re supposed to be used, not from what you’re trying to write down.” In other words, focus on the story you’re trying to tell and less on the specific syntax.
Hills, version three
Let’s continue refining our hill from earlier by asking the team a simple question: “Knowing what we know from the to-be scenario and user stories, what do we need to change about our hill?”
Between this hill and the previous version you’ll notice that the team felt confident enough to name their DevOps engineer. They added language to the “what”, and elaborated on the “wow” as well.
Now we have a user and a hill that everyone agrees on! With a rough but steady foundation, let’s go ahead and clean up the language to see if we can improve the hill’s meaning.
Ask the team to dissect the hill and label the “who”, “what” and “wow”. You’d be surprised how much a team gets out of dissecting a hill into its requisite parts. Lately, my colleague and I have been experimenting with adding “why” to the hills writing process. Plainly speaking, “why” means just that — why would the user want to do this or need this? It’s easy to want to put all the impact of a hill in the “wow” without stopping to think why a user would be compelled to do it in the first place.
Now that we have the crux of the hill figured out, let’s revisit our to-be scenario and user stories one more time.
To-be scenario and user stories revisited
Before we settle on the final language for our hill we should take a look back at our to-be scenario for one important reason: a hill is supposed to be completed within the given release cycle. If we write hills that aren’t scoped tightly enough then we’ll never achieve all that we set out to do. So to be certain that our hill covers work we know we can achieve in this release, we need to take another look at the user stories attached to our to-be scenario.
You’ll remember that the team originally came up with the following to-be scenario and user stories.
Try as we might, we’ll never be able to accomplish all this work in one release, and that’s okay. Ask the team to prioritize the most important and most valuable user stories. In a little bit we’ll take those high-priority user stories, shown in yellow, and use them to create something called the “golden thread”, which is intended to be a marriage of executive intent, strategy and innovation.
Final hills
With the most important user stories from our to-be scenario selected let’s nail down this hill once and for all. Again we ask ourselves “knowing what we know from the to-be scenario and user stories, what do we need to change about our hill?”
“We need to split the hill in two. Too much meaning gets lost if we just leave it as-is,” the IBM product team said.
At IBM, we suggest creating three hills for every release, but that’s merely a rule-of-thumb. It’s more important to have quality over quantity in this case. Here’s what our IBM team wrote:
Even though this team had one hill to start, they felt more confident about delivering on it by splitting into two. You can see that at their core these hills have separate objectives. No wonder we broke up the original hill. With our hills complete, let’s look at the golden thread we started earlier and then call it a day.
The Golden Thread and Beyond
As a summation of the day’s work and the user story mapping we did we asked the team to create a draft of the golden thread. The Golden Thread winds its way through the user stories and describes one specific, end-to-end experience, that is part of the new to-be scenario. The purpose of the Golden Thread is to prioritize what development will deliver first, with the specific intent that research will validate it with the user after the workshop. The process of validation will help the team decide what user stories to prioritize for the next development sprint. The IBM team created the following Golden Thread for Dwight.
Before we go any further let’s recap. So far we have:
- A validated user
- An established user journey with diagnosed pain points
- A best-case to-be scenario that proposes solutions to said pain points
- Refined hills, or mission statements, describing what value we’re bringing to the user in this release
- Epics detailing how we will climb the hill
- User stories telling us how we will complete the epics
- A draft of the Golden Thread that the team can put in front of users and validate
All in all that’s a good day’s work for any product team! I know it seems like a lot to cover and it was, but the IBM product team that did this work completed it in under four hours. They walked away with a greater understanding of the work they were agreeing to complete and a shared understanding of the user outcomes they wanted to achieve. In the end, that’s what it’s all about.
Post workshop
You’ve done the pre-work and your workshop was a success, but you’re not quite done. First, you need to show sponsor users your Golden Thread to see if it resonates with them. Second, from a development perspective, epics and user stories need to be created in whatever project management tool your team uses, such as Github. UX designers can probably start to create low-fidelity wireframes as well and put that in front of users.
The IBM team’s users rated the Golden Thread’s users stories from one to five with five being the most important.
Long-term Outcomes
It’s usually not until a team has gone all the way through the user story mapping process that they realize what they’ve been missing. While the team is excited and feeling good about the shared understanding they now have, take the opportunity to implement a more efficient UX process for your team.
I tell stakeholders, “if you like this, then don’t let it be a one-time thing.”
For user story mapping to work, the product team has to allow the user research to be done. If you don’t make user research a priority, you’ll never get out the gate. That means release cycles need to account for user experience ideation. Development can still continuously release, but design needs to be working at least one iteration ahead of development.
In the case of our IBM product team, we caught up with them a couple of weeks after the workshop to see how things were going. They showed us a timeline that revealed design and research were now doing their work in advance of development. The agile workflow was smoother because there were no more bottlenecks where development was waiting for design deliverables. Everything was on a schedule, and everything was connected to a corresponding user story, epic and hill!
Putting it all together
At the end of the day it’s not about what you write on Post-Its, it’s about aligning the team around the work they’re trying to deliver. Before we call it a day, let’s take a look at how everything fits together.
In the graphic below, you see that every release begins with a product strategy & discovery phase. This is where the bulk of the user research occurs. For teams like we talked about in this article, user story mapping-based hills workshops can help a team deliver the bulk of what’s needed to create a successful product release.
At a minimum, I’d ask any team seeking to implement this process to require three things: validated personas, a mapped out end-to-end as-is scenario, and a rough draft of hills.
I can’t tell you how many workshops my colleague, Eric, and I have seen where teams skimped on one of those three things and it ended up coming back to haunt them. If those three artifacts are created and the team is aligned around them, I guarantee you will have a successful experience.
One final thing to keep in mind: hills in the graphic below look as though they’re completed sequentially, however, in reality that’s not always the case. Most of the teams I’ve been on had work from one or more hills happening concurrently. Don’t feel like you need to tackle the first hill before you move on to the next one. It’d be nice if product development was that simple, but it’s not.
Given all that we’ve covered in this two-part series you should have the tools you need to connect user research to development tasks using design thinking. If you have further questions or comments about anything you’ve read, please feel free to reach out to me. Good luck!
If you have further questions or comments about anything you’ve read, please feel free to reach out to me. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
Thanks to Eric Morrow.
Note: Thanks to Corrie Kwan, Eric Morrow, and John Murray for contributing to our blog with this article