Knowing how to create, read, and use a StoryMap are essential agile skills.
A Storymap can help you uncover user needs, find alternative ways of achieving a user's goals, help organize your product backlog,
visually communicate how the steps a users performs fit together, prioritize what to develop and more.
Story maps were invented by Jeff Patton.
In this video, we're going to cover how to read a story map, the vocabulary used for talking about story maps, when to create a Story map who should participate
in creating the Story Map, how turn a storytelling map into a roadmap, and how a storyline map relates to a product backlog.
Let's start by looking at how to read a story map.
By the way, my name is Mike Cohn, and I'm the author of three best-selling books on Agile and Scrum.
I help teams succeed with Agil.
A story is a two-dimensional visual representation of actions a user will perform to achieve some goal.
The first dimension of a StoryMap is across the map, Cards lined up horizontally show a sequence of steps a user will perform.
Because the horizontal dimension of a story map represents a Sequence, you can read across a map by mentally inserting the word Then between cards.
So the map here is read as a User does Step 1, Then Step 2, then Step 3. For example, if we're mapping the act of sending an email,
we might identify the steps of select recipients, enter a subject, compose the message, and send the email.
Each step becomes a card on the map.
You'd read the maps by inserting then between each card.
First, the user selects the recipients.
Then the users enters the subject.
The user composes the messages.
So far, so good.
But I said story maps are two-dimensional.
So let's look at the second dimension, which is going to be down.
The vertical dimension on a story map shows alternatives.
Sticking with the simple email example, there are actually a few ways to select the recipients of an email.
A user can type in an e-mail address or type a recipient's name or select a name from a contacts list or a select name for past recipients.
As you can see, we read down a map by mentally inserting the word or between cards.
Cards containing alternatives should be placed on the map in descending order of priority, the most important at the top and the least important the bottom.
Priorities established like this in a story map incision shouldn't be rigid, and their product owner can change them.
But it can be useful to have short discussions about rough priorities within a column of alternatives.
In my example story map, I'm saying that typing an address of an email recipient is the top priority.
So if we're developing this email product, i'd love for it to support all four ways of selecting recipients.
But if the team only has time for one, The top row of a story map is called the Backbone.
Generally, cards in the backbone are not stories you'll implement directly.
You won't, for example, bring the card Select Recipients into a sprint.
Instead, you will bring in one or more of the cards below it into the sprint A team might,for example decide that in coming sprint they will work on the
Type an Address and Type a Name cards, leaving the other two cards for later.
If your map gets a little too wide and unwieldy, you can make it easier to read by adding a second row to the backbone above the top row.
Think of the Top Row of The Backbone as analogous to signs along a highway, those signs that tell you when you're entering a new city or such.
On a story map, cards in the top row tell you when you're entering a new area of functionality.
But instead of, welcome to Arizona, the signs on the backbone say, Welcome to Saving a Document, or Welcome To The Checkout Process.
As long as we're talking about terms, let me go ahead and define a few other terms used with story maps.
After that, I'll describe how to create a Story map and how use it to convey a product roadmap.
In story mapping, we use the term step to refer to any card on the map.
Sometimes it's useful to referred to a group of steps.
In a story map, an activity is a collection of Steps that achieves some goal.
For example, logging in might be an Activity with the multiple steps of entering a name, entering password, passing a CAPTCHA challenge,
enter a code sent to the user's mobile device, and so on.
The steps and activities will become the user stories that give Story Maps their name.
Steps will typically be small implementation-sized user Stories.
An activity will be typically larger in what some teams and tools will call an epic.
If you put an activity under your product backlog, you'll probably later split it into the smaller steps or user Storys so that the team has small units
of work that fit well into sprints.
Finally, the term narrative is used to describe a sequence of items read across a map.
I was describing a narrative when I said you can read a across map by mentally inserting then between each card or step.
Looking back at our story map for writing and sending an email, we can a read narrative across the one line of the backbone.
Select recipients, then enter the subject line, and then compose the message, send the email.
By the way, if you want a one-page story mapping cheat sheet to help remember these terms and how to read a story map, I'll leave a link in the description.
It will give you a nice one page PDF on storymapping.
Let's talk about when to do story mapping.
I recommend doing it at the start of a project to get a feel for the overall product or system being built.
This is early on in a product, so don't get too detailed.
And I also recommend creating a story map any time a team is ready to develop significant new capabilities for users.
For example, suppose we're developing an e-commerce website and want to add wish lists as a new capability in the coming period.
We would create a story map showing how users will be able to interact with the new wish list capability.
I don't think you need to do a story map for everything.
For example, suppose we added wish lists to our e-commerce site years ago, and now we want to enhance that feature, perhaps with the ability to add a note
to items in a wish list.
We can probably just add user or job story to the product backlog describing this.
A user story could be, as a logged-in user, I can add note of an item in my wishlist so that I later remember why I added it.
Or I could write that as a job story.
When viewing an item in my wish list, I can add a note so that I later remember why I added it.
If you're not familiar with job stories, check out the video on them in this playlist and linked in the description.
Sure, there will be some UX design needed on this, but you probably don't need to map something out that is this small overall.
Who should participate in story mapping?
I want the product owner in any system or business analyst to participate.
We also want to consider including any users or stakeholders who can speak to the specific needs being story mapped.
If the team has a scrum master or coach, that person should facilitate the story mapping session.
And I want team members to participate, ideally the full team.
But this is not a meeting that I'm going to cancel if someone has dentist appointment.
I just generally want the whole team there.
When team members participate, they're going to hear the underlying reasons users and stakeholders want whatever is being developed.
Hearing about needs, problems, frustrations, expectations, or more directly from users or stakeholders can sometimes lead team member to insights they
may have otherwise missed.
And of course, I want team membership to participate because they often have very good ideas.
Ideas that non-technical participants may not think of.
Team members can also help steer discussions to the right level of depth.
I've seen more than one Story Mapping session where participants would have spent more time talking about something than it would've taken developers to
just do it.
Because a Story Map is arranged vertically in priority order, it's really easy to use a story map to convey a roadmap.
This allows a product owner to show the intended delivery sequence of features in one or more upcoming releases.
To create a roadmap, add a horizontal line to the map and then drag above the line everything that must be included in the next release or version of the product.
Then add label to map indicating what the items above line represent.
Here I've indicated that the cards above the line are part of the minimum viable product, or MVP.
Notice in this map that I put two cards from the third column above line.
This is fine.
It's just saying that those two alternative ways of doing something must both be supported in the MVP On the other hand,
notice that I didn't put anything from the fourth column above the line.
Again, this is fine.
It indicates that a suitable minimum viable product can be delivered without anything form that column.
Situations like these are common and to be expected.
To indicate additional milestones on a story map, you simply add additional lines.
Here I've added a second line to indicate the quarter three release.
I also moved a few cards above it and one lonely card below it.
Story maps can help teams discover important product backlog items they might have otherwise overlooked.
To do this, walk through the steps on your story map, thinking about each step from the perspective of a user.
It can be very helpful to ask a few questions at each stop, such as, what will a use most likely want to do next?
What mistakes could a user make here?
What could confuse a use at this point?
what additional information could the user need at the step?
If your product has multiple types of users, ask these questions for each type of user.
Story maps are my favorite tool to help product owners, stakeholders, and developers understand user needs and the interconnectedness of those needs.
I find story maps extremely effective for brainstorming the product backlog items that will be needed to achieve a team's next significant objective.
Do you use Story Maps?
Have you found them helpful?
What challenges have you experienced with Story maps?
Please share your thoughts in the comments below.
If this video has been useful, please click the Like button as it helps others find the video.
And if you're new to the channel, click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.