User Story Mapping - Overview Outline

User Story Mapping
By Mo Goltz
Intro - User Centered Design
● What is user centered design
● The user is understood first
● The user is our primary focus
● User understanding is the foundation all other consideration
● The user’s experience is at the core of decision making
● Why is being user centered important
● Thinking of the user first reduces risk and improves quality by focusing on
creating the right things before making them in the right way. It's surprising how
many companies have this process backwards.
● first on who to build product for, then on what are the right things to be c
● Given the choice between two products (or services) of roughly equivalent
functionality, most people would choose the one that is designed better (for
them). Over time, poorly designed products fail, where well designed products
become popular and widely used to help people improve their lives in some way.
● It's easy and natural when trying to create new or improved product to think
primarily about that product. However the most useful, enjoyable, and successful
products start with a focus on the user: Who wants or would benefit from using
this product? What problems are we solving for them or what goals are we
helping them accomplish? When and where will this product be experienced?
Answering these questions early helps creates a conceptual framework that in
turn helps guide critical thinking and decision making.
● Great designers begin by crafting stories that show how customers
interact with a product, and only after they’ve accomplished that, do they
design screens as a way to tell that story of interaction. A design process
that begins with screens will not create a cohesive flow between them. It’s
similar to writing an outline before writing a story.
● This is why the entirety / totality of any experience must be thought through
wholistically - life for the user (and everyone else) is a series of events that take
place over time. It is easy to forget that users will start using your product after
finishing a previous activity, and will go on to do something else after they finish
using your software. Taking into consideration what happens before and after
helps make your product fit into the daily lives of people in a more purposeful and
meaningful way.
● How to be user centered
● Employ processes and methods to steer thinking towards users early and often
Mo Goltz - User Story Mapping 1

● By constantly thinking about the user, and what the world could be like from their
perspective, you gain empathy for them which leads you to make better decisions
on their behalf
● Understanding the the user is never in isolation, they experience the world over
time. Interactive products change over time too, so they can accommodate and
facilitate the user in their journey. There is no better way to understand and
communicate that journey then with a story.
Intro - Stories
● What is storytelling
● Storytelling is an activity that is old as mankind and is utilized within every culture
- it’s a universal way to organize share and process information about the world
while also connecting with others.
● Joseph Cambell ( mythologist, writer and lecturer,) discovered
● Studied the structure of religion and myths across many cultures.
What he discovered is that, consciously or not, every story (or
myth) told had been created with the same basic formula. This is
why great stories transcend even language barriers.
● TLDR
● http://www.pliant.org/personal/Tom_Erickson/Stories.html
● https://medium.com/re-form/what-is-narrative-ux-9400664660af#.4njbdkk
9j
● https://speckyboy.com/2015/07/30/the-importance-of-storytelling-in-design
/
● https://uxmag.com/articles/why-we-need-storytellers-at-the-heart-of-produ
ct-development
● Why is storytelling important
● What makes a good story
● Story structure
● Elements
● Setting
● characters
● Hero’s journey
● Learn more about stories
● http://www.echostories.com/5-ted-talks-to-make-you-a-better-storyteller/
● http://blog.invisionapp.com/improving-ux-with-pixars-storytelling-rules/
● http://www.slideshare.net/sarahdoody/the-need-for-storytelling-in-user-ex
perience-design-8999357
● How stories can be used for
● Design
● Personas

● User Journey
● Scenarios
● Create a series of narrative use-cases for your product that
illustrate every step in the user’s journey through it
● User flows
● Combine them together
● From my prev article: COMPONENTS OF GOAL-DIRECTED
DESIGN THAT SUPPORT PERSONAS - Personas, end goals
and scenarios relate to one another in the same way that the main
character in a novel or movie goes on a journey to accomplish an
objective. The classic “hero’s journey” narrative device and its
accompanying constructs have been appropriated for the purpose
of designing better software.
● Engineering
● User Stories
● Use Cases
● Backlogs
● a prioritized list of user stories that represent all the work on a
product that could be accomplished
● Often this large master backlog is separated into smaller
prioritized list of work items that can be completed in a
(typically) two week period.
● Often used by teams practicing agile methods such as SCRUM
● Resources
● https://www.atlassian.com/agile/backlogs
● Design and Engineering Combined - using User Story Mapping
● Use cases
● User Story Mapping
Intro - Story Mapping
● Story mapping gives the team a space to think through solutions / alternatives to create
great outcomes for users (and the business) within constraints (people, money, and
time).
● Story mapping (when done correctly) helps connect
● business strategy
● target users (and customers)
● user goals and activities
● Features

