Building Collaboration between Product, Design, and Stakeholders with Story Mapping

What Is Story Mapping?

Story Mapping is a visual map of the user journey as a narrative flow from left to right, along with the user stories or tasks from top to bottom, to support those activities. It informs how the new functionality fits holistically with the existing functionality. Most importantly, it keeps the project focused on delivering value by continually addressing the user value items along the user journey through your product.

Where Documentation Fails, Collaboration Wins.

The inventor of story mapping is credited to Jeff Patton, who literally wrote the book (User Story Mapping: Discover the Whole Story, Build the Right Product) on it. He believes that teams often rely too much on written documentation without enough collaboration and verbal conversations to challenge the problem and keep the intended users’ needs always upfront. Strong products and results can come from these conversations because misinterpretation from written documents is avoided.

Story mapping keeps us focused on users and their experience, and the result is a better conversation, and ultimately a better product

- Jeff Patton

How We Use Story Mapping at BigCommerce

One of the most difficult parts of any project can be getting into the smaller details of a goal without losing alignment with the various stakeholders and teams. Using a detailed visual map as such, can help keep every person and moving piece informed and included where necessary.

Designers

How can a designer see the whole picture — starting at a high level and slowly get more and more granular? How can a designer see how the project overlaps with other teams/functions? See themes where redundancy is happening? Is that a necessary redundancy or a need to simplify and remove? How can I break this problem down in bite-size pieces by laying it out as a map across the entire experience as it already exists today along with where we want it to go in the future? The visual journey and task map help a designer strategize and wrap their head around complex problems while avoiding adding too much complexity to the solution. Thinking about design as a user-story and jobs-to-be-done

Product Managers

A product manager hopes to align designers, developers, and stakeholders as accurately and efficiently as possible. The best way to do such is typically bringing the right people into a room to collaborate around the problem. Once the story-map has been flushed out and iterated upon, product managers can easily commit those mapped stories to the project’s backlog of epics and tasks. Utilizing the right tools, this can also be done so digitally by linking the story map to tickets. So rather than having a scrolling, sometimes hard to navigate list of user stories, the end-to-end story can be quickly analyzed and shifted as needed. A flushed out story map can be useful for explaining context for any members of the execution team or internal stakeholders.

Other Stakeholders

When stakeholders would like to see how things will be prioritized and dependant on other stakeholders and teams, a story map can quickly articulate that vision and cross-functional challenge. It can also help build empathy across teams, stakeholders, and the project leads, for the full scope of the project can be quickly scannable. Meanwhile, the heavily detailed content can be tucked and linked to (in digital format) for deeper dive discussions.

The following are some of the ways that story mapping has helped us improve processes for building products users will love.

• Focuses on user value while prioritizing the work
• Drives clearer, better-sized requirements
• Exposes risks and requirements
• Drives team transparency and alignment
• Delivers value faster

Planning a Story Mapping Exercise

Any exercise or workshop takes planning and preparation. You’ll be asking multiple people for their time, so capitalize on that by knowing what you need to accomplish with all of those smart heads in the same room at once. However, story mapping takes less planning than you might think.

Don’t overthink while planning.

Firstly, you’ll need a small list of what tools your team can best utilize to collaborate. If you’re in the same location, sticky-notes and sharpies work best. A cloud-based collaboration tool like Miro, Trello, or Mural can substitute for paper if your team is remote from you. Even better, start on paper and whiteboard (if possible) and then transfer to a digital format for updates and continual access.

Sometimes it’s best to take the first pass on your own, at least for the top-level concepts and steps. Providing these key concepts to the participants/stakeholders will get their brains working.

Facilitating a Story Mapping Workshop

If you’ve done a little planning, facilitating should go smoothly. Utilize what you’re used to for workshops, like simple decks to display the steps. But this is absolutely not necessary. Below I’ll frame the key processes to work through.

1. Frame the problem.

For example, “Shoppers want an affordable and efficient way to simplify their meal prep.” Keep it simple but something that addresses the theme of the solution that is being implemented.

2. Map (existing) user activities.

• Start out with the high-level user activities, or the backbone of your product.
• Group and label those sections, like Discovery/Sign up, Store setup, Store design, Catalog creation, and so on.

3. Interject the journey with ideas where the problem could be considered. Frame these as potential user task stories.

• Now, where does the new problem make sense to add new user needs and tasks? Add those below the appropriate activities and sections. Don’t worry about redundancy or scope and complexity right now.
• Add additional steps of the user journey that were missed in the first pass of step two.
• Add a keymap to explain the color-coding.

4. Add tags to specify teams and themes.

This is a great time to convert your story map into digital form utilizing a product your company has access to. This one pictured is utilizing Miro with their tagging functions, and Jira integration.

A few others that work great for this are Mural, Trello, and LucidChart. Some of these have excellent tagging functions and syncing capabilities with Jira, Slack, Google Drive, Box, Dropbox, Github, Salesforce, InVision, Sketch, Figma and more.

• Consider what tags will best serve your organization and teams.
• Status: discovery needed, in design, prototype testing, dev in-process, dev complete, etc.
• Marketing, design, back-end, front-end, security, etc.
• Teams, pods, experts, stakeholders of specific sections may be called out in a swimlane above the story map.
• Add your own custom tags where needed.

5. Collaborate with the appropriate stakeholders to determine release buckets

Now is time to organize the user-stories in releasable phases.

• Consider what items are dependent on each other.
• Which user stories deliver the most user value? You may need to do some user research to get the answer to this.
• Which stories deliver backbone dependency needs for multiple stories? You may need to ask the technology experts to determine these.
• How many releases are you planning for?

Tips for Success

When organizing the batch of features and functions for your project, keep these details at top of mind, as they are directly recommended from Jeff Patton, the creator of this process:

• First focus on use-cases where the actors are a single user and the system.
• Avoid use-cases that describe the internal workings of the system.
• Avoid use cases that define processes at a macro level; make them what author Alistair Cockburn calls “sea-level system scope use cases.”
• Include a user of the feature in a concise story statement, practitioner Rachel Davies invented: As a [type of user] I want [some particular feature] so that [some benefit is received]. For example: “As a bank customer I want to view my current account balance so that I know my recent deposit went through.”
• As you plan your releases and bucket your stories in each, scan the features for dependencies that might not be in this release or a prior one. Starting from the top and addressing dependencies as you bucket horizontally and move your way down, you’ll run into fewer dependencies that you haven’t already resolved in a previous release.
• Avoid adding features that don’t address the users and their needs. (ie branding updates, migrations and tech debt. These types of features don’t play well with this model.
• When bucketing a set of features within a release, discuss how valuable and usable that release will be for your users. Will the user still gain value with this release? Will they be able to have workarounds until the next one? If the answer is yes, consider releasing smaller and faster, with the fully sophisticated version releasing later.

Challenges & Learnings

• Don’t let your crew get too micro or detail-focused early on.
• Organize an onsite assistant facilitator if you’re facilitating remotely.
• Consider adding additional layers of information. What teams or pods are experts and contributing over each section? Add those in a lane above the map.

Conclusion

This practice can lead to better results: aligned teams, more efficient meetings, better sprint velocity, and successful products with much happier users. Remember that the story map will always be a work-in-process and iterative item as your team learns things through the process. Further conversations and discoveries will inform where you need to make changes. The story map is designed to be adjusted and flexible to change.