User Story Map: a practical tool to get a glimpse of the whole picture
Today, almost every product team I know is applying the agile development methodology, no matter it is for the reasons of responding to change, emphasizing on collaboration, or focusing less on documentation.
I have been continuously considering a question: after executing the agile process for a while, how can we make sure we won’t deviate from the target we have set at the beginning?
In German, there is an idiom called ‘Auf dem Holzweg sein’. It means ‘to be on the wrong track’, which can perfectly describe the cases when the tasks we focus on are not fitting to the overall target and the problem we would like to solve.
In order to be ‘on the right track’ when managing the development tasks, there is a tool called ‘User Story Map’ which I would highly recommend,
User Stories
Before we dive into user story mapping, let’s adjust the angle to user story first.
User story, was introduced by Kent Beck first, who is the original signer of the Agile Manifesto.
Originally, a user story was raised to solve the problem of ‘common understanding’. It is the smallest unit of work that describes who, what and why the user desires to achieve certain goal and value.
With a clear description of a user story, different parties, like product owner, developer, etc, can understand the actual user requirement.
Human likes to read stories. If at the beginning we focus on the user story, instead of functional solution, thus, different parties can share the same understanding to user’s requirement.
A complete user story comprises of three major elements: user, activity, and value.
User defines who needs the activity. Activity describes what functionality the users desires to achieve. Value means the benefit that a user can gain by executing the activity.
Typically, a user story can be fomulated as:
As a <Role>, I want to <activity>, so that <Business Value>.
For example, as a customer, I want to know when the commodity would be in stock again so that I can buy it in time.
User Story Map
User story map is a technique to visualize the work and goals to to be completed in a digital product, which usually consists of a bunch of user stories.
Do you know what the function of map are? There are mainly two sides: finding the path, and getting the whole picture.
- Finding the path
When we want to drive to a place, by inputing the start and end points, any map app would find the best route for us. When we were still at the time with paper maps, we also needed to locate the start and end points to plan the path on our own.
Finding the right path is a natural outcome we could gain from a map.
- Getting the whole picture
When we were at school, we learnt about continents and oceans with a world map. A map shows us primarily how the world looks like and how the countries are next to each other.
This is what I call ‘getting the whole picture’.
Similarly, user story map also works the same. We can also gain two major values from it:
- We can find the backbone of the product, which is the path. Thus, the product team won’t miss the key features the product requires.
- We can get the whole picture of the product. The product team can then share a common understanding about what to be built, why they need to be built and for whom the team is building.
How to create a User Story Map
User story map can be practised at any phase during the product development lifecycle. It can be used to drive discussion, share common understanding and assist in team alignments.
When constructing the story map, a small team with the parties from business responsible, product, UX, development and major stakeholder can collaboratively discuss and shape the flow, structure and plan of the product.
Before the formal construction, it is of significance to define the product goals, who we are building the product for, what kind of real problems the product is solving, scope of the story map, outcome and benefits the product is targeting at.
For on-site teams, we can use sticky notes, white boards, etc. to support us with creating the story map.
While for remote teams nowadays, a bunch of digital facilitates, like video conference, slides, online programs could support the team to build the map together.
Frame the backbone with activities and tasks
As the first step, it is necessary to anchor the major activities tasks of the whole product per time sequence broadly. We can imagine the backbone as the fundamental flow and skeleton of the product.
Like how we brew the coffee, we need to write down every activity and tasks in the step: there are many tasks we can think of, for example, grind coffee beans, place paper filter, boil water, etc.
At this step, the activities and tasks do not need to be articulated in depth as more specific user stories will plump each activity.
As an outcome of the step, we can ensure a clear backbone with the vital activities and tasks (or also named as epics) which can be grouped with a bunch of stories afterwards.
Split and map stories under each activity and task
Right for each activity, it is of importance to create a series of user stories so that we can gain more detailed contents of the activities.
During the process, we can ask the team to write down whatever the participants think that is important to the activity. Similar to brainstorming, we can stimulate the team to think of some questions like:
- What shall the user do with this activity?
- Does the user have any other alternative?
- How shall the user execute to be more efficient?
- How shall we handle if there is any issue happens?
By exploring the activities further, this step would help the team to gain more details about the product in depth.
Communicate and confirm
As the next step, it is important to organize the scenarios, clean up the stories, and classify the tasks with close team discussion. We should place the tasks together which happen at the same time. In the mean time, we should consider if there is any detail missing.
Prioritisation
After articulating the major activities, backbone and stories, the team can start the prioritization process to rank the stories vertically.
With this step, the team would share the common understanding which stories have the largest impact and shall be worked on first.
That is to say, with the prioritization, we could also define and plan the releases of the stories.
Afterwards, we can get a user story map as following:
Thus, a user story map is ready.
How to solve problem?
Let’s get the back to the question: how can we keep the whole picture in mind when digging into so many tasks?
After we create the story map, can we see the whole picture so that we can avoid to be on the wrong track?
The answer is YES!
Earlier, I mentioned two functions of a map:
- Finding the path
As we list the major activities and backbone as per the time sequence, we can easily find the whole path and understand how to reach the complete flow of the product process.
With the story map, we can view and think broadly with certain degree of details.
- Getting the whole picture
After we see such a story map, we can clearly know which major tasks we have for the product. During development, we can easily know how the whole story line is in progress.
Summary
User story is not another way to draft the requirements, but rather a communication tool to support the teams to reach common understanding.
When we talk about a story, it needs to be well told to attract the relevant parties. The sames goes to user stories. User story map can perfectly act as a practical technique to connect the attractive stories together to visualise the needed work for the product.
With the support of user story map, the product team can not only find the path of the product, but also keep an eye on the whole picture during the product development process.
