Story mapping: Set context, align teams, bring focus
Story mapping is without question one of the most powerful tools I’ve come across during my time working in product engineering. It showcases the breadth and depth of a product, yet somehow manages to do this concisely. Nothing seems to cut through complexity, focus a team, or facilitate conversations quite like it. And, when you boil it down, it's an incredibly simple technique to deploy.
Are team members unsure why they are working on a feature? Are you struggling to decide which area of your product to focus on next? Are there orphaned components within your product, shrouded with mystery? Do teams lack identity, seemingly unaware of their place within the wider product and organisation? I’ve seen story maps help with all of these problems, and plenty more to boot.
What is a story map?
It is a straightforward way of decomposing and visualising the capabilities of a product or service, be those existing or potential future capabilities. Story mapping (sometimes also referred to as user-story mapping) is best suited to products that have a linear flow to them, but this is by no means essential.
Jeff Patton first wrote about the subject back in 2005 and has touched on it in various publications since.
What does a story map look like?
A story map can be created on a wall using post-its, or digitally using Miro or similar.
From left to right, high-level capabilities are listed one after the other, in the order that a user would usually undertake them when using your product or service. These are generally written in a verb / noun format, such as “Find product” or “Manage order”.
Under each high-level capability, lower-level capabilities are listed out in the same format, top to bottom in the order that a user would typically step through the activities.
The example below shows what this might look like for a simple e-commerce product.
Where can story mapping add value?
- Illustrating the existing capabilities of a product and fostering a shared understanding
- Outlining the findings of discovery work - which capabilities will meet user needs and which won’t
- Prioritising ruthlessly, determining what minimum viable product (MVP) looks like, and cutting work up into slices
- Deciding between different approaches to deliver the same capability
- Working out how best to split out a product engineering function into teams
- Surfacing dependencies between teams, as well as between stories
How do I create a story map?
If you are story mapping an existing product, you’ll need access to someone who knows the product well, or you’ll have to ensure that you’re sufficiently familiar with it yourself. It helps if you have a version of the product in front of you that you can traverse without impacting your business, such as a development or test environment. Create a first pass yourself, then share or play back to others for feedback.
If you are looking to map out a future state, it can help to have a collaborative session where attendees come up with candidate stories and talk through them as they add them to the map. It helps to keep these sessions relatively small (perhaps just the team, or several key stakeholders), to be clear on scope and desired outcomes, and to start with a story map of existing capabilities to help frame conversations.
Common dimensions that need consideration when creating a story map include:
👤 User - A story map per user is not uncommon, or if the domain is simple enough, one map could cover multiple users, where it is made clear which stories belong to which users.
📲 Channel - It is rare to combine channels in a story map. If a user can update their payment details over the phone, on the website, or on a mobile app, you’d probably see each of those as individual stories on separate story maps.
🏷️ Functional area / theme - Often used to help readers follow the user journey, and can provide handy break-points should a story map get so big that it warrants further decomposition.
🔎 Fidelity - I’ve usually found getting everything out onto a board is the best place to start - so stories of all levels. Once they’re on there, you can begin to order and group them, which will usually lead to three levels of fidelity listed out below:
- High-level capabilities: Sometimes referred to as epics e.g. “Find product”. Rolling a story map to just high-level is useful for providing context to newbies and where high-level conversations are required, but is rarely used in practice.
- Feature-level capabilities: Of the size that you might feed into a product engineering team e.g. “Cancel order”. This is the most common and most useful level of fidelity.
- Sub-feature capabilities: Can also cover variations that may provide the same or similar capability e.g. “View Trustpilot reviews”, “View internal reviews”. This level of detail can detract from the accessibility of a story map but can be particularly useful when visualising and debating potential future stories.
🔪 Slicing - If you are using story mapping to help you plan out a team’s focus, it can help to group stories together in batches, or slices, and indicate the order in which you plan to tackle them. This is particularly useful for new propositions, where you know for certain that you need to have key capabilities in place before achieving any sort of viability.
The illustration below shows how some of these dimensions might be reflected on a story map.
Any other story mapping tips and tricks?
Here are ten things I wish I knew when I first started using story mapping:
👉 Don’t make it do too much. If it becomes inaccessible due to size or complexity, chop it down. Service blueprints are a better tool for capturing the finer details.
👉 Story mapping isn't just for products with linear flows. In some ways story mapping can be even more impactful here, as a less linear product can be much more difficult to mentally visualise. I’ve used story mapping to illustrate the capabilities of a B2B API before now with great results. It can help to start with core capabilities on the left and have secondary ones toward the right, and similarly having the most common stories towards the top, paling off to the more obscure towards the bottom.
👉 Be wary of bloating it with candidate stories. Only add them in if you think there is a good chance that you’ll get to them, or if you are emphasising that those stories don't make the cut.
👉 Set a regular reminder to ensure you keep it up-to-date. Regularly referring to your story map will help to keep you honest, as will making it a flagship artefact for anyone learning about your team, and a must-read for new starters.
👉 Don’t be afraid to tailor your story map for the job at hand. Weighing up two epics? Go granular on those and roll up the others to high-level, greying them out to give you the focus you need. Trying to determine MVP? Stick a prominent dotted line around the stories that you believe to be in scope so you’ve got a starting point for the conversation.
👉 Be pragmatic on naming and granularity. Ideally, your stories will be around the same size and labelled consistently, but there are always outliers. This is okay.
👉 Try not to over-slice. Four slices are probably too many. One slice is likely enough to get you going.
👉 The verb / noun naming convention leaves lots of room for interpretation. Be sure to use consistent terminology that resonates with the rest of your organisation, and if in doubt include a supporting one-pager that elaborates further. Linking to other artefacts and including images can also help.
👉 It always helps to be mindful of what you can defer, or avoid altogether. It can be a useful exercise to step through any potential future capabilities and rigorously challenge how else those user needs could be met. Could they be met offline, or via another channel? Could they continue to use the low-fi process that they currently use? Could they be handed off to another product entirely?
👉 There is no “right answer” for story mapping. Someone else would come up with different terminology, different ordering, and different levels of granularity. Don’t let this hold you back, but take on board feedback and tweak as you go.
In summary 📋
There are few better ways to visualise a product domain and develop a shared understanding of what a product does and how it is used.
Story mapping is an incredibly useful technique, whether you want to boost awareness of an established product’s capabilities, spot gaps in an existing proposition, or contemplate what a new product might look like.
