Exercise Introducing Story Maps

When doing Product Owner training I have introduced the concept of story maps to the attendees for the last year or more. The problem has always been the same though. You need to do an exercise before people really get it but an exercise involving even a small example or the trainees own context always ended up taking way too long or became too simple to be of any real value.

It seemed that creating a vision, Identifying the backbone, identifying personas/users and creating high level user stories from walking them through the backbone proved simply too much to do in an hour or less even for simple examples and way too much when people had to do it for their own context. I went back of forth, putting more or less weight on the individual elements but still really was not satisfied with how it went.

Therefore I started thinking “what is the most important thing I want people to learn from this”. It turned out that what I really wanted was to make people aware of was the power of the story map as a tool for discussion and communication and how when prioritizing and planning, a 2 dimensional story map will generate insights far beyond those you get when doing this using a traditional one dimensional backlog.

So the goal became to create an exercise where the groups would use most of the time exploring this. To do this I decided to create an example of a product that everyone would be able to relate to, create the vision, identify users and even write the user stories. To try to make it as realistic as possible some user stories would be interdependent, redundant, obsolete, missing etc.

The result became the exercise named “hairdresser.dk” described below. I have been running it four times now and it works really well. Teams come up with very different "walking skeletons" and the story told can be very different. What matters most though is that they get into real discussions about value and MMF's, and some tell me afterwards that Story Maps was probably the most important thing we covered in the entire course.

Here is how it works:

Purpose: Giving people an idea about what a Story map is and how it can be used to facilitate prioritization, release planning and finding MMF’s

Before the exercise I use about 10 min. to describewhat a story map is. Then I roughly do it this way (You might want to twist the “story” a bit. The one below is just the basic version)

Setup: Divide people into groups of 5-8 and hand each team these user stories and vision http://dl.dropbox.com/u/2095335/hairdresser.dk%20English%20Version.docx. Draw the following backbone on a whiteboard – one for each team.

• Log ind
• See available
  appointments
• Book appointment
• Confirm
• Change
• Remind
• Admin.

Story: Tell them they are both hairdressers trying to set up a business in a small town and will be competing for the same customers as well as against existing hairdressers. Market research shows that this particular town is filled with young people eager to have a more flexible
and easy way of booking hairdresser appointments and that given the opportunity to do this online, whenever they want, they would turn away from their prior hairdresser. It does however have to very quick and intuitive for them to make this transition.

Time to market is key and the first hairdresser on the market with an online solution that customers accept will likely survive while the other will go bankrupt within a very short while.

Timeline: Give them 10 minutes to go through the user stories and place them in the “right” column on the backbone (there is no right or wrong). Then allow 20-25 min. to find the “Walking Skeleton” and the content of the next 2-3 subsequent releases.

The winning team will be the one that can offer the most convincing story on why they chose to balance functionality and time-to-market the way they did. Having a theme/vision for each release will give them extra points but of course the most important thing is their story and the arguments they use to explain why their release plan is the best one.