User Story Mapping

It’s late in the evening the plane finally settles on the tarmac. The last two days have been intense. Despite the fatigue, somehow, I find it difficult to calm down and stop thinking about what we have accomplished. I am still impressed with the results we have achieved during the workshops.

Just a short journey through the empty streets lit up with Christmas decorations, and I will be home… that is, at a hotel. Because this time, I am “only” a few hundred kilometers away from home, in a place where tomorrow I will continue my journey through the world of requirements analysis and product development. In less than 10 hours, we are starting another workshop.
Despite all this, I still like this job!

One November day, the phone rings. There is a job to be done – you need to conduct a workshop and collect requirements – that is the offer in short. The industry – completely unknown to me, the location – central England, the date – a few weeks away.

All these elements make me think a little longer than usual. In a few moments, however, I say yes – let’s get down to work! We get through the administrative details quickly. And then it is time to get prepared.

We are going to conduct a User Story Mapping session, based on Jeff Patton’s concept, but with some modifications. That is the plan.
I have had quite a lot of previous experience with this technique, but each product has its unique characteristics. And no two teams are identical.

What I have learned is that there are no good workshops without prior preparation.

Prepare the participants

Therefore, the first step, or maybe even step zero, is to prepare the participants. We have already carefully selected the people invited to the workshops. In my opinion, the first meeting must include the Product Owner and other business specialists. No more than 5 or 6 people. I add technical specialists later in order not to filter ideas through feasibility criteria.

But let’s go back to the preparations. The group has already been put together, so a few days before the workshop is to start, I send them detailed instructions – why we meet, what our goal is, what we are going to do, and what is needed from them to complete the workshop successfully. I also throw in some links to background material on the subject.

I don’t forget the logistics – to run a workshop you need multicolored cards, some writing materials, sheets of paper on which you can group your requirements, something to stick the cards to walls with, and my trusted colored tape (why – more about it later).

It seems obvious, but I have already witnessed the initial enthusiasm of a group being destroyed by an increasingly frantic search for all the necessary workshop accessories.
The preparation of participants is one thing. Equally important is to…

Prepare yourself

Since I expect preparedness from the participants, I also expect it from myself. You may think that since I’m only conducting a workshop (I’m only a facilitator), I don’t need to know the industry. Of course, you don’t have to know it, and nobody expects you to be an expert.

But think of it as if it were a visit to a foreign country. If you at least learn to say “good morning” in the local language, then from the start, it will be much easier for you to get along with people in a store or a restaurant. Even the worst-sounding greeting in the local language generates more goodwill than the traditional “good morning” in English.

Preparation is also important to me because I respect my partners. We are devoting a lot of time and energy to the workshop, so let’s do it right. Let us do our best, and not be satisfied with anything less. So, I look through all the submitted materials, analyze, write down questions, and note topics that are worth taking a deep dive into. Ok, my list of questions is now complete, so just a few more days and…

I am on my way

The plane leaves after 6 am. That means I get up at an inhuman hour. I quickly collect my things and go to the airport. The capital looks deserted at 4 am. Almost no traffic. My Uber driver seems not to notice it. We travel at  the breathtaking speed of about 40 km/h, on the left lane…  I’ve got a feeling that it’s going to be a long day.

Fortunately, the pilot of the plane is better skilled and from now on everything goes well. I arrive in London on time. I wait for one more person (the UX designer) who is arriving from a different location.  There is a slight delay. We nervously queue for train tickets. Finally, it’s our turn! We quickly buy overpriced tickets (peak hours) and run to catch the bus. Phew, we made it. Here is our first success – we arrive at the train station on time. Moments later, we watch the diverse landscape of central England through the window of a speeding train.

Get prepared for the second time

We use the time spent on the train to synchronize our levels of knowledge. We browse through the materials, clarify doubts. I pause to take a look at my watch. It is about 11 am our time. I don’t even want to know how much time has passed since I got up.

