Story Mapping

Playbook
50 tips and 100 user story examples

ALL LEAKED BEST PRACTICES IN ONE PLACE

 Copyright © 2019 DevMads Ltd.

All Rights Reserved. No part of this book may be

reproduced or used in any manner without written
permission of the copyright owner except for the
use of quotations in a book review.

Published by DevMads Ltd.

Table of contents

CHAPTER 1
Introduction ................................................. 4

CHAPTER 2
Discover project goals ................................ 6

CHAPTER 3
Map the journey ......................................... 17

CHAPTER 4
Come up with solutions ........................... 22

CHAPTER 5
Prioritize user stories ................................ 43

CHAPTER 6
Slice out the release structure ................ 49

CHAPTER 7
User story examples ................................. 56
 CHAPTER 1

Introduction

4
User story mapping is really easy to learn. By collecting user goals, steps,
and stories and arranging them into a logical order on a story map, you
can get a great overview of what’s needed from your product.
Even so, story mapping could deliver even more value if you develop
your knowledge to the next level. Our advanced story mappers invent
amazing new ways of working every day, and constantly improve the
way they work. Based on their expertise, we’ve made a collection of tips
and ideas that’ll really ramp up your story mapping comprehension.
You’ve possibly already read our quick guide User Story Mapping for
Beginners, but for the benefit of those who haven’t, here’s a top-level
rundown of the process:

Discover the Map the Come up

project goals journey with solutions

Prioritize user Slice out the

stories release structure

To improve your whole story mapping process, we gathered together

best practices for each of these steps, so let’s dive right in. These
techniques work like Lego bricks, slotting together to build something
solid. You’ll find that most of them work well at the whiteboard, but to
get the most value from story mapping, we always recommend using an
online tool. So we can demonstrate our hints and tips more clearly to
you, we’ve used in-app screenshots of StoriesOnBoard.

5
 CHAPTER 2

Discover project
goals

6
Framing the project, and creating clear goals is crucial for effective
planning. Project goals are the cornerstones of story mapping. If you
write them effectively, your job will be much easier during the next
steps. If you miss a project goal, you can easily miss other aspects of the
story too, which leads to a product that’s full of holes.

Involve people in brainstorming

This looks like a cheap hint, but trust us, the more people you’ve got
involved in the creative stages, the better. The idea here is thought
diversity, and involving people from different teams adds new facets to
your thinking. For example, if you’re developing a webshop, a tech sup-
port team member could deliver valuable information around requests.
You’d get priceless information from marketing or commercial
departments too. If you want to avoid a ‘too many cooks’ scenario,
then organize silent brainstorming or a Crazy 8 exercise.

Exercise
• Let different people discuss the same everyday product
• Discover product-related teammates at your company

7
 Choose the best-fitting brainstorming method
As described above there are different brainstorming methods for
different needs. When a new project starts from scratch the best way is
to invite team members to a standard brainstorming and go thru the
planning phases step by step. First things first, the team should collect
the user goals, then the user steps and the user stories and so on...

As we mentioned in tip 1, if the brainstorming team is too big, and

escends into chaos, then a silent brainstorming session could be
effective. Create small groups to discuss the ideas, then place the results
on the board and remove duplications.

TEAM 2
TEAM 1

TEAM 3

Idea X Idea Y

Idea Z Idea Y

What TEAM 2 sees

8
 TEAM 1 TEAM 2 TEAM 3

Idea X Idea X Idea Y Idea X

Idea Z Idea Z Idea Y Idea Z

What the Product Owners sees

When your task is to improve a running product, there are two great
brainstorming methods. Reverse brainstorming is when you look closer
at the product features and try to find out which of them causes the
biggest satisfaction. This is easily tested by removing a feature and
investigating the dissatisfaction caused by this removal.
Reverse hinking is slightly different. This method gets you to ask the
question, “How would a typical user use our product?”
Then imagine the opposite outcome. Would it work? Why or why not?

Related article
5 awesome brainstorming
techniques to boost planning
We would like to introduce five special
methods for different situations.
Follow us to learn the new techniques.

Public story map

Silent brainstorming example

9
 Let your team catch up in story mapping
Although user story mapping is an easy-to-learn method maybe not
every team member is familiar with the process. It could be
embarrassing to admit it, and those members could participate
effectively. Remove barriers by starting a very simple story mapping
session. Let the people describe and map a very common activity of
day-to-day life, e.g. the morning routine (by Jeff Patton). So they’ll be
familiar with the method, and all of them can add valuable thoughts.

Involve the full cast - Think frontstage

and backstage
Brainstorming and story mapping of requirements often focuses on the
end user, the customer, and rightly so you’re probably thinking.
However, to effectively map out the full story you need to consider the
full cast involved in the system you’re designing and not just the end
users. To use a cliché example; the hotel receptionist informs you you’ll
be in your favourite room and that there’s a balcony table reserved for
your dinner as that’s what you like. The customer is interacting with the
front of stage.

But here the database and analytics informing the customer’s

preferences enable that interaction, that is the backstage design.
Story mapping is the perfect time to consider the full design from
frontstage interactions to backstage complexities. This is made easy by
StoriesOnBoard by through enabling layers of requirements as you go.

10
 Use personas for better understanding
User personas are crucial elements of a backlog. They are similar to
buyer personas, used by marketing managers to understand the target
market’s behavior and needs better. The target audience of a product
can be segmented by user groups according to their similar mindsets or
goals. Each user persona could represent a group acting similarly by
using the product.

John Doe

11
To engage your team and keep them focused on users, summarize the
main goals and add these cards to the board. To express individual or
common goals, mark your top-level cards with their related personas.
Using StoriesOnBoard you can easily assign personas to user goals.

GOAL 1 GOAL 2 GOAL 1

STEP 1 STEP 2 STEP 1 STEP 2

FEATURE 1 FEATURE 2 FEATURE 1 FEATURE 2

FEATURE 3 FEATURE 4 FEATURE 3 FEATURE 4

Further possible persona preferences

• Purchase behavior
• Challenges/Pain points
• Personal background
• Business background

12
 Related article
