An Experiment with User Story Mapping
Tags: agile, scrum, userstorymapping, userstory
Published: 2020-04-29 18:57:57


![enter image description here](https://miro.medium.com/max/4452/0*VQBwgVGeQAuQ0hm2)

A while ago I attended a Scrum Developer workshop facilitated by  [Mario Melo](https://melomario.com/)  where we used  **User Story Mapping**  to create backlog stories to an imaginary product.

# User What?

[User Story Mapping](https://www.jpattonassociates.com/the-new-backlog/)  was created by Jeff Patton and it is a way to organize a product backlog that intents to allow the team to see “the big picture”.

To do so, we establish:

-   A “**backbone**” that will represent the categories or the big modules;
-   A  **narrative flow**  ordered from left to right that tells the story of what we want to achieve;
-   **Small tasks** representing the steps to accomplish the story.

[Learn more here](http://www.jpattonassociates.com/wp-content/uploads/2015/03/story_mapping.pdf)  or check Jeff Patton’s  [book](https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909).

To understand the technique Mario provided us an example (also created by Jeff Patton) of narrative flow for a person getting ready to go to work. I tried to reproduce it in the image below.

![User Story Map “Go to work”](https://miro.medium.com/max/1481/1*A3X0Vu0QgUwTZjZX7M2CIA.jpeg)


We have the categories in  **blue** representing the  **backbone** of our story and the  **narrative flow**  in  **yellow**.

To complete the story “**Go to work**” we have the  **MVP** with the tasks in  **pink**. Imagine that the MVP is what is done in a day when the user Dani wakes up late.

The remaining activities in  **purple** on the backlog are the  **desired**, but not mandatory  **activities**. We can think of them as something that is executed only during the days when the user wakes up early (or during the next Sprints).

The advantages of it towards a flat backlog are:

-   The story is organized in a **logical flow**  and can be seen as a whole.
-   **Every member**  of the team can get  **involved**.
-   **Prioritization** is visual.
-   Describes a  **journey** to accomplish a goal.

# I want it for my project!

The activity went so well during the workshop that I suggested the technique to my team since we have just started a brand new exciting system.

My Scrum Master delegated the responsibility to conduct the session to me and a colleague. I have never done something similar before, but I enjoy testing my anxiety limits.

![](https://miro.medium.com/max/1131/0*Kl5CG0LqTj-LIY_i)

After a little bit of reading about the subject and counting on Mario’s extra advises, the plan was:

-   Establish a common  **dictionary** of terms with the Development Team, the Project Owner and the Test Team.
-   Identify possible  **users**.
-   Discuss and  **map 3 user storie**s.
-   Every member of the team would write the activities to every user story in a “Post-It”. In the end, we would join them and discuss if they made sense or not.
-   We should use a  **timer** and keep it visible to everybody.
-   We should have background  **music** while people were writing. :)
-   Perform it in a 2-hours-meeting.

# And how did it go?

In the beginning, the team seemed a little bit confused, but soon most of them started getting involved and collaborating. Additionally, we  **almost** have  won against attention leechers a.k.a. mobile phones and parallel meetings.

I struggled, however,  **controlling the time**  and the session. Since the discussions were flowing, I did not dare to interrupt. But because of that, we could not keep the quality of the discussion until the end.

I also had a hard time trying to  **keep things on track**. I was just a software developer trying to facilitate a session and I did not feel that I had the authority to stop some discussions and simply move on. I did not want to be “bossy” or to give the idea that some member’s opinions were less valuable than others’.

![](https://miro.medium.com/max/609/0*mEFXrYL-up8eUY71)

After the session, I have conducted a survey to collect the team’s feedback and the answers were pretty encouraging. Between some complaints, there were positive comments and the overall opinion was that the session was essential to  **put every team member on the same page**  and to  **clarify** what is, in fact, this new system that we are about to create.

# Lessons learned

If I would like to conduct a similar session again?  **Yes**! Nevertheless, I would try to make some things differently:

-   **Control the time!**  Time flies fast when there are many opinions to be heard.
-   Make sure that everybody understands that  **some discussions might get stopped before coming to an end**. The focus should not be compromised.
-   Split the team into groups to think about the user stories. It is easier to merge all ideas afterward and it seems to me that it would  **encourage collaboration rather than a debate about who is right**.

It is rewarding — and fun — to try distinct ways to do the same stuff and, despite the “setbacks” and some heated discussions, it was delightful to see so many members of the team with such a great extent of engagement for that amount of time.

![enter image description here](https://miro.medium.com/max/662/0*J9g8_cf7nKiymea9.jpg)

Originally posted on my [Medium page](https://medium.com/@danianepg/an-experiment-with-user-story-mapping-f0a78b9d86ec).