Implementing Story Mapping

How we have used ‘story mapping’ to map out initial system complexity and start building our roadmap and fleshing out our backlog.

6 min readAug 23, 2018

Co-authored with Edward Earle, CTO at The Acorn Collective.

As product manager at The Acorn Collective my role has been bringing together teams and individuals to build a brand new product. In this post, co-authored with Acorn CTO Edward Earle, we seek to explore why we implemented story mapping to kick off our development, the challenges we faced and how overcame them.

Acorn’s vision is to build a crowdfunding ecosystem that encourages anyone, anywhere in the world with a suitable idea to explore that idea, and potentially get it crowdfunded. This means building a platform that not only enables crowdfunding, but also builds community and provides coaching.

Delivering a platform of this nature will be no easy feat. To deliver successfully we need:

A shared and clear understanding of what we’re building and its direction
A high level appreciation of the platform users involved and the breadth of their needs
A way to plan an incremental and iterative development strategy

We’d done some thinking on this already, but we realised it was very high level and so far involved limited user research. Therefore we needed a new, living process, where we could actively explore each user, understand their needs and document in a visual, shared fashion that everyone at any level in the organisation could see and appreciate.

On this basis we turned to story mapping.

Story mapping is a concept developed by Jeff Patton, after many years wrestling with backlogs, stories and release scoping activities which just weren’t working any longer. It’s intended to encourage shared understanding and become a living artefact where collaboration and imagination can take place.

Jeff describes an entire wall filled with sticky notes and index cards mapping user personas with their goals, activities and tasks. For example, if my goal was to be ready for work in the morning I might perform a number of activities, including eat breakfast, take a shower and get dressed. Each one of those activities will have tasks associated with it, such as switch on kitchen light, pour muesli into the bowl, add milk and pour coffee.

It’s these tasks which form the foundation of the product backlog. To find out more read Jeff’s material on his site, or grab his book. (In fact I highly recommend his book, since he digs much deeper in to the role of a user story, and how to maximise its potential without turning it into just another ‘requirement’)

How we approached story mapping

As with anything new, it took a little effort get through the initial inertia, but once in the groove we soon ran out of wall (more accurately, whiteboard) space!

However, as we progressed it became clear that not all the stakeholders involved in were quite sold on the output. There was a feeling of looseness about the direction that had been mapped out, possibly a consequence of the various minds at work in creating the user activities and task. There was also a lack of clarity about how other stakeholders in the business would digest the map, and appreciate how it translated into a workable product backlog. We needed it to be as cohesive and unambiguous as possible.

Therefore to combat this issue we decided to formalise and document the various components of the map, such that anyone could contribute to or read from it with in a unified way. We also created a key to help us remember.

User roles

We determined that ‘user roles’, rather than personas were the foundation of our map, but capturing the personas that fit into each user role provided the benefit of context. We determined that a user role must be given a name describing their role, which would make it a noun.

This descriptive role name would define the ultimate goal of that user — their reason for using the system — illustrated in more context by the persona(s) associated with that role.

Phases

We assigned ‘phases’ to these user roles. Phases represent a distinct part of a user’s journey toward reaching their ultimate goal. They could be considered to be ‘sub-goals’, described using a present-participle.

Outcomes

Within each phase we detailed ‘outcomes’ — that is outcomes which the user is expected to achieve as part of that phase. We used past-participles to describe these.

Actions

Then under each outcome we listed ‘actions’ — which the user performs to reach the specified outcome. We used verbs to describe these these. These actions, like Jeff Patton’s tasks, will form the basis of the product backlog.

Each action will represent one backlog item (or perhaps more, where they may later be split out), and further work to ensure these backlog items are ready for development will be required, such as building acceptance criteria and detailed user experience designs.

We found this helpful because it encouraged us to think in terms of outcome rather than output. We also discovered it was hard to distinguish between a task or an activity, but thinking in terms of ‘action’ provided more clarity.

Another advantage of the ‘phases’ was that we could eat our elephant in chunks. Once we’d identified the majority of the phases we could tackle each one individually, rather than have to thrash them out all at once. This is important for me to maintain consistent flow through the product development timeline — enabling us to start work on what we know and avoid wastage on areas we don’t fully understand yet.

Once we had begun the map, we could start converting the actions into product backlog ‘feature’ items, predominantly as user stories.

What we learnt from story mapping

Building our map in this structured fashion quickly identified areas of ambiguity and misunderstanding.

For example, in some cases we realised we just didn’t know enough about what our user was trying to achieve, or what information we needed from them at that point. In other places we left notes highlighting an assumption or believe that needed to be tested.

In the spirit of stories and story mapping we recognised the map was a focal point around which we could structure conversations and thrash out further details. We could bring stakeholders to the map, quickly show them the user’s journey with its phases, outcomes, goals and actions — then add any output from that conversation to the map, then also to product backlog items as they were created, and refined to get them ready for development.

Clearly not every detail could be represented on the map — and neither should it be. However, each element in the map acts as a marker for further documentation.

Earlier on in the article we mentioned the ultimate goal of each of the defined user roles. It is form this goal that the phases are derived. Careful work should be done to define these user roles, understand the user personas and to define their primary or ultimate goal.

We are pleased we persevered with story mapping. It could have been easy to give up when at first we didn’t succeed. However, having stuck with it we now have a living, shared artefact we can maintain within the business.

Additionally the process of building the map has provided us with learnings we can build on to develop not only a better product, but also a better process.

This is a prime example of being able to take principles from a process or idea pioneered by someone else, and apply them to the content in which we find ourselves. Too often great ideas or processes are unsuccessfully implemented by others because applying them word-for-word doesn’t work.

It’s like following a recipe in our kitchen: when faced with a missing ingredient, a knowledgeable or experienced chef may be able to replace the ingredient with something similar, or adapt the recipe to suit — rather than abandon the entire meal.

Therefore, we look forward to maintaining our story, discussing it with stakeholders and continuing to drive out ambiguity in our understanding. We have further releases to plan, and more phases to flesh out, developing and improving the process as we go.

Thanks Jeff!