What’s on a persona card?
You’ve probably heard about personas and if
you created a persona, would realize how
hard it can be to define them. Follow us in
this short reading to get tips where to start.

5 formatting tips for personas

To create useful persona cards you have to
fill the details with valuable information.
Read more about what’s on a persona card.

Public story map

Guide map

Exercise
• Categorize your product’s users according to their behaviour
• Try to collect the key preferences of your user personas

Be specific about your User(s)

As a <user>, I need X, so that Y, is a great and powerful format for user
stories. As long as the user is specific. A ambiguous user is hard to design
for. Stories should be descriptive and specific on the actor involved.
They should focus on that user’s need, not a generic ‘user’ Imagine the
requirement to view the most read news articles in the top right.

13
As a consumer of news, that’s useful so that you’re up to date on the
latest trends. As a marketing manager it’s useful because it allows the
blank space on the right-hand side to be commercialised rather than
being blank. As you map across your board don’t shy away from directly
calling out the user – a logged in user has many different implications to
a developer designing secure by default. Avoid them asking you the
question, or assuming, and go specific. You can do this quickly with
StoriesOnBoard by colour coding different actor / user types.

How do you make toast?

Perspectives see the same thing differently
Starting a workshop or story mapping session with a few minutes of
‘gamestorming’ is a proven way to warm up a group of people.
The game we go for is ‘Making Toast’. Everyone spends a few minutes
writing the steps they go through to make toast. Then everyone reveals
their own toasting process to the group. Straight away, you’ll notice how
different everyone’s toast making process is. Some people will get the all
the items together first (butter, bread, knife, etc.), others won’t even use
a plate.

The purpose of this game is to emphasise perspectives – everyone was

aiming for the goal of toast, and everyone achieved it, but the journeys
were very different. Keep this in your mind as you go through the story
mapping process to design a more inclusive and diverse product.
One that meets the needs of more people, overall, increasing the value
add of your design.

14
 Design for a product, not for a project
We work in projects and programmes. However we design products.
Our customers and users interact with products. The ‘thing’ you are
building is what gives them value, not the governance, release frames
and documentation that a project brings. We suggest you shift your
mindset from one of designing with a deadline in mind as good products
don’t have a deadline, they’re used or they’re not and good ones are
used a lot.

Changing your mindset to realise your story map doesn’t just describe
the next 10 months of work but the first 10 years of a product’s life will
change your approach and your design. Changing like that will let your
attention focus on what really matters and enable the story map to em-
phasise a user journey that’ll be repeated and repeated.
It won’t just be a map that describes your release timeframes.

Remember that business goals will

influence design
As you story map you’ll be planning our features based on user needs
that is supported by solid user research and observations.
You’ll be problem solving as you map the journey path out. But reality
gets to us all, and we need to remember that someone is paying for the
development and design. That means their goals will influence the
construction.

15
We hope business and user goals align. And a good story map will facili-
tate that by allowing you to highlight features and user needs to wider
stakeholders that review it. But there are times when a business goal
does not align to a user’s or priorities will conflict. Now, unless you can
prove the benefit of a feature or user journey, you might not have the
clout to beat that business goal. That’s when highlighting key factors
becomes even more important.

StoriesOnBoard lets you easily call things out by including attachments

and uploads or changing colours. Remembering this need and taking
these simple steps make it easier to have that difficult conversation with
the Business.

16
 CHAPTER 3

Map the journey

17
 Continue to brainstorm
Don’t stop the brainstorming after you’ve found your goals.
If the brainstorming team is really engaged with the problem, they’ll be
more likely to be innovative in creating solutions. Continue to
brainstorm when you’re finding user steps and user stories too.
Using StoriesOnBoard in brainstorming mode, you can collect ideas as
‘cards’ and decide later where to place them on the map.

Think in stories
Forget the features. Tell the story following the logical narrative flow!
Tell the story of a user, who goes through your product to reach his goal.
If you split this goal into subgoals then you will focus only on a chosen
subgoal. For example, if the main goal is to purchase a shirt on a
webshop, then the subgoals would be something like: narrow the search
with filters, select the color and size, use the checkout etc.

Search for the Select product

product

Open main Use search Select product Examine

page panel product

Refine search Order search Add to basket

resulets resulets

18
 Retell the story
After you’ve built the narrative flow, ask a team member to retell the
story or retell another user persona’s activities on the product.
This way you’ll establish missing steps. It’s a really good idea to get team
members to tell the story in the first person. Telling a third person’s
activity can create distance, so break down these barriers by asking your
participants to imagine themselves as a user. Using an online story
mapping tool means you can easily insert a new step between two cards
if you need to. Moreover, you can rearrange the whole narrative flow by
drag&drop (which is much faster than moving cards on the whiteboard!).

Let me tell a story: an agile team wanted to develop a brand new

software for cash machines. They wrote all the user stories about
inserting the card, entering pin-code, entering the menu, withdrawing
the money, etc...

Insert the Enter pin-code Enter menu

card

Withdraw the
money

19
But something was missing. Fortunately, they found the missing part at
the end of the brainstorming session. Do you see what is missing?

Yes, they forget to “Take bank card back” :-)

You can check not only the narrative flow but the user stories. If there
are no user stories written under a user step, then there is no solution to
take that step in the journey. So you need to write at least one user story
under each user step.

Insert the Enter pin-code Enter menu

card

Withdraw the Take bank

money card back

Exercise
• Open story map examples and try to find missing steps in
the mapped journeys

20
 Don’t consider UX to be an afterthought
Invite a UX designer to add a different and practical mindset to your
team. It could be helpful in those moments when your team doesn’t
know exactly what the real user journey looks like. Ignoring users’
behavior at the beginning could cause additional work after launch, and
let’s face it, nobody wants that! Using StoriesOnBoard, you can assign
different colors to cards, or add tags to mark out several user journeys.

Think of the tool your user needs

Working through a story map is exciting. The discovery brings your prod-
uct alive. The vision is there for everyone to see. Within that excitement,
it’s easy to get carried away. We begin imagining bold, bright, new ideas
and start designing a system with great intentions and functions.
This vision quickly escapes from our capabilities.Constraints could be
technology, timeframe, budget, or anything else. When this happens we
need to remember our value statements and remember we’re building a
tool for a purpose and a specific user.

