The idea of user story mapping can be traced back to Jeff Patton. He literally wrote the book about it, It’s All in How You Slice It, which came out in 2005.
Patton is a consultant who helps companies work in a way that’s more focused on building great products, not just improving production speeds. He does this through a mixture of agile, lean and lead, UX design and design thinking startup frameworks. His holistic approach is about using stories but not forgetting the big picture.
What does that all mean? It sounds nice enough. Everyone likes stories. The human mind appears hardwired to understand reality through narrative. Are stories just as useful in business for understanding the customer journey?
What Is a User Story?
The idea of a user story as it applies here comes from software development and product management. When they’re talking about a user story, it is meant as an informal description of one or more software features, spoken in plain English.
A user story involves a persona, an action and a benefit. Here’s an example of a possible user story, “As a project manager, I want to print out my Gantt charts, so I can hang them on my office wall.” The persona would be project manager; the action would be printing, and the benefit would be hanging the Gantt chart on the wall. This simple user story helps the development team better understand how customers use a product feature in the real world.
As you can tell, the user story is often written from the perspective of the end user. These user stories are collected on index cards, Post-It notes or in project management software. The authors can be stakeholders, such as clients, users, managers or the development team. The idea behind this concept is a means to facilitate communication. User stories help teams organize the ideas behind the “why” of the product and its context, to create better software for the target audience.
The benefits of user stories are perhaps anecdotal. There is no empirical data to say that they increase software success or developer productivity. That said, they help teams make more sensible choices without causes problems.
What Is User Story Mapping?
User story mapping takes the user stories and places them on a graph. The graph is two-dimensional visualization of the product backlog. The top of the graph or map are headings under which big stories are grouped. These are called epics, themes or activities, meaning large collections of user stories. The user stories are collected vertically, under each epic theme and ordered by priority. This allows for even large products to be described without losing the big picture.
User story mapping is then a way to organize and use those user stories in an agile environment in a simple yet effective method. It helps teams envision the entire product or service in terms of a series of tasks that the user completes.
How to Develop a User Story Map
To make a user story map, first identify the features of the product or service you’re creating. Each of those features is a heading to the story map you’re creating. They run horizontally across the top of the graph.
Then underneath each of these feature topic headings come the user stories that are related to it. The user stories don’t have to be very well-developed yet or even prioritized at this point. You just want to collect them under the correct heading. As more research is done, and more direction comes from the stakeholders, more detail is added to the user story. You’re refining the user story by breaking each one down into smaller pieces or tasks. It’s at this time where the order of those user stories will reflect the order in which they occur in the user journey.
Story mapping, like the larger agile framework, is an iterative process. It comes from conversations between team members and stakeholders on ways to best deliver more value for the end user and the business. This dialogue starts early, and the story map captures that conversation in an actionable format.
Why Is User Story Mapping Important?
The user story map is a helpful tool for many reasons. As noted, it provides a space to collect the conversation between the stakeholders and the team to figure out what is important in developing the product. It then allows for those user stories to fall into the context of the bigger story, so that they’re positioned in order or importance.
The story map, like the product, should be a work in progress. It’s like a snapshot of what the team is thinking at that moment in the project. Therefore, it’s a means to validate assumptions about the project and make sure that the team is progressing in the right direction. It acts not only as an organization tool; it also repeats a statement back to the person who spoke it to ensure both parties understand one another.
It’s also a visual way of thinking, which is helpful for people on the team and stakeholders who process things better this way. Because it is a visual tool, it allows one to see the whole picture at a glance and where the smaller parts fit into that whole. This also makes it obvious to team members when there is a hole in the process.
Because the user stories are collected in a user story map, they can be moved around to see which sequence would best service the process. This sequencing allows the team to figure out what user stories must be included in an incremental manner.
Prioritizing, which is a major part of user story mapping, helps with efficiency and productivity. This helps to avoid wasting time by focusing on features that are not critical to the end user. That’s because you’re not only prioritizing but also keeping in mind the big picture, which keeps teams out of the weeds.
There’s also the communicative democracy of the user story map. It facilitates communications and provides a shared understanding of the project for teams and stakeholders. No matter where you stand in the project, you can look at the user story map and know the big story down to the smaller parts that make it up and how that all relates to the product roadmap.
Challenges to User Story Mapping
Many of the downsides to user story mapping are related to errors in execution. I’ve listed a few below.
Too Much Detail
If you attach too much detail to the user story then you run the risk of distracting the team. It can create undue risks, such as missing a crucial part of the conversation, as if the signal is lost in the noise.
Another problem is if your user story is too generic. It needs a certain level of detail, that sweet spot, in order to function correctly. If you’re too broad, then issues can arise when extracting functions in a given iteration. Don’t get too formal, either. Remember, the language should be plain, simple and easy for everyone to understand. When you use formal language, it can again distract from the user and lessen the readability of the description.
Some fall into the trap of using technical parameters masked in user stories. The listing of technical tasks rather than the user history will help blur the important step of prioritizing those tasks. For the prioritization is based on the end user and not the mechanics of the production. That said, there are some dangers to be aware of, even when user stories and mapping are done correctly. There is the focus on bugs or purely systemic tasks, which can take away from the main thrust of the project.
Disconnect Between Management & Development Team
The user story can be understood differently between the stakeholder and the team. A lack of information in terms of the methods used to develop and design can stymie developers, while focusing on business functionalities might miss important technical ones.
If you’re looking for ways to communicate and breakdown your project so it better serves the end user, then you need a tool that has the power to make communications seamless and organize your tasks on a shareable platform. ProjectManager.com is a cloud-based project management software that gives your team the collaborative tools they need to run agile projects. Try it today with this free 30-day trial.