What Does Story Mapping Look Like
● Image
● Image
● Image
● Image
What is Story Mapping
● A powerful technique (pattern / model) that helps teams
● collaborate and communicate to decide what, when and how to build - it
facilitates product definition and planning.
● strategically decide how maximize outcome and impact for users and the
company while minimizing the amount of output (software design and
development).
● create a shared space to discuss and to think through solutions / alternatives to
create great outcomes for users (and the business) within constraints. (people,
time and money)
● Merges Agile / Lean methodologies with user-centered design thinking.
● Story mapping starts with a user's story, and then breaks the narrative / journey
into functional chunks. The narrative structure is always maintained (good for
designers) while still allowing for deconstruction too (good for developers).
Learn about Story Mapping
● Watch
● https://www.youtube.com/watch?v=ICMKhgBe4L4
● Read
● http://guide.agilealliance.org/guide/storymap.html
● http://jpattonassociates.com/user-story-mapping/
● http://storiesonboard.com/user-story-mapping-intro
● Talk & More
● see Mo to discuss
● he has books, articles, and videos to share
Why use story mapping? Benefits
● facilitates communication and collaboration

● it's format combines the whole user journey with its constituent user stories,
allowing PM, Design, Engineering and others to build / describe the solution
together using a shared format / language
● Story maps organize and structure user stories in a way that enhances
communications with and among the product team, other stakeholders, and
users too.
● provides context
● get a sense of the size / scope of a shared vision
● provides the big picture that a pile of stories so often misses
● create a big picture perspective, and give context to the details. You can think
about the details, and combine them into a coherent whole
● avoids the negative consequences that can occur when using a one-dimensional
backlog (queue). With a story map, you don't: loos the big picture of what a
software system should do. This avoids a 'frankenstein' creations that are just a
jumble of pieces that isn't really helpful to the users.
● supports planning
● Mapping a user story helps you find holes and gaps in your thinking
● helps the team decide what to build next
● helps the team avoid building unnecessary features
● keeps the focus on users
● Story mapping keeps us focused on users and their experiences, and as a result
produces a better conversation and ultimately a better product.
● keeps the product team focused on the user (their goals, and the activities and
tasks they will need to accomplish those goals) rather than the software and it's
features
● provides an orientation and context to build a coherent and useful experience for
users
● helps the team focus on what you hope will happen outside the system to make
decision about what's inside the system, and how aspects of the system are
prioritized
● Reduces Risk
● Minimize work required to create impact
● strategically decide how maximize outcome and impact for users and the
company while minimizing the amount of output (software design and
development).
● prioritize and rank work
● Break apart big things into: small things with small plans
● allow you to evaluate and see progress sooner
● this is done through prioritization and slicing
● Visibility
● enable much more visibility into the progress of a product development /
design project (everyone can see the project change as progress is
made)

● show where risk exists
● you can map out (and thus visualize and talk about) risk on the map by
capturing:
● open questions (helps inform a validated learning strategy)
● assumptions (uncertainty and risk)
● Additional Benefits (secondary)
● can support the following (though this is not the main use):
● show progress in the production process
● decide when to do work
● delegate that work
How is Story Mapping Different?
● Shared understanding
● Story maps are an efficient and effective way to create Shared Understanding
among team-members better than other methods. Shared understanding is when
two or more parties truly understand what the other person is imagining and why.
● Communal
● Story maps are a communal activity: team-members get together to talk, ask
question. They also externalize the ideas, concepts, and thinking generated as
the conversation goes along. Back and forth discussion combined with
externalizing ideas builds shared understanding.
Do We Really Need to Add a New Process?
● The problem with written documentation
● written documentation (requirements, a pile of user stories) alone, is not enough
to communicate clearly to create shared understanding. When people read
what's written, they intemperate it differently (as is shown by the blog and book
"Cake Wrecks")
● Use the right tool for the right job (in the right way)
● it's really hard to express a design problem in programming terms and it is
equally hard to do the inverse. The junction or rosetta stone of the design and
development worlds is a story map.
● Agile development methodology (such as linear backlogs) and other construction
techniques are great at a delivery tool, but not as good for design. It's advised to
build one feature at a time, but not design in the same way.
When do you use story mapping
● product definition and planning (start)
● while designing
● convert the story map into scenarios
● convert scenarios into storyboards