21
 CHAPTER 4

Come up with
solutions

22
The next step is to find solutions for achieving the user steps.
Through this process, you create "user stories". Initially, you can use the
following template: As a user , I want goal, so that step . Using the
accommodation example, a users storiey might be: “As a user, I want to
find hotels for my holiday, so I start browsing the discounts and adver-
tisements” or “As a user, I want to find hotels for the next week, so I start
searching by date.” Brainstorm with your team to collect the most possi-
ble solutions and put all user stories under the related steps.

Write short card titles

After mapping the user journey, it’s time to collect your solutions or user
stories. To keep the good overview of the board, try to write expressive
card titles. A smart title helps you to recover the story quickly and easily.
Avoid abbreviations as they aren’t always clear to everyone. Write or
attach every other piece of information to the back side of the card.

Online story mapping gives you the ability to attach unlimited details to
a user story, without complicating things. StoriesOnBoard limits the
visible length of card titles, to keep them short and sweet.

Highlight daily offers for

Highlight daily
last minute shoppers
on the main and search offers
page

23
 Exercise
• Take time to learn how to write short card titles
• Create long descriptions and teach the team how to
shorten them

Avoid cliches in your story writing

The good-old user story cliche “as a <user> I want <goal> so that...”
could be helpful when telling the story, but they aren’t always necessary
when you’re writing down the outcome. Standardized and repeating
panels waste the card title’s limited space and make the board hard to
read. When the team agrees to a user story, it’s good to summarize it in
your own words but remember to keep it short!

As a loyal shopper, I want to receive

I want to be notified deals notifications
about deals so that
I don’t miss them.

TOO LONG SHORTENED

Receive
notifications

EVEN BETTER

24
 Look beyond a problem to a goal
User Stories traditionally use the below format;
As a …
I need…
So that…
This format has a lot of advantages. A large one being it lets you
emphasise the goal of the requirement, the ‘so that…’ part of your user
story. This is important as it’s the part that shows how the product will
be user by a user and will let you know when you’ve actually achieved
the part that adds value to the product.

Writing the ‘goal’ or ‘value statement’ shouldn’t be difficult, and if it is,

the chances are the story needs re-thinking as it’s not screaming user
value.

Goal focusing make it easy to demonstrate your story is ‘done’ and to

articulate what the team has achieved when stakeholders ask or in your
‘Showcase’. I.e. we added this payment feature so that the customers
can make payments.

Size does matter

With many acronyms offering advice on the best way to format user
stories we won’t cover that again here. The important thing to
remember is size does matter. Detail needs to be sufficient and
necessary, not overwhelming. Attempting to add more details by adding
new words risks confusing people by accidently combining multiple
requirements into one or introducing ambiguity. Keep size in mind and
use your words carefully.

25
 Never miss the details
When brainstorming an idea, the team will tell you a lot more about the
user story than a card title. These valuable thoughts will be lost if you
don’t write them down. So try to make up a scheme for your user story
details. StoriesOnBoard’s markdown formatting allows you to create
great looking descriptions and lists with image attachment functionality.

Make up your own specification scheme. Separating categories

by using different headings gives nice looking card detail.

BROWSE BY CATEGORIES

OVERVIEW

SCENARIOUS

26
 A picture tells 1000 words
Story mapping is a beautiful technique as it allows us to read
requirements as a journey or a full story. This provides a fuller story of
the solution we’re designing. Saying that, if a picture or visual is
available it can enhance your story map dramatically.

Visuals answer a lot of questions in a way that’s both very quick and easy
to digest. If words can be drawn, they should be. Process flows, whether
sketched in sharpies of done to the highest fidelity are great ways to
improve a story map and can easily be added using the add image
feature from StoriesOnBoard.

SIGN UP

OVERVIEW

MOCKUP

First Name Last Name

Email Password

LOGIN

SCENARIOUS

27
 Ambiguity is the enemy
User stories want to be specific so that anyone, whether business or
technical, can read it and understand not only the requirement, but the
need for that requirement too.

You know what they say about assumptions, so don’t let that happen,
instead work to record all of the context and implicit knowledge you and
the group you’re with have. It seems like an effort to specify the what’s
meant by ‘clicking the pay button’ but it won’t be if it prevents the
re-work that would have been required because customers begin
complaining that they haven’t received their confirmation emails,
all because someone ‘assumed’ that no form validation was required
because it wasn’t specified in the user story.

These items seem like minor details to us involved in the trying to map
out the entire journey, but to a develop who has to pick that item up
from nothing, they’re very important minor details. Ambiguity is always
the enemy.

Be conscious of the story’s altitude

As you go through the story mapping process you’ll realise how large
the solution is (or small!). This will help to show you how much
development work is likely to be involved. To make that estimation
realistic, be aware of your story’s altitude.

What level of detail do you go into? Are you vaguely describing the way a
customer uses to product? Maybe you’ve stacks of user stories describ-
ing the NFRs involved in changing screens given certain traffic loads.

28
A story map with lots of gaps isn’t going to take you anywhere fast.
A map plotting every streetlamp and curb won’t help much either. We
recommend that level of detail should sufficient, but not be over the top.
Crucially though, to keep your estimates and assumptions realistic, you
need to be aware of the level you’re working at.

Evolve your information

The board is not just for the user stories, use it for notes and annotations
too. User story maps should be living and breathing backlogs. Has a new
idea or question come up after the brainstorming? Note and save them
for the next session or meeting to discuss. You can create new stories
from these questions and ideas to make things tidy or separate your
ideas and questions cards out of the user stories by using different colors
or annotations.

Highlight Receive
daily offers notifications
Change color

Default
User Goal
MVP
Medium Priority
Need to discuss
Purple
Risks

29
 Individual stories are a part of a bigger book
User stories are a good technique for capturing an individual
requirement. They describe a need and how the product should be
developed to add that piece of value. Being easy to digest they can be
useful for talking with any stakeholder, technical or not.

Linking them together through story mapping fills in the remaining

