Product developer's guide to the story mapping galaxy

Product developer's guide to the story mapping galaxy

In 2005, borrowing heavily from other solutions, Jeff Patton created a two-dimensional visualization for backlogs called "story mapping." It was immediately found to be so effective - especially against its predecessor - that it became a best practice in product development. The concept is simple to learn, but it will benefit developers for the rest of their career.

Story mapping is much easier and more efficient than using a flat backlog to plan product development, and it offers many advantages. This quick overview will show you how story mapping works and how it can improve the product development process.

At Syncroness, we have adopted this technique to a holistic, system-level approach to integrated product development (products that have mechanical, electrical, and software aspects, such as a medical diagnostic device). Story mapping is not just for software anymore!

Shortcomings in the status quo (flat backlog)

A flat backlog is made up of items such as features, bugs, technical work and knowledge acquisition. User stories describe the functionalities your team is attempting to achieve from the viewpoint of the users. These user stories may be arranged in the order you intend to build them, but that process is insufficient to explain to others what the system does.

A flat backlog fails to place bits of functionality, or user stories, within the context of the user's experience. A flat backlog lacks organization, and it is difficult to discern which product features should be addressed first.

A flat backlog is also tedious and time-consuming. Flat backlogs take more time because they do not organize product features by importance to the user and may result in a lot of time spent on irrelevant or redundant functions.

Story mapping vocabulary and visualization

Story mapping solves this by visualizing the entire product functionality set in one overarching storyline. As described by Jeff Patton, a story map begins with a row of cards across the top, which are activities or "big stories." It organizes the tasks done by similar types of functionality (or people, depending on your product) in comparable time frames to accomplish a goal. User activities are arranged from left to right on a story map to represent the user's chronological progression while using the product.

The next row of cards is referred to as the backbone because it provides the overarching narrative of tasks for your story map. Supported by the backbone, the subsequent rows offer details. Subtasks, alternate tasks and exceptions will all be included. Any relevant details to accomplishing a task on the backbone can be added to a sticky note and placed under the task.

Story mapping process and tips

Someone that understands the story mapping process should act as a facilitator. Participants include those from a variety of disciplines, including marketing, sales, engineering, management, maintenance and even end users. It is also important that story mapping is a focused brainstorming session - so no phones, laptops or other distractions. Schedule time for breaks to allow people to check email and conduct other business.

Keep it up for the duration of the project. For story mapping to be effective, it needs to be used consistently throughout the project. While this may seem like a daunting prospect, story mapping (or task tracking) software can make the process easier and allow for easy collaboration of sharing of feedback.

Swap it around as necessary. The modular nature of story mapping makes it easy to arrange and rearrange stories to achieve the optimal configuration. We at Syncroness are big fans of sticky note-based story mapping. Go out and buy jumbo ones for the "big stories," and medium-sized ones for the various ideas and tasks. We also recommend writing in marker on the notes, so that the ideas are easily visible to the story mapping group.

You will also need to have a dedicated meeting room, for at least a day, and often longer. One of the walls (ideally a whiteboard) will become the story map.

Rather than brainstorming the entire story map in one go, break the brainstorming into groupings based on the big stories or sub-stories. This allows the team to focus and is not as intimidating as trying to think about the entire product functionality at once.

story mapping.jpg

Story mapping utilization

You can utilize the user activities to prioritize tasks since story mapping provides a clear picture of what needs to be done and in what order the tasks must be completed. Because story mapping shows the whole picture, it's easy to identify which tasks must be done first. Place higher priority and higher risk tasks towards the top.

Use the user activities to create a minimum viable product; or MVP. The reality is that most product features are never used. Unused features represent waste, and story mapping can be an effective tool for producing the minimum viable product that will meet users' needs.

To create the MVP, take horizontal slices through the story map. Some use tape, but since we put our sticky notes on a whiteboard, we mark up the whiteboard for this. The topmost slice becomes your MVP. This is the first generation release of features and requirements for your product. Subsequent features of later releases are found in lower slices. This focuses your development team from the outset.

Learn more

At Syncroness, we are nimble and quick studies. Our experts have guided numerous customers in the story mapping process to identify precisely what is necessary to produce an MVP and outline the path to upgrades.

We have created story maps on integrated products as varied as rocket engines and medical diagnostic devices. Story mapping has evolved past its software origins, and we are leading the way to its broader applicability in integrated product development.

Contact us now to discover how we can assist you in getting your share of the market and start the cash flowing.

Vital components of product development - Part 1

Vital components of product development - Part 1

Sustaining engineering for medical devices

Sustaining engineering for medical devices