A while ago I attended a Scrum Developer workshop facilitated by Mario Melo where we used User Story Mapping to create backlog stories to an imaginary product.

User What?

User Story Mapping 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 or check Jeff Patton’s book.

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.

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.

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 stories.
• 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’.

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.

Originally posted on my Medium page.