gaps. It creates a full scenario that focuses discussion on a product and
service level, rather than limiting yourself to an individual requirement
level. StoriesOnBoard allows you to start having that discussion by
providing an online, easy to access service, meaning you can remain
focused on product value, not displaying the requirements.

Tag your user journeys

If you’ve run out of colors, you could use small tags in the card title to
group them or express different meanings. Essentially, you could
perfectly visualize your journey just with these tags. Don’t forget to
explain which tag belongs to which journey, so all teammates can easily
understand it.

JOURNEY - impules shopper

30
 Related article
How to label user stories
Card colors are still a great feature to add
more visuality to a board, so use them for high
priority information such as task type, risk
points. Afterward, try to add icons to cards.

How to visualize personas and journeys

The next awesome opportunity to use labels
is visualizing buyer personas and journeys.
In a user-centered world, you can’t miss the
buyer persona out of the backlog.

StoriesOnBoard has an awesome solution to visualize your journey

called the search&filter feature. It allows you to choose and filter a
selected journey, helping the team focus on a selected journey on the
big story map.

Test the story map

If the goals, the steps, and the user stories are consistent, every
teammate should be able to perfectly retell a selected journey.
So, take the time to test the backlog to discover missing steps or logical
errors. Digital story mapping has the ability to hide unrelated segments,
so you can concentrate on the right part of the backlog.

31
 Involve your tester
A tester’s aim in life is to break the code given to them. They are
software’s embodiment of the scientific method. For that reason, get
them involved early, right from the story mapping stage.

A tester will bring a unique and importantly, different, perspective to the

Developer and Analysts in the room. They’ll make sure you user journey
considers the non-functional needs of the system – how fast do they
those APIs need to return their result? Do we need to think of what’s
rendering to the user on the page whilst the computation is taking place?

Testers will keep you on your toes. And whilst obviously you don’t want
to dive right into journey mapping every NFR you’ll need right from the
ideation phase, it’s important to consider them as early as is practical
even from a high level.

Look for the unhappy path

Story maps normally focus on the product’s happy path design. This is
sensible, it narrows attention and keeps focus on the product’s core
design. But considering the unhappy path before you need them has big
advantages.

First, some error paths are so common they can’t be ignored at all, think
password resets.

32
Second, bearing in mind some core error paths right from the start will
make sure you group user stories correctly and that more accurately
estimate the time it will take to develop your product. Finally, and
maybe most importantly, if you’re factoring error paths scenarios in from
the start, you will build a better product, because you’ll be able to design
a lot of those error cases out, or at least limit their impact on your user.

Slice user stories

Prioritizing user stories, or finding the best place on the map can be
difficult. This is likely to be an issue when your user story is too big.
The solution is to split them into smaller stories.

For example, the ‘search box’ on an ecom site could be too big a user
story when it contains the basic and also extended search functions.

It’s called vertical slicing when you split stories by functional boundar-
ies. Avoid slicing horizontally by technical boundaries, because the out-
comes are not independent stories. Using StoriesOnBoard, you can use
custom estimation units.
Estimations are summarized release by release. You can also filter your
‘too big’ user stories by using the search&filter panel.

33
 See details of selected product

OVERVIEW
• Categories
• Name
• Price
• Long description
• Image gallery - slideshow of the product’s images

Basic product Long description Image gallery on

page on product page product page

34
 Choose a slicing strategy
All projects and user stories are different, but you will have to find the
way to split those ‘too big’ stories to avoid overwhelming your teams.
If you struggle with slicing user stories, try the following strategies:

• Split by user persona - if different user personas need different fea-

tures of a user story, then you could place the new stories under their
related personas.

Sign up

TODO

Regular sign up Sign up with Sign up with

gmail account facebook account
TODO TODO TODO

35
• Split by data - test the user story to find necessary data only.
For example, a registration form can ask for multiple details like email
address, username, password, country of residence, phone number,
etc... But the core function of registration can work just with the email
address and password fields.

CONTACT DETAILS
First Name
Register standard
Last Name
information
Mobile
Email TODO

Home Phone
Birth Date Register personal
Address 1 informations
Address 2 TODO
City
Country

Store marketing
Receive Transactional Email
information
Receive Transactional Text Messages
Receive Marketing Text Messages TODO

• Split by acceptance criteria - keep out the edge cases and concen-
trate on the most common usage. e.g. Type A users are the ones that
pay with their bank card, the most common journey. Prioritize the Type
A journey and avoid edge cases that might want to pay using an alterna-
tive, lesser known method like loyalty points and trigger validation
messages or redirects. After breaking a user story into two or more parts,
some stories hold their positions and some might move to further
releases.

36
 Don’t scrimp on the scenario detail
When we learn to write user stories we stress the value statement, the
‘so what’ of the story. This is important as it lets the software engineer
know the reason they’re doing something. Knowing that lets them
tweak the technical solution to better achieve the business goal.

But, another important part of the story is the context. The scenario.
Providing more detail there saves tons of time in explanation later on
through slack, emails or desk bombs.

3 good ways to do that:

• Set the user’s background; ‘They’re a returning customer hoping to
re-order their previous food order’
• Consider the circumstance; ‘Usage is likely to be in a loud, busy
environment’ - maybe consider subtitles
• Consider their digital maturity; ‘Target user is of low digital maturity’ –
maybe consider video instructions?

These are just 3 ways you can increase the calibre of your user stories.

37
 Make your stories fallible
There are lots of ways to add acceptance criteria to your stories.
Whatever your preferred method, consistency is key. Having a reliable
format makes the story review and test process simpler in the long run.

BDD or ‘behaviour-driven development’ is a good method:

• Given <X state> - e.g. Given <a user is logged in>
• When <Y occurs> - e.g. When <they view the top right of the
homepage>
• Then <Z should follow> - e.g. Then <they should see the day’s most
read articles.>

Using this format forces you to double check your own homework – is
that scenario reflected in your user story, if not refine it now.

It’s scalable, meaning, without deviation you can add multiple

acceptance criteria by just changing the ‘Then’ statement.

It also aligns well to automation testing, where before creating scripts,

scenarios are conjured to prove or disprove. Using an appropriate
format has just saved your tester a lot of time.

38
 Group and theme your stories
