I have been getting very involved with the Business Analysis community at my current client ASOS (Mega large fashion retailer). In the absence of a true Product Owner role here, the job they do is absolutely key.

Over the last month I have been running a series of lunch and learn sessions to compliment some education they have been doing with the BCS Business Analysis course. One of those was user story mapping.

I wrote a 1.5 hour lunch and learn for them and a complimenting guide with all my top tips in.  I wrote this with my good friend Richard Arpino, who works as a ScrumMaster at ASOS. The aim of this guide is so that they can continue to run these sessions once I have left them. Whilst it is not as good and as comprehensive as the book ‘User Story Mapping’ by Geoff Patton. It’s enough to spark creativity and a pull for them to know more about this technique.   …

I was quite pleased with my output and so I thought I would share it in a blog.

Remember it’s part Lunch and Learn and top tips at the same time

Story Mapping Workshop

Learning Objective

This session will give you an idea on how to facilitate a user story mapping workshop. Over time you will develop your own techniques and we encourage you to share these as a community’.

This hand-out will detail running a mock session and where you see the numbered bullets, these are top tips!

Scheduling the Workshop

Once you have an understanding and vision for your work, you are ready to start with user story mapping. These sessions are one of the first things you want to do. There is no need to produce separate requirements documents; this is the start of building your Product Backlog. If you do not have a vision, then this is something you can create in this session also.

We value face to face collaboration and so workshops should be booked to include all business and IT teams involved.

1. Ensure that you have a room with plenty of wall space.
2. It’s ok to only invite a sub-set of the IT team. However, rotate people to allow everyone to have a chance to attend. They then have the responsibility to take this information back to the teams.
3. Don’t panic if you need to have 20 people in the room to cover everything. We can cater for this, but we will need to think about how we run it logistically.
4. Consider how long people can focus for. Working for one day or short bursts over multiple days keep people focussed. With 2 or 3 day workshops, people will get tired and lose energy.

Pre-Workshop Preparation

It is important as a facilitator that you prepare for this session. You will need to:

• Print and add the Vision to the wall – We will need to ensure that we are working to this at all time.
• Print and make visible anything that is definitely out of the scope – We might want to add to this or challenge it.
• Capture Issues, Risks and Actions - Create a flip chart on the wall for each of these. It is a good idea to seek help from someone who can ensure these are all captured and owned. As a facilitator consider yourself as the conductor of the orchestra. You do not want to slow the session down and so having someone else to support with these means you can keep the session moving.
• Create straw man User Roles – You do not have to do this, but the chances are the people in the room have never ever done user story mapping in their life. This means you might have many blank faces looking back at you. My advice is to prepare a sample of these to give people some context. You do not have to have all of them and they do not even have to be correct. People find it easier to review and amend then create from fresh. If you have a fully experience group, then this can be done in the session.
• Create straw man User Journeys – The same principle of straw man user roles.
• Prepare how you are going to explain what user story mapping is in a simplistic, jargon free language. I sometimes practice this with my mother!
• Create & print a simple user story example for the wall
• Create a template to assist in the collection of user stories and data (See Appendix)
• Have plenty of post it notes and sharpies!

Let’s Run an Example Workshop

1. Take photos of everything! It’s a great reminder of what you have achieved once you have completed. It also helps you to show others when you are explaining the technique in the future.
2. Time boxes shown vary from workshop to workshop. You will need to have a think about this about this before each workshop.

The Vision

“Our research has revealed that users want a simple email experience. It should be super simple to use and not require a manual or training of any sort. People only want the basics and hate fussy screens with lots of buttons. They want this on their mobile, tablet and computer with a similar experience in each.”

• Be prepared that everyone might not have the same view of the project. This is a great opportunity to get everyone aligned.

Organise into groups

Split up into groups of 3-4 users. Each of these groups will work together from this point forward as a team. You have 1 minute!

1. Ensure that the teams are mixed in their skills; you can pre-set these before the session if it helps you.

Explain what User Story Mapping is

Many of your audience will not have completed this exercise before. You will need to explain what they are going to be doing. We can use the straw man examples to bring this to life.

Discover the Users (10 minutes)

In your groups, write a list of types of user that you envisage will use your email app. You have 10 minutes to collaborate in coming up with a list of user personas.

1. You can either the straw man or do from scratch depending on the experience of the attendees.
2. Get people to brainstorm as many as possible. It doesn’t matter if they have duplicates.
3. Walk around the groups giving support if questions arise.
4. Sense the energy and the state of completeness of the exercise. Don’t be afraid to end or extend the time box if needed.

Merge the User Personas

Each team gets to introduce one persona at a time. The other teams discard that persona if they came up with it or they can challenge the description if they think theirs is better. If none of the teams has a specific persona, everyone can discuss if this persona is useful and decide if they want to add it to the list.

Decide on the most dominant user persona – the one which describes the largest number of users for your app. This is the one we will start to create the story map for.

