31 Jul 24

Story Mapping

Story Mapping is the one technique I’ve found that gives Product organizations superpowers. Jeff Patton has written the definitive book on the subject. If you have a say in how your team approaches and organizes its work, read Jeff’s book.

This post is part book review and part sharing of experiences. I read Jeff’s book several years ago. Since reading, I have advocated for the techniques described in every organization I have been a part of. Some successful, some organizations never adopted the technique into its rhythm sadly. Those organizations tended to be unorganized in most aspects.

Story Mapping is the exercise of mapping out all of the functionality of your Product or Application in a timeline of sorts. In many cases, it outlines the user journey. Horizontally you see everything a user can do from a high level. Under each high-level item, you see the details. Details are the granular bits that make up the functionality.

Imagine having a map or outline that gave everyone on the team a sense of what your product did for a user written out in plain English. Now imagine that the team is discussing some new functionality. Having the story map or the outline should make it pretty clear where the new functionality fits into the overall picture. Seeing where it fits in will probably shape the functionality as well. How does that feel compared to your current process?

If your current process is someone dreaming up new functionality and trying to articulate it through a JIRA story, maybe start with mapping just the functionality that relates. Run an exercise where you story map out an epic the team has defined.

Story mapping is more than just writing out the functionality in plain English and seeing how it relates to other functionality. Story mapping advocates iterations. Say your product has a sign-up form. Most do so this should be a relatively well-known concept. The major piece of functionality is to enable a user to sign up and start using your product. But with signing up, there are many details to consider. Maybe the first is that it is required the user provides their unique email address. Next is that they provide a desired password. For an MVP that may be enough. But you then decide that passwords need to be a certain length. That can be a follow-up. It can be iteration 1. Get the MVP out the door and allow people to start signing up and follow it up with more validation around passwords. Maybe you then decide that you’d like to capture the user’s first and last name so you can address them properly in a welcome email. Adding the first and last name field can be iteration 2. Arguably, all of this work could be done in a single sprint and delivered. But does it need to be? Is adding the first name and last name as important as other functionality? By thinking in iterations, we can capture the ideas but we can weigh them in relation to other functionality in our map. For example, if the team responsible for sending emails aren’t ready, maybe your time is better spent on something other than capturing first and last name since it can’t yet be used. This may seem granular and super focused, but the combination of capturing data and using it in an email are key bits of functionality. And they can be delivered separately. Maybe iteration 3 is the actual sending of the email.

Story mapping helps new team members quickly grok functionality as well. Depending on the size of your product, even the fastest learner may have a hard time wrapping their head around all of the functionality if it is not spelled out. Why not give them a map? The why not is called discipline. It takes discipline to keep the map updated. It is easy to think a small amount of functionality is a given, or doesn’t need to be spelled out on the map. In the example above, capturing the first and last name is an easy JIRA ticket to write and an easy thing to implement in most codebases. It would be easy to skip identifying it on the map and designating it in an iteration. But without it, the email can’t be sent. Everything should go on the Story Map. It should be a living document. There are plenty of virtual solutions. The book gives the example of using sticky notes on the wall of the office. I’ve led teams in exercises using sticky notes. It’s quick and engaging. I highly recommend it, even if it is just to get started and eventually transfer into a more persistent virtual solution.

Recently, I wrote about using roadmaps as a tool to convey to the team what the future holds. I believe story mapping can accomplish the same and with added context. I’d recommend planning work using a story map and then once the iterations are set, representing the work on a roadmap. My experience tells me you’ll be more accurate and set proper expectations more often.

Story mapping engages the team, and gives everyone a shared understanding, and through practice, the iterations can mean faster, smaller, less risky deliverables. Ultimately that should mean less tech debt, but that depends on the implementation. Story mapping brings together Product and Engineering to work as a single team. I highly recommend it. There is plenty of literature out there but as mentioned at the beginning of this post, I can’t recommend Jeff’s book enough. It’s eye-opening and will give you all the tools you need to get started.

Launch Scout advises its clients to use Story Mapping. https://twitter.com/teamgaslight/status/1382069441870053388

Music companion of this post: Younger Than You — Whirr

What I am working on currently: I am multitasking at the moment: writing some documentation for Schemabook and updates to a WebAssembly app compiled from Rust