You can add more value to your story map by grouping, categorising or
theming them as you go. StoriesOnBoard offers lots of techniques to do
this by colour coding, tagging or vertically staking them.

Doing it become really helpful when you start to consider how to cut
your Releases or the development work. Maybe it makes sense to group
things by page, maybe by component type, or you could do it by value to
user type. There are a lot of efficiencies to come from good, thorough
grouping and it’s quicker to do as you go, rather than retrospectively.

FEATURE 1 FEATURE 2 FEATURE 3

FEATURE 4 FEATURE 5 FEATURE 6

FEATURE 7 FEATURE 8 FEATURE 9

MARKETING FEATURES UX FEATURES RISKS

39
 Be aware of accessibility
Design tends to focus on the simplest, ‘happy-scenario’ first.
Due to biases this often defaults design to focus on an able-bodied
individual’s journey through the system. Except a lot of people have
different accessibility needs. These range from screen reader
requirements and text enlargement, to a different platform being the
default (e.g. using mobile over desktop) and colour blindness.
Building accessible products is necessary.

Consider these requirements at the story mapping stage and you’ll save
masses of time through limiting rework. It might also affect your entire
design by making you consider the journey from another perspective.
It’s better to find that change out early rather than half way through
development!

If you’re not sure on the extent of the accessibility needs for your
product, check the WCAG’s guidelines.

40
 Mark user stories
As we wrote earlier, tags can be used for several reasons. Here are a few
examples of what you might use a tag for in development:

• Risky stories - sometimes, developing a feature can be risky.

Special knowledge may be needed or sensitive data could be involved.
• Possible barriers - a barrier could be for example, if your development
source is offshore and there are delays beyond your control.
• Priority work - i.e. a particular user story is a priority, but development
work is on hold as there is an awaited outcome from qual testing that’ll.

FEATURE 1 FEATURE 2 FEATURE 3

FEATURE 4 FEATURE 5 FEATURE 6

NEEDS DISCUSSION IDEA RISK BLOCKED

Public story map

Accommodation Website - Visualize Personas
Accommodation Website - Visualize Journeys

41
 CHAPTER 5

Prioritize user
stories

42
After collecting the user stories you should arrange them into a priority
order.

Use MoSCoW categories

There are several prioritization methods, one of the best known is the
MoSCoW method. It’s a very popular way to broadly prioritize the user
stories.

The team could easily agree with the four main priority classes
(Must have, Should have, Could have, Won’t have) and decide the
stories’ priority. The easiest way to approach the method is to create the
four categories (as releases) and move cards into the best-fitting
category. You should keep these releases as long as you work on the story
map and you can create the final releases above the MoSCoW categories.

Outcomes Administering Browse site

products

Empty card Menage Open main

product catalog page

MVP

Release 2 - Improved shipment and payment methods

Release 3 - Security improvements

Release 4 - Improved marketing features

43
 It’s a must you drop MoSCoW
Prioritisation of requirements is crucial. There’s always more that could
be built that there is time, resource or money. Using MoSCoW for this too
often leads to arguments between stakeholders who have very different
opinions of what constitutes a MUST. And they can each justify their
position. What do you do? You ditch it.

Use a prioritisation framework or grid, with two axis, labelled in

consensus with your group, everyone can begin agreeing on somethings
priority. For example, contrast Customer Value on the Y-axis against
Technical Complexity on the X. It’s suddenly easy for everyone to agree
to MUSTs are those in the bottom right that offer the most customer
value and the least technical complexity.

See the wood from the trees – it’s easy to have

too many stories
As you get into your story mapping, you and your group will get excited
and psyched up around your design. That excitement will transform into
different potential requirements, more complex routes, different routes
and an incredible looking product story map. You’ll end up with a large
number of user stories. Now a large number could be necessary, your
design may warrant that number of user stories, or your might prefer
that lower level of detail. But, it’s common that that number is not
necessary, and is far higher than the sufficient number needed.
Trust us, having too many stories is not as helpful as it might seem.
Priorities will become mixed, themes will get blurred or detail may be
too low.

44
At the end of it all, if you have too many user stories it’ll be confusing.
Although, digital story mapping using StoriesOnBoard has big
advantages in this area as it keeps everything neat and accessible.
But even still, the number of user stories you write should be necessary
and sufficient, not exponential.

Continuously collect ideas

Ideas can come up at any time in the workstream and the team may not
always have time to discuss and prioritize them. That’s why you need to
create a space for new stories. You can place these cards into an
“unprioritized ideas” release. Don’t hesitate to put a new thought there
and organize meetings occasionally (or regularly) to discuss new stories.
This queue-box” is not just for product owners, all team members
should be allowed to add their new ideas. Sharing the map online allows
the team to leave comments on these new ideas.

Must have

Should have

Could have

Unprioritized ideas
Idea 1 Idea 2 Idea 3

TODO TODO TODO

45
 Remember that ideas are valuable
Never remove an idea. Put it into a “won’t have” or “icebox” release.

Recycle them and give them value.

• An idea may be valuable when the project’s scope is changing
• An idea could inspire teammates to think of a better suggestion
• An idea can show and prove previously tried “dead end” ideas

Involve customers
Involving customers in product development is crucial to enhancing the
customer experience and delivering an outstanding product. Whether or
not customers took part in the planning stages, walking them through
an overview of the story map is a really good idea.

By introducing the anatomy of your story map to the consumer,

everyone involved gains a clear overview of the product and its benefits.
Once users more easily understand the goals and features of a story
map, they can track product development and discover missing or
unnecessary features themselves. Managing product design with a story
mapping tool gives the product more value to the customer, and since it
is always available online, users can review progress and leave
feedback.

Managing a backlog in a story mapping tool allows the customer to track

current iterations through card statuses. Story maps keep your
customersupto-date with the development process, which builds trust
and transparency.

46
 Related article
Involving customers in product
development using story maps
Involving customers in product development
is crucial to enhane the customer experience
and delivering an outstanding product.

Look beyond the MoSCoW method

One of the most frequent criticisms of the good old MoSCoW method is
that you have to set priority levels for every single user story. But how
can you declare relative priority on similar tasks? In fact, the issue is the
same when you use priority poker. There must be a different approach
to scheduling tasks… We suggest using goals. For example, A UX
designer’s goals might look like this:

PRIORITY
1
“I got what I need”
PRIORITY
2
“Don’t make me think”
PRIORITY
3
“I really enjoy using it”

PRIORITY
4
“Habit is second nature”
PRIORITY
5
“Make users of your promoters”

47
 CHAPTER 6

Slice out the release

structure

48
After collecting the user stories you should arrange them into a priority
order.

MVP - is the shortest/simplest way

Collecting all the user stories and journeys is the easy part… but how do
we find the most common, most relevant, most needed aspect of work
to launch the project? A product can target several buyer personas, so
try to concentrate on the biggest crowd, the most simple and common
use case of your product. Remember, the user has to complete the
journey and reach their goal.Collapse any non-relevant steps to get your
MVP.

You’ve considered MVP, now think Minimal

Shippable Product
MVP is probably a familiar term. Storyboarding allows us to see the full
picture of a product, then slice it over and over to reach our MVP – the
smallest viable version of the Product. This allows us to focus attention
and stick to priorities.

A less familiar term may be a ‘MSP’ – the minimum version of a product

that a business is happy for their customers to use. This is likely a larger
version of the product, with more features and a longer development
period. For example an e-commerce product will have the requirement
to take payments, the MVP could be credit card only. But the MSP may
require debit and credit card functions.

49
This is a big distinction, driven by wider business context, its market and
environment – if everyone’s product takes both payment, a business
may simply not be comfortable only offering one. When everyone is in
the room mapping out the user stories it’s useful to understand the
differences and align expectations. This way the shippable product
developed will actually be shipped!

1 2 3 4

1 2 3 4 5

Call out the logical release points

As you’re going through your story mapping process the user journey
will start to take shape. You’ll be able to imagine how your product will
look and feel and how you can divide work out for the different develop-
ers within the team. If you start to wear your Delivery Manager or Project
Manager hat at this point, you’ll do everyone a lot of favours.

50
Start noticing logical release points. Where does a sensible product
iteration fall? Could you ship something when it gets to point X and then
continue to enhance up until Y? StoriesOnBoard makes this easy to mark
through tags. Doing this will add some big value to your wider
stakeholders who are interested in the product’s design but also when it
could start being used and adding value to the business and their
customers.

Come up with release goals

After slicing out the MVP, the next steps are not always clear. It could be
helpful to find or describe some further goals for each release.

Release

RELEASE GOALS

LINKS

51
A goal can be:
• reaching another user persona
• upgrading an existing feature
• improving the user experience
• increase the rate of returning users

Once you’ve chosen your next goal, you can move any related cards into
this release really quickly. In addition, there is a good opportunity here
to rethink your priorities and rearrange the releases.StoriesOnBoard
offers enhanced release management with release date and goal filters.

Give every map section an

outcome-based goal
Outcome-based roadmaps put the emphasis on the goal a deliverable is
trying to achieve rather than the milestone a team are trying to hit.
Spelling out outcomes and goals empowers a development and design
team to build a solution, not meet another milestone.

Story mapping is the design equivalent of that outcome-based road-

map. So when you combine the two, you’ll be onto a sure thing. You’ll
have the business onboard as they’ll be able to see the exact problem
you’re solving for them whilst also seeing the design you’ve come up
with to do it. You can do this by using the outcomes goals as story
themes and using the linear progression of your story map to achieve
more and more goals for the business.

52
 Use releases within scrums
Releases are developed to separate product versions, but they can be
beneficial in scrums too. Think of it as separate iterations using
release-lines. You could even create scrum iterations inside a release.
Using StoriesOnBoard, you can track your iterations using status reports.

Release

Rel1 - sprint 1

Rel1 - sprint 2

Release 2

Release 3

Imagine the map as a system

We know user stories should consider functions in isolation. Story maps
should combine user stories to create a journey – or to map the journey!
This is useful but it misses a level of depth by describing a journey in a
linear fashion. As often, the most useful products do not create simple,
linear user journeys. Some of the best software actively encourages
loops. Imagine an ecommerce site that focused solely on converting the
first product in a basket – there’d be no upsell! Story maps can be creat-
ed to show these journey loops. Arrange them by inserting trigger and
reference points.

53
Get a postit to read ‘return to point a’ or ‘trigger feedback loop X’ and
then on another layer you can map that entire feedback loop.
This increases the effectiveness of the story mapping process by being
more realistic. Actions have (without being grave or drastic!)
consequences and that feedback loop is something story maps should
try to capture if they really want to describe the user’s journey with the
product.

Stories should facilitate iteration

Anyone who read a user story you’ve created should understand its aim
and how it helps deliver the feature it’s related too. But they should also
see how it progresses, what the logical iteration is. Good stories are like
a lego brick. They’re independent but they’re also more useful as part of
a group. Alone they form something okay, but when combined, they
form something awesome!

You can build this into your user stories by clearly calling out the individ-
ual part of a chain they’re doing. For example, a user with items in my
basket, I need to pay for them [using my debit card], so that I can pur-
chase my products.

It’s simple, distinct, it’s useful. But by inserting ‘debit card’ we’ve left the
space open other payment methods at later iterations. The description
focusing on the user’s scenario allows us to space to iterate the process
further, i.e. yes they need to pay to receive the items, but what other
things could they do now there are products in their basket?

Use this iterative mindset as you create and review user stories in your
maps and individuals and you’ll encourage more innovation.

54
 CHAPTER 7

User story
examples

55
We collected one hundred user story examples in the most common
cases such as “sign-up process” or “check-out process” to give
ready-to-use solutions. Writing an intuitive user story is just the first
step. To deliver real value with a user story, you need to detail it by
adding descriptions, mock-ups, and pictures. Every user story is unique,
but there are some frequently used sequences that can boost the story’s
efficiency. For example, writing “scenarios” or “acceptance criteria”
guide you to collect all the crucial information.

Login / Sign-Up process