● convert storyboards into wireframes
● convert wireframes into prototypes
● while developing
● convert story map into backlogs
● convert backlogs into sprints
Process
● Overview
● As a team, we tell the story of a user and their interaction with a product or
service, writing each step the users take on a sticky note in a linear flow from left
to right.
● Then we go back and talk about the details of each step, writing those details
down and placing them vertically under each step.
● The result is a simple grid structure.
● Main Activity: Talk and Doc
● this activity supports the group discussion: think, write, explain, place
● write something on a card, talk about it, agree on what to build, put the card in
context relative to other cards (Card -> conversation -> Confirmation)
● Steps
● Create Context
● Frame the ide Idea (Opportunity / Problem) from a business perspective
● What is it?
● Why build it?
● What will happen when you do? (Desired Outcomes for our
business)
● Name the business problems you are addressing
● Determine specific business metrics affected
● decide on metrics that will allow us to measure people use and
like this new product / feature
● capture big risks and assumptions
● discuss issues with business stakeholders and subject matter
experts
● Develop success criteria
● how will we demonstrate this software later when we review it
together and with others
● what will we check to confirm that this software is done
● Describe customers and user and how you're helping them (provisional /
lightweight personas, map how users work today)
● List possible users / customers

● Define primary role / persona (focus on thrilling them above all
else)
● Define secondary role(s) / persona(s)
● What benefits will they get?
● Why would they want it? What's in it for them?
● What can they do with it?
● map out how people do things today
● conduct user research and observation to fill in what we don't
know or might want to learn
● Envision a Solution (and map it)
● focus on breadth of the story before diving into the depth
● go wide
● Imagine the future, then tell a day in the life story - brain
dump each task on to its on sticky (make sure to talk out
loud often and discuss as needed with the group) Do this
one step at a time.
● capture details / sub-tasks on their own stickies as they
come up
● arrange details / subtasks below associated main tasks
when they are related conceptually or occur concurrently
● arrange tasks in a rough / approximate chronological
sequence
● Continue repeating tasks above until a full story is told
(with a clear beginning and end) or you run out of ideas
● Add Activities - above tasks to organizes groups of related
tasks directed at a common goal
● go deep
● Types of cards you could add (color coded)
● - user tasks
● - system tasks
● - user subtasks / details
● - user activities
● - open questions (helps inform a validated learning
strategy)
● - assumptions (uncertainty and risk)
● - target outcomes for the user
● - ideas
● - opportunities
● On the Card - Info to Capture
● - Each card should have only enough information
on it to jog your memory / facilitate discussion
● - Title (on front)
● - Description (on back)

