A product is more than a single user flow, but when collected with other flows, the shape of our product begins to emerge. As we rarely create products in vacuums, the outside world will start applying the pressure of time, resources, and capital constraints on our work.
This pressure forces us to make smart decisions about how we prioritize work and communicate those priorities to the team and stakeholders.
When working in the industry, you’ll encounter user stories that are either assigned to the current build cycle or the backlog. This either/or approach often creates an inability to track the project over time because it fails to communicate anything beyond the current iteration or sprint.
The backlog is where tasks that do not have the highest priority wait for reconsideration for the next build period. Because everything in the backlog has the same level of priority, it becomes an issue for both teams and stakeholders because it doesn’t provide a sense of direction. The closer you get to the end of a sprint, the more time you spend communicating and debating the next build cycle.
It becomes easy to get lost in the details of the product. Without insight into progress, you lose sight of where you are going. When this occurs, the small chunks of product development that Agile introduced suddenly begin to feel like unrelated items being glued and stitched together. This moment means that your work has crossed over into the realm of dreaded Franken-product. Few teams can maintain their momentum in this space for long.
These are significant hurdles that few tools that can handle, but author Jeff Patton stumbled upon one when he created Story Mapping.
“Story mapping keeps us focused on users and their experience, and the result is a better conversation, and ultimately a better product,” Patton said regarding the of his creation.
As a discipline, Story Mapping is still very young. Patton first blogged about the method in 2005 before eventually releasing User Story Mapping in 2014.
While intended to be a team exercise, Story Mapping is beneficial for anyone working on a product that will take more than a week to accomplish. A story mapping board can display the scope of your endeavor while showing the details arranged by priority over time. This level of visibility allows anyone to discuss the project without having to be briefed. With Story Mapping, you’ve already done all the work needed.
The core components
Every story map contains a small set of parts that help our team and stakeholders orient themselves to the project.
Direction is associated with time. Across the top, left-to-right movement tells the narrative story of your project and the order in which you are building it. This area is the Backbone. These are the large scale elements that your project is attempting to do.
Source: newpragmatic.com
Details are associated with each task, and when reading top-to-bottom, you can see the order of priority for each job. A line further enhances order for the backlog, where order establishes priority again. These controls allow us to see what details will be worked on next.
It takes less than a minute to orient a team to a story map, and the tool is most helpful when it is visible to all. Creating a public space at work to display a physical story map provides a sense beyond your immediate team regarding how people are spending their time. Additionally, there are digital versions available using platforms like Miro, which makes displaying your progress to teammates easy wherever they are.
Populating the board
To properly prioritize, we must first gather our prior work and organize it so we can visualize the scope of our work. Whether you display the smaller user stories or, the more elaborate user flows will depend on the organization. I prefer to build a story map after the user flows because the details needed to scope the work properly are available.
Some tasks will be longer than others, and that’s ok. When completed, you’ll have a board that looks something like this:
Source: newpragmatic.com
Adding priority
Each flow you have added to the board has critical tasks that will render the flow useless if removed. There will also be optional aspects of your work present that are less vital.
When adding priority to the tasks, your prior interrogation of the flows is beneficial. Without that effort, your flow would likely be missing steps, and you would lack the critical evaluation needed to make some decisions.
When applied, your board takes on a new form with some noticeable gaps:
Source: newpragmatic.com
Now you can communicate the intended direction of a project with greater clarity. The arrangement shows project scope while displaying priority for the path ahead.
Releases must be usable
When you’re building out your first products, it can be tough to understand what makes a Minimum Viable Product. An MVP is an early version of your product that can be used by users for testing to capture feedback.
The first MVP your team will produce is unlikely to make anyone particularly proud — and that’s a good gauge to measure the work. MVPs are meant to be rough to minimize time and expenses spent. The prototype and testing stages are when you perform the bulk of refinements on the project. Therefore, the quicker you can get your MVP into testing, the lower your production costs.
The structure of your story map plays a direct role in whether you have a testable initial MVP to work with after the initial cycle. Incomplete prototypes require more work before testing and drain momentum from the project.
Source: newpragmatic.com
Think of your MVPs like the evolution of the phone. Humanity didn’t wait for Steve Jobs to walk out on stage and call Starbucks on the first iPhone to kick off the age of telephones. It took over a hundred years of product iterations before we got to the smartphones we recognize today. Before the first successful call, Englishman Alexander Graham Bell was testing the ability to communicate via electrical signals for years before breaking through in 1876. Without building testable MVPs, he never would have had the feedback needed to guide him to success.
Like Bell, our goal is to create MVPs that can be used to generate feedback. That valuable information will inform each step that follows as we steadily improve our products.
Every project grows
When you create a pattern for your map, it is essential to remember that it is still very malleable. You will be adding new information long after your initial work.
The feedback generated from prototype testing will create new stories that could alter the Backbone of the map. Just as quickly, new details could be added to existing tasks, added additional release cycles into the conversation.
Your story map is a living document that will be altered and updated many times throughout a project, so use it as a centralized tool for progress. Update your map regularly and track new developments with it.