1) As a new site user, I need the ability to create a username that is not
my email address, so that I can have an identity on the site
2) As a new site user, I need the ability to create a secure password of
over 15 characters, so that I have a private account
3) As a site user, I need the ability to reset my password from the stan-
dard login screen so that I can access my account if I forget my password
without having to navigate elsewhere
4) As a site user, I need the ability to link my account to an email address
so that I can receive notifications from the website
5) As a site owner, I want the ability to validate an email field, so that I
capture correctly email addresses
6) As a site owner, I need the ability to send a confirmation email to a
new user, so that they are assured the sign-up process was successful
7) As a new site user, I need the ability to view and agree the site’s terms
and conditions, so that I understand what I am signing up for

56
8) As a site owner, I need the ability to display our terms and conditions,
so that I have the required permissions from my users and abide by
legislation and laws
9) As a site user, I need the ability to log in to the website so that I can
revisit my account at different times
10) As a site user, I want the ability to edit my user profile, including
username, address and date of birth, so that I can keep my details up to
date

Scenarios
• Username with different character sets allowed
• Username with only numbers allowed
• Username using only emails allowed
• Password that must be long
• Password that must include special characters
• Password that does not allow special characters

57
Checkout process
11) As a shopper, I need the ability to view different products across
multiple product ranges, so that I can find an item I want to buy
12) As a shopper, I need the ability to add item(s) to my shopping basket
by selecting ‘add to basket’, so that I can create a checkout basket and
purchase items
13) As a shopper, I need the ability to remove items from my shopping
basket by selecting ‘remove’ next to the given product, so that I can
purchase only the items I want
14) As a shopper, I need the ability to review my basket before making a
purchase, so that I am sure of the items I am buying
15) As the owner of a shopping site, I need the ability to take payments
from a shopper, so that I can sell my stock
16) As a shopper, I need the ability to check out as an anonymous user
so that I do not have to create an account to buy items
17) As a shopper, I need the ability to save a payment method to my
account, so that I don’t have to re-enter my details every time I attempt
to buy something
18) As a shopper at checkout, I need the ability to select different pay-
ment methods, so that I can choose the method most appropriate
19) As a shopper, I need the ability to enter my delivery address using a
postcode look-up system, so that my purchases can be sent to me
20) As a shopper, I need the ability to enter different billing and delivery
addresses, so that I can receive deliveries at places other than my billing
address

58
 Scenarios
• Input address using dropdown menu
• Input address using free text
• Input address based on zip code look-up
• Payment method of credit card
• Payment method of only debit card
• Payment method of PayPal
• Payment method using bank transfer

User Profile processes

21) As a user, I need the ability to enter biographical details about
myself, so that I can create an accurate profile
22) As an existing user, I need the ability to edit my existing details, so
that my profile’s details remain accurate
23) As a user, I need the ability to choose what details are displayed
publicly so that I only have to share things about me that I want to share
24) As a user, I need the ability to add a profile picture to my account so
that I can be identified easily
25) As a user, I want the ability to create a user profile, so that I can tailor
my experience when using the site
26) As a site owner, I want users to be able to create an account so that I
can relate historical actions to an individual
27) As a user, I need my account profile to have messaging capabilities,
so that I can contact other users
28) As a new user trying to sign up to a service, I need access to instruc-
tions from the sign-up screen, so that I can successfully sign up

59
29) As a new user, I need something to indicate which fields are manda-
tory to complete on the sign-up form, so that I can successfully sign up
30) As a developer, I need to highlight validation errors in the sign-up
form in real time by highlighting the field and providing an error mes-
sage so that users know how to correct input mistakes
31) As a user, I want automatic spell check on any input fields, so that I
am aware of typos and spelling mistakes as I input my information and
avoid errors

Scenarios
• Biographical details including Date of birth / Name /
About Us / Address / Likes / Dislikes
• Sign up using a 3rd party (e.g. Facebook) as a service
• Sign up using email and password combination
• Sign up using a guest account

60
Accessibility
32) As a developer, I need to make sure color ratios are correct so that
my website is accessible to users with visual impairments
33) As a developer, I need to make sure audio instructions are available
so that my website is accessible to users with visual impairments
34) As a user with visual impairments, I need the website’s features to
format correctly in close up so that I can access the website
35) As a user with visual impairments, I need to be able to change text
size, so that I can read the website
36) As a developer, I need to make sure all images on my website have
the correct accessibility tags so that a user with a screen reader can still
use my website
37) As a developer, I need to make sure my website works consistently
across multiple browsers so that I can increase my reach to different
users
38) As a developer, I need to consider different device requirements, so
that users with different device preferences (mobile, tablet, desktop) can
still use my product
39) As a developer, I need to make sure the next action to take is obvious
to a user, so that users are not confused using the product
40) As a developer, I need to consider loading implications under differ-
ent network conditions (3G, 4G, Wi-Fi) so that users can access my web-
site under different networking conditions
41) As a user with hearing difficulties, I need access to subtitles / tran-
scripts for all audio content, so that I can understand the audio content

61
 Acceptance Criteria
• When a user clicks on a ‘+’ the text size increases
• When a user clicks on a ‘-’ the text size decreases
• The content remains in order as the text size changes
• Media content moves correctly when text sizes are changed
• Given a user is on a 3G network, loading times are <X seconds
• Given a user uses the product on a 3G network, when loading
times are >X seconds the service degrades gracefully rather than
offering a 500HTTP error

Search
42) As a user, I need a search bar accessible from any screen so that I can
easily find the things I’m looking for from any page
43) As a user, I need the ability to set my searches to only return images,
so that I can easily find pictures
44) As a user, I need my search results moderated against standard ‘Safe
for Work’ standards, so that I do not receive explicit search results
45) As a user, I need the ability to filter my search by location, so that
search results are more relevant to me
46) As a developer, I need to limit the number of search results per page
to 20 results, so that search return loading times are not impacted due
to loading large result sets
47) As a developer, I need to implement an ‘infinite scroll’ feature on
image search results, so that results are more accessible to users
48) As a user, I want search terms recommended to me based on current
trends, so that I can access popular content

62
49) As a developer, I need to auto spell correct user search terms once they
select ‘search’, but make the user aware of this change, so that user input
errors are limited but they can still search for uncommon words
50) As a logged-in user, I want my search terms recommended to me
based on my history, so that my searches are more appropriate
51) As a user, I want the ability to delete my search history, so that my
search history is not impacting future search results
52) As a user, I need to be able to complete searches without having to
create an account, so that I can search for things without having to sign up