● - Optional Metadata: tracking system / tracking
number, indicators of importance, status, rough
size, budget, author, date created, value, metrics,
dependancies (on front and back - see connextra's
template)
● - Optional Metadata: Theme - a group of cards
(stories) that are related in some way conceptually
(not functionally) across discontinuous sections of
the user journey and release slices (a story can
belong to more than one theme)
● Beyond the Card - Info to Capture
● - Because many different people will be having
input on the cards / map, you'll want to capture
more info than fit onto a card (each 'library card
catalogue card' is not the book itself)
● - This additional info can be captured in any way
that is useful / advantageous for the team and its
members. You can link each card to additional
documentation / systems to accomplish this.
● - things not directly associated with cards might
come up such as discussions decisions. Capture
these using drawings, photos, videos, and text to
retain and remember conversations
● How to tell the difference between: task, subtask, and
activity
● - Task: something we'd expect to complete before
intentionally stopping to do something else. (i.e.
take a shower) (these are also known as functional
level or 'sea-level)
● - SubTask: micro tasks support the parent task (i.e.
adjust the water temperature or wash hair) (these
are also known as 'fish-level')
● - Activity: helps organize related tasks that
accomplish a goal (i.e. getting washed up, which
could include tasks such as: take a shower, brush
teeth, etc.)
● Subtasks
● SubTaksDelete…
● 0%
● capture details / sub-tasks on their own stickies as
they come up.

● arrange details / subtasks below associated main
tasks when they are related conceptually or occur
concurrently
● What are the specific things they'd do here?
● What are alternative things they could possibly do?
● What would make it really cool?
● What about when things go wrong?
● Are there any missing details?
● Break (some) Stories Down into Smaller stories
● A right sized story from a user's perspective is one
that fulfills a need
● A right sized story from a development experiment
is on that takes just a few days to build and test
● A right sized story from a business perspective is
on that helps a business achieve an outcome
● Identify the smallest viable solution that will bring value
● successful for a specific business strategy, specific target customers /
users
● prioritization of cards
● slicing of cards
● each slice should help you learn
● collection of slices = a release
● each release can be turned into a backlog
● Prioritize
● Consider which metrics / models to use to determine prioritization
(i.e. how do you define business value, exactly?)
● Rank or Categorize each task / outcome (Option 1: differentiator,
spoiler, cost reducer, table stakes) or (Option 2: must have, should
have, could have) etc.
● Slice into releases
● each slice should tell an end-to-end story! for each slice,
determine desired outcomes that each story will result in for the
user (and business), create a card for those outcomes, and place
that card to the left of the main story map (this seems superfluous
but is very important to focus our thinking on what makes a slice
useful)
● create a line below the body of subtasks / details that creates a
category speration of in/out
● Roughly categorize each details / subtasks as 'in' or out' of a slice
(remember: a slice is the smallest group of tasks that successfully
archives a desired outcome)
● Split and thin cards (stories)
● break down stories progressively (not all at once) and just in time

● split big stories into smaller stories, then thin out other stories by
removing unnecessary extraneous details
● make the plan concrete
● create estimates used for setting a development budget (time
and/or money)
Principles to remember
● Focus on the right things
● when talking, try to focus on the who (the user) the what (what the user will do)
the why (why the user cares)
● Focus on what you hope will happen outside the system to make decision about
what's inside the system, and how aspects of the system are prioritized
● Tell Stories
● Stories are called stories because they are meant to be told and talked about, not
just written down.
● when talking, try to focus on better solutions, about how this or that could be
accomplished, talk about how long this or that will all take
● Stories are meant to spark conversations that lead to shared understanding.
Writing down the details of a story is not important unless it helps you remember
and continue the conversation. (Kind of like a vacation photo reminds you of all
the details of the vacation, but the photo itself isn't intrinsically of any value)
● listen to others as they talk and doc, this will help you come up with other ideas
and then do your talk and doc later
● Turn stories into cards
● stories to capture
● user tasks
● system tasks
● user subtasks / details
● ways to organize stories
● user activities (they help group tasks)
● target outcomes for the user (they help create slices / prioritization)
● user tasks are the most basic building block of a story map
● Capturing Ideas: write each concept on its own card, then have a conversation
about it, then confirm shared understanding, then write the details of that
understanding on the back of the card
● there is no 'right' format to write down info on these cards
● Arranging cards into a map
● Map only what you need to support your conversation
● cards and their organization should serve as a means to generate conversations
and build shared understanding

● Break the map down into slices
● There is always too much to build. Focus on what you're trying to achieve for
your business and the users. Slice away what's not needed to reveal minimum
solutions that both delight users and help your business reach its goals too.
● Each slice should tell an end-to-end story!
● Focusing on specific target outcomes is the secret to prioritizing and slicing out
stories.
● Outcomes are what the users need to do and see when the system
actually does come out
● each slice groups together tasks that help the user (and the business)
accomplish specific outcome(s)
● Slice away what's not needed to reveal minimum solutions that both delight users
and help your business reach its goals too.
● Slices can be used to
● each slice should help you learn
● collection of slices = a release
● each release can be turned into a backlog
● Don't release each slice to users (each slice is an internal milestone to demo and
test)
● Think of each slice as an organizational container with different user
objectives and learning goals each.
● Capture additional information
● ideas you could (and should) capture
● open questions (helps inform a validated learning strategy)
● assumptions (uncertainty and risk)
● ideas
● opportunities
● as ideas / solutions come up, capture them. could be drawings, stories, facts,
decisions, etc. mapping these things to the user journey keeps things focused
and organized.
● there are more details than can ever be captured on a card, additional info
captured somewhere else such as a trello card, google doc or spreadsheet (great
if these are linked to the card)
● use words and picture too, create artifacts and connect them back to the map to
see how specific thoughts relate to the big picture)
Recruit a Team to Do this Together
● Discovery Tam

● The core discover team: The product owner (usually a PM) needs to be
supported by at least 2 other people, preferably from a senior designer and an
senior engineer to form the 'triad' or 'trifecta'
● Its recommended that a small, cross-functional team lead by a product owner
orchestrate product discovery and definition work (this includes story mapping)
● The ideal size for a core team is one that is 'dinner-conversation sized' so the
members can esily have once conversation to build shared understanding
● The different perspectives within the team will help find the sweet spot in the
venn diagram of what is desirable for all involved: valuable (business), usable
(product), and feasible (engineering)
● Requiring a single product owner to write all of the stories and be present for all
story conversations doesn't work.
● Support Team
● beyond the core discovery triad, there may be a need for a secondary support
team that forms the 'three amigos': BA, developer, and QA (testing)
● Other Stakeholders
● if you have more than a few people that want to contribute, try the 'fishbowl style'
collaboration technique (3 at the board who can talk and edit the board, rest is
the audience who stands back and listens. the audience members can tag those
at the board out)

User Story Mapping - Overview Outline

More Related Content

What's hot

Similar to User Story Mapping - Overview Outline

More from Mo Goltz

Recently uploaded

User Story Mapping - Overview Outline