1. Consider using different colours for internal and external users.
2. Rationalise the names to a common list and agree that this is how you are going to refer to them from this point.
3. We use the process of diverge and merge throughout this exercise. It can be seen as duplication, but you will find that each group gets the opportunity to discuss and each group will bring out different ideas. It highlights consensus and edge case we need to consider.

Discover the User Journey (10 minutes)

In your groups, you need to think of your dominant user persona’s experience of your software. Write down a series of words that describe how they interact with your software in the order they do so, describing their journey through the software. You have 10 minutes to come up with a list in the order that best describes your user’s journey through the software.

1. Use the straw man you have available or create from scratch depending on experience.
2. Think verbs. This these are doing words at a high level e.g. Browsing, Searching, Buying.
3. Typically you will see about 10 in a user journey. Any more than this might be a signal that they have gone into too lower level detail.
4. These are not cast in stone and can change anytime. Sometimes these merge at a later stage.

Merge the User Journey (5 minutes per team)

Each team gets to introduce their journey. Each team can either place their section under and existing one or insert it between existing sections. The whole team can decide which sections have the best descriptions to create a single merged user journey.

1. Keep it fun!
2. You can either the straw man or do from scratch depending on the experience of the attendees.

This is the story journey or spine, and will allow you to organise your software features in these sections. Once the team has decided on the best descriptions and order of the journey, all of the others are discarded.

Summarise

At this point, talk about what we have achieved so far.

You will now need to introduce Epics, Features & User stories as a concept. During the next stage we are looking for breadth, not depth and so it is acceptable to collect meaningful titles.

1. You will need to consider as a facilitator where you insert the natural breaks. The next part of the exercise is intensive and you might want a break before this. Again energy of the room will be your friend.

Create the features (10 minutes)

For each section, each team takes 10 minutes to write down features they would need to create to satisfy the dominant users journey.

1. We found creating a template (See Appendix) helpful because it set the expectation of format, but we could also collect other information that would help us manage dependencies and teams impacted. This will help you at a later stage. These can be re-formatted each time you want to collet something different.
2. Get them to focus on one section at a time, rather than everything.

Merge the features

Each team introduces the features for the section that we have been working on and introduces them to the rest of the teams. If other teams have the same or similar feature they collectively decide which one to keep and the rest are discarded.

If there are features that only one team has come up with, everyone gets to decide if this is relevant and keep it if it is.

1. It is key that they own this process and so keep them active by getting them up out of their chairs and presenting back.
2. Remember you are facilitating from the back of the room. Use your domain knowledge to stop people going into too much detail. Consider If that conversation needs to be banked as part of Issues, Risks and Actions.
3. It doesn’t matter how important the person is, if they need to be moved on, move them on!

Repeat for all sections

The teams repeat the exercise for each part of the user journey until complete.

1. If you have many workshops I ensure that I gather feedback from the end of each day. If there is something we can do better, why wouldn’t we.

Repeat for all personas

Now you need to repeat this exercise for each of the other different User Personas you have starting with the next most dominant .If you are lucky, then these will fit into the existing journey. If not, then you might have to review the journey or even create a new one if the journey would be significantly different.

• It is not unusual to find many personas, but only a few have active roles within the journey. As long as you check these, then all is good.

Summarise

Take the opportunity to play back to the group what we have achieved so far. We have now got the breadth of what we need to achieve.

• Stories will get added and removed. This is all part of the process

Prioritisation

Prioritisation and slicing helps us to focus on the stories that need to be broken down first. There is no point in getting going deep on details for all the stories if they are not being delivered for several months or could get removed altogether. We want to remove as much wastefulness as possible.

You have a couple of option here

• Each team takes a column and prioritises the features underneath it. The features at the top should be the ones that we absolutely need, the ones at the bottom should be the ones we could potentially live without. Teams than then swap columns and reprioritise if necessary – any items that are repetitively moved are taken to one side for a wider group discussion. This is a good technique for large groups.
• Ask them to all gather around and do this together. Another spin on this is to them to do this silently.

By the end you will have columns of priority.

Slicing

The whole team then look at the map and discuss what could be delivered and what the minimum would look like. They use lining tape to draw a line around the stories in show a slice of functionality. The first of these would be the minimum viable product. The following slices would be increments of functionality.

At this stage we do not know how big these slices are, but it gives us areas to focus on first.

Get everyone to agree that to the best of their knowledge this is ‘it’ for now.

Closing the Workshop

This workshop is only just the start of it; I would always close the work shop with

• Consensus that everyone is happy
• A playback of all the Issues, Risks and Actions and how these will be progressed
• What the needs to be done next to achieve the lower level story information.

Further workshop might need to be booked to get lower level information or we might have enough knowledge, information and contacts to be able to draft these as Business Analysts and then gain consensus from them during the usual refinement process.

Appendix

Example template

Example template

Tweet.