A while ago I attended a Scrum Developer workshop facilitated byMario Melo where we usedUser 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;
• Anarrative 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’sbook.

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 inblue representing thebackbone of our story and thenarrative flow inyellow.

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

The remaining activities inpurple on the backlog are thedesired, but not mandatoryactivities. 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 alogical flow and can be seen as a whole.
• Every member of the team can getinvolved.
• Prioritization is visual.
• Describes ajourney 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 commondictionary of terms with the Development Team, the Project Owner and the Test Team.
• Identify possibleusers.
• Discuss andmap 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 atimer and keep it visible to everybody.
• We should have backgroundmusic 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, wealmost 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 tokeep 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 toput every team member on the same page and toclarify 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 thatsome 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 wouldencourage 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 myMedium page.