Scenarios
• Search results are returned based on; keyword matches
• Search results are returned based on; popularity
• Search results are returned based on; semantic matches

Music
53) As a user, I want to see the top 10 trending tracks in the top right of
my home screen, so that I can choose popular songs to listen to
54) As a user, I need the ability to create playlists, so that I can access my
favorite songs in one place
55) As a user, I need the ability to search for music by genre by selecting
one from a list, so that I can easily find music in a specific genre
56) As a user, I need the ability to search for songs by album, so that I can
easily find the album I am looking for
57) As a user, I need the ability to search via song title so that I can easily
find the track I am looking for

63
58) As a user, I need the ability to control the playback volume, so that I
can modulate the volume
59) As a user, I want to be recommended songs based on the last track I
listened to, so that I can easily find new but similar music
60) As a user, I need the ability to edit my playlists, so that I can change
which tracks are on my playlist
61) As a user, I need the ability to name my playlist, so that I can easily
identify my different playlists
62) As a logged-in user, I need the ability to share songs I like with other
logged-in users, so that I can be social with other users
63) As a user, I need the ability to receive notifications when songs from
my favorite artist(s) are released, so that I know when new songs are
available
64) As a user, I need the ability to see my recent searches within the
search screen view, so that I can easily find songs that I searched for
previously
65) As a developer, I need to limit the number of recent searches dis-
played to a user and order them chronologically, so that users are not
overwhelmed with very historic search history

Outcomes
• When a user shares a song, then another user receives a link
to that song
• When a user renames a playlist, it is visibly updated after
pressing save
• When a user deletes a playlist, it is no longer visible to that user

64
Mobile
66) As a developer, I need to make my website scale correctly to different
screen sizes
67) As a user, I need a mobile-friendly version of a website, so that I can
still use the website on a smaller screen
68) As a developer, I need to highlight key actions when the user is on a
mobile device, so that key actions are more obvious to a user
69) As a user, I want to be able to use the app offline, so that I can use
the product without internet access
70) As an iOS developer, I need to make my app accessible across multi-
ple Apple devices, so that I don’t exclude users on different iPhone types
71) As an Android user, I need my app accessible on the most recent
version of Android, so that it is accessible on the newest OS release
72) As a developer, I need to make my app accessible on mobile devices,
so that it can be used on the move.
73) As a mobile user, I want the ability to receive in-app notifications so
that I know when I have a new message/action within the app
74) As a mobile user, I need the ability to opt in and out of notifications
via the settings menu so that I can easily control whether I receive notifi-
cations
75) As a developer, I need to design my product to cater for screen rota-
tions (portrait & landscape), so that users can use my app in any rotation
layout

65
 Acceptance Criteria
• The app is made accessible on iOS v.N it is still accessible
on v.N – 4versions
• Notifications are visible as a red dot icon on the app
• Notifications are visible in the user’s notification menu

Security Admin User

76) As a Security Admin, I need the ability to reset other users’ pass-
words remotely, so that I can resolve password issues for users when I /
they are offsite
77) As a Security Admin, I need higher access privileges, so that I can
access additional features to non-admin users
78) As a system user, I need the ability to delete user accounts, so that
redundant accounts are not left on the system
79) As a Security Admin, I need the ability to view logs of other user
actions, so that I can monitor network usage
80) As a Security Admin user, I need the ability to block other user access
so that I can control user access
81) As a Security Admin user, I need the ability to log incidents with a
ticketing system that allows free-text input (limited to 200 characters),
so that correct responses can be taken
82) As a Security Admin user, I need the ability to create new accounts
for new users, so that new users have accounts
83) As a Security Admin user, I need access to the command line on com-
puters so that I can perform my role more effectively

66
84) As a Security Admin, I need the ability to set up network traffic moni-
tors view, so that I can respond to network threats appropriately
85) As a Security Admin, I need the ability to perform system backups, so
that recent systems images remain available

Acceptance Criteria
• Given a text field is limited to 200 characters then;
• The 201st character will not appear when typed
• Any text pasted from clipboard – characters after 200 do
not appear
• User is able to enter any input length from 0-200 characters

Holiday Booking
86) As a user attempting to book a holiday, I need the ability to search
via dates, so that search results are relevant
87) As a user searching for a holiday, I need the ability to order trips by
price, so that I can select results based on price range
88) As a user booking a trip, I need the ability to see reviews from other
people, so that I can learn more about the trip
89) As a user booking a holiday, I need the ability to choose different
departure locations so that I can make my search more accurate
90) As a user, I need my search results to include different airlines so that
I can compare prices across airlines
91) As a user booking a holiday, I need the flight lengths displayed in
search results, so that I can use that information to inform my choice

67
92) As a user, I need the ability to review my trip selection before I con-
firm my purchase
93) As a user, I need to receive a confirmation email following my book-
ing so that I can review my order and have a record of the details

Scenarios
Search results can be ordered by:
• Date
• Price
• Location
• Rating

Communication tool
94) As a user sending an email, I need the ability to add a recipient(s)
from a list, so that I can send emails to the correct person
95) As a user composing an email, I need the ability to format the mes-
sage text with different colors, font sizes, bold and italics, so that I can
emphasize certain parts of my email
96) As an email recipient, I want the ability to see a preview of the email
before I open it, so that I can decide whether I need to action the email
immediately
97) As an email user, I need the ability to create / edit / delete email
folders so that I can organize my messages correctly
98) As an email user, I want the ‘Send’ button in a position away from
other action buttons, so that I do not accidently send my email

68
99) As a user organizing a meeting, I need the ability to access my calen-
dar without leaving the email tool, so that I can easily organize meetings
100) As a user, I need the ability to mark emails with an importance level
before I send them, so that recipients know how urgent my message is

Scenarios
• Calendar is accessible via an icon in the bottom left
• Calendar is accessible via an icon in the tool bar
• Calendar is accessible via a dropdown menu

69
Your opinion
matter to us!

RATE THE BOOK

70
Build software
that matters!