When I heard people talking about “story mapping” I was intrigued. Especially as they explained it as a way to bring user stories to life. A user story is a simple but very effective tool to help design and develop (online) products, taking into account the end-user perspective. A story is typically written up in simple, everyday language capturing what a user does or needs to do as part of his or her job or to satisfy a certain need.

For example: “As an event coordinator (role), I need to be able to create an event schedule online (goal) so that I can access and amend the schedule whenever or wherever I want (benefit).”

Typically, these user stories get drafted and maintained in an excel spreadsheet where product or project managers can easily order and prioritise them. In the Agile development world this is often referred to as a feature backlog.

Jeff Patton is a well-known user experience (‘UX’) specialist. His main bugbear is ‘flat backlogs’ i.e. a static backlog of user stories, ranked in order of priority or value. I agree with his point that a lack of context is often a great risk with these backlogs. One tends to forget about what the overall system does or is supposed to do. It was Patton’s dissatisfaction with ‘flat backlogs’ which led to the creation of ‘story maps’.

These are the main things that I have learnt about story maps from having used this technique previously:

1. Not looking at user stories in isolation – It’s easy to have a good overall idea of what a system should do, break this down into high-level features (and put these into a backlog) and to then come up with user stories for each individual feature (when one gets to work on it). The risk with this approach, however, is that one loses the overview of how the different user stories interact, of how the overall system is supposed to work.
2. Thinking things through – I’m with Patton when he says “A story map, initially, for me, is about thinking things through and understanding user experience.” Physically laying out the different user stories and connecting them helps people to both maintain context and to identify bottlenecks or dependencies.
3. It is a collaborative experience – One of the things I most like about story mapping and similar exercices is that it enables a group a of people to be involved in the process. I’ve got good experiences with cross-disciplined teams discussing the different scenarios, user stories and identifying pain points in the process. It brings discussions out in the open and gives people an opportunity to pitch in, adding their own unique perspective.
4. A walking skeleton – The other thing that I really like about Patton’s story mapping is how it distinguishes between the “backbone” (a term originally coined by Dan Rawsthorne) – high level activities or outcomes that cannot be prioritised – and “ribs”, the actual user stories which can be prioritised. It helps to visualise the story map as a vertebrae, like Patton does: the big things on top are the critical things that a product needs to have – the minimum marketable features – whilst the ‘ribs’ (the user stories) get prioritised (see Fig. 1 below).
5. User stories hanging down from the backbone – As I outlined in the previous point, the backbone doesn’t get prioritised. Instead, one moves the most critical user stories as high up as possible on the story map to stress their importance. When you do this, you’ll find that all the stories placed high on the story map describe the smallest possible system you could build that would give you end-to-end working functionality. This is what Agile specialist Alistair Cockburn refers to as a “walking skeleton”, a minimum viable product (‘MVP’). When creating a new product from scratch, I always try to concentrate on releasing the MVP first, getting real-time user feedback and iterating accordingly.

Main learning point: I really see the value of Jeff Patton’s story mapping technique. Both in a sense that it really helps to engage with people and that it ensures one doesn’t lose sight of the system as a whole. Being able to distinguish between the ‘backbone’ and the ‘ribs’ is another advantage of using Patton’s technique. Having more context around user stories and being clear on the critical nature of a story really helps in designing and developing products.

Fig.1 – Sample story map (source: http://agilepmstudent.blogspot.co.uk/2012/06/how-to-create-user-story-map.html)

Related links for further learning:

http://www.agileproductdesign.com/presentations/user_story_mapping/index.html

http://www.uie.com/brainsparks/2011/10/07/jeff-patton-story-mapping-for-ux-practitioners-tying-agile-and-ux-together/

http://www.learninggeneralist.com/2010/01/agile-bengaluru-2010-jeff-pattons-story.html

http://www.agileproductdesign.com/blog/the_new_backlog.html

http://www.slideshare.net/agiledays/rawsthorne-dan-scrum-the-big-picture-12164857

http://alistair.cockburn.us/Walking+skeleton

http://www.youtube.com/watch?v=KSsWm1LxEQQ

http://www.youtube.com/watch?v=Zg5MBYDn9pc