When preparing for a workshop, you also need to learn about the participants. You need to know who they are, their levels of experience or seniority. And memorize their names right away to avoid awkward situations.

No matter how much you learn about the participants, you are never quite sure who you are going to work with. There is usually no information about personality type or a sense of humor on LinkedIn.

So, there is always a bit of uncertainty.

Their level of experience and job descriptions make me expect a serious, maybe even stiff meeting atmosphere. Such an environment does not make creative work easy. When we approach the conference room, I’m getting a little nervous…On the spot, we are unexpectedly greeted by young and smiling faces of workshop participants. Reserve is out of the question. Everything will be fine!

Get prepared for the third time

This is the last bit about preparation. I promise.

First a small digression. When we arrive at our destination, it is already around noon Polish time. I quickly count the hours that have passed since the early morning. I should have finished my 8-hour working day a long time ago. And nothing has even started yet…

I wash my face and look for a coffee machine. There it is! My euphoria does not last long.  After all, we are in the country of tea lovers. Why would anyone want to drink good coffee? So the machine does not make any grinding noises but pours some dark-colored liquid into my cup. It seems to me that even chicory coffee is more aromatic and more powerful. Maybe my brain will be deceived?

But let’s get back to the subject.

Even if you have already sent detailed instructions and answered possible questions by e-mail, then just before the workshop, tell everyone what it is all about again and describe what the teamwork will look like.

This time I slightly neglect this part and at the beginning, there is a lot of uncertainty. After the workshop, the participants point out to me, that such a solid introduction would have helped them. Sounds obvious. Now I’m going to remember that.

Here we go or, in other words, tell me a story

I always start my story mapping workshop with… a short story. Although it is not exactly me who is telling it.

I ask one of the participants to prepare and present a story. The story should be about target users (person), their problems, and challenges. Without mentioning any specific system functionalities.

This element usually works out perfectly. We find a common ground with the participants. We know what is important, and at the same time, we take notes, which speeds up the subsequent steps.

I wrote “usually” because I have already heard anti-stories several times. This problem usually occurs when you are building version 2.0 of an existing system. The “story” may sound like this: “…and the user selects an option… and types in… and then clicks… and then it’s done”. Great, but that’s not the point.

Time to return to the main subject and the story told there.

A moment of uncertainty because we do not know what we are going to hear. After a while, we know that it is very good. The story is lively, it contains all necessary elements and does not drag on too much.

Soon we have a lot of notes and we can start.

Still, on the subject of notes, the team has prepared themselves for the workshop perfectly. We have a whole pile of multicolored cards and other tools. There is even a blue tape, which will come in handy. Another big plus!

The main path through the system

We get up and start to build the main process together – the path that the defined personas follow. And here, as usual, misunderstanding creeps in.

Typically, when we plan to build systems, it is natural to have the following levels:

• implementation – we start with the architecture, then the database, API etc.;
• functional – we define the most important functionalities first, and then the rest.;
• design – we divide our timeline into stages, first collecting requirements, analysis, design, etc.

The option I use in my workshops is completely different. Often the participants try to clumsily fit it into the way of thinking they already know. This is also the case here.
It takes a moment to explain things and some additional examples get the job done. Now we know where we are going.
The work on the main scenario is interrupted by the lunch break. It is, in fact, quite late. We recharge our batteries with a variety of sandwiches and, as we are in England, we have chips.

And now let’s get into the details

Soon, the main story is established and pasted on the wall. We throw in the personas – users we have defined together. This is only the beginning of our work.

Then comes the time for details. We discuss each of the steps in detail. Questions, doubts, and contradictory expectations appear. All this is completely normal. We carefully note down every idea, because at this stage there are no stupid answers.

This moment is critical to the success of the whole process. You can go too deep into the details or, on the contrary, only go through the issues superficially.

Thanks to prior preparation, I successfully engage the participants in creative discussions. They in turn repay me with specific responses, based on market research (and not on their own guesses, which often happens).  The more I know about this industry, the more relevant my follow up questions are, and we gradually move forward. Gradually… because time is crucial here! Workshops can drag on indefinitely. We simply like to talk about what we are interested in. To keep time under control, I draw something like a burndown chart with topics to discuss and the time we have left.  We have a specific number of steps to discuss and a certain amount of time on our disposal. It is easy to calculate the optimum speed. This tool takes care of the matter.

We also mark problems we have found no solution for in a specific way. We move them aside and go on.

It has been dark outside for some time now. We spend another hour working on detailed requirements. You can feel the levels energy and commitment decreasing. This can be most clearly noticed in these participants, who used to actively stand by the boards and now mostly remain seated with occasional bursts of creativity.

You probably know this feeling from parties or board game meetings. There comes a moment when people start saying “Keep playing without me” or just go to sleep. What can you do?

I could write that I switch into second gear and make the discussion more dynamic. The problem is that I have already done that – at the beginning. After a dozen or so hours on my feet I feel only rocket fuel could help. A short break, a loose discussion about the Sherwood forest around us, a sip of the coffee-like beverage, and we move on.  I feel I have some more strength left. I get up, I do not allow myself to rest. The participants are also reinvigorated. Just a minute more and we finish. For today.

A Break

Finally, we look at our work with admiration. Several sheets filled with user stories. The view is impressive. There are still some areas to be completed, but that can be done tomorrow.

In the evening, our hosts take us for a walk through their enchanting city, we visit a pub (of course) and have some traditional British (or rather Indian) food. Everything is great. The evening ends with a walk to the castle to greet Robin Hood who stands there. I can confirm that he is still guarding Nottingham. We return to the hotel, take a short nap, and start another day.

MVP

The day begins with another success. All the cards still hang where we left them. It is not always the case. Sometimes we have to start the day by picking up yesterday’s results from the floor.

We fill in the details until the end of the scope. The map grows and grows

Now the last major task before us is the division of this scope into versions.

We start by defining the MVP, i.e., the minimum needed to launch the production version. Beforehand we define what MVP means to us, so that there are no misunderstandings.
The process of grouping stories and assigning them to versions can be difficult and sometimes painful for participants, because everything is important. Some of the functionality ends up placed near the floor, which means “great idea, but not for now”. The rest is divided into three parts (versions). This is where the blue tape comes into play, clearly dividing the subsequent stages.

As you can see on the attached map, the first version (from the top) is really basic but covers most of the process steps. It is going to allow us to quickly test the assumptions we have made. We will add most features in the third version when we have enough information from real users.

And this is the essence of the presented method. Designing a basic, yet fully functional version.

Archive

At the end of the second day, we look at the end result with even greater satisfaction. You can clearly see the tangible, measurable effects of the used technique. More precisely:

We know what we want to achieve in the first stage of work (MVP) and what this version will be used for,
We know who we are building the solution for and which problems we are going to solve first,
We know what we won’t be able to achieve at the beginning and that’s ok too.
The only thing that remains to be done is to take pictures (several people do it, just in case!) and store the physical elements. Based on these photos, I will prepare a virtual map (for example in Excel) a few days later. It will be the last stage of the workshop.

Now we only need to get back home. Everything runs smoothly and we land in Pyrzowice late in the evening.

Epilogue

After the described workshops there were others, and soon afterward the project was finally scheduled to start.  Unexpectedly, we got news about a delay. The postponement was caused by the results achieved during the workshop – this was the message, more or less. What did we do wrong?
On the contrary! During our meetings, so many questions and unfinished threads emerged that the project team needed another few weeks for preparations.

Was this a success or not? I will leave you with this question.

If the subject of User Story Mapping is close to your heart and you want to learn more, both theory and practice, I have good news for you. We will soon be practicing this method in workshops. Stay in touch so as not to miss this event.

_{Article written by Artur Guła, Senior Analyst.}