At Devbridge, when we work with our clients on projects, it’s essential for everyone to understand the big picture. When our clients have a hard time visualizing and communicating their vision and strategy, we help by working with them to create a visual product roadmap.
To accomplish this, we often use an approach called “story mapping." This technique leverages lean requirements gathering practices to quickly identify, prioritize and plan a product roadmap. With story mapping, we can quickly obtain a shared understanding of the product vision, scope, priorities and delivery strategy.
Step One: Brainstorm
The first step in the story mapping process is brainstorming. To do this, we gather client stakeholders and Devbridge team members in a room to discuss the business problem we are trying to solve. This helps to justify the business need for the product, set the context for the roadmap and identify the target market users.
We then brainstorm features that might solve the identified business problems. We do this by asking the audience to write down their ideas on sticky notes. We then have attendees randomly place these notes on a wall and explain each idea to the audience. This approach encourages creative thinking and the open nature of the discussion leads to rapid ideation. The act of moving around gets participants more involved and keeps ideas flowing. The group participation aspect of the exercise prevents any single voice from dominating the roadmap, and the disorganized method of presentation allows the group to focus on idea generation.
To see how this works, let’s say we want to host a party at our place for our friends. We start by getting some of our friends to help generate ideas. Below is an example of the outcome from our brainstorming session.
Step Two: Organize
Now that we have a collection of thoughts and ideas, we can organize them. We do this by placing similar ideas, or user stories, into groups that are commonly referred to as epics. We then give these epics a name to describe the items in the group. In our party example, we used blue post-it notes to indicate the epics below.
Step Three: Prioritize
Now that we have organized our stories into epics, we need to identify the priority of how to deliver these items. This step comes in handy in situations when we run out of time or budget. When this happens, we can drop lower priority items while ensuring high priority items are completed. For more understanding on how to prioritize a product backlog view our article on how to manage successful Agile sprints.
We need to prioritize epics as well as the stories within each epic. High priority user stories are placed at the top of the epic list, while high priority epics are placed towards the left of the story map. User story and epic prioritization is performed with your stakeholder group in order to obtain a shared level of understanding around product priorities. By organizing information in this manner, we now have a framework to understand the project scope that can help identify gaps in your backlog. You can see how we’ve prioritized epics and stories for our party below.
Step Four: Plan
At this point, we break our stories out into different iterations in order to quickly produce valuable product increments. The first thing to do is identify increment goals, and then determine what user stories will enable each increment goal. When you read through your collective release goals, you should be able to understand how these goals will solve your business problem. During this step, we need to consider dependencies, blockers, risks, and parallel activities to determine which stories can be added to a given iteration. We use iterations to incrementally deliver value as soon as the iteration goal is completed.
In our party planning example, we broke our plan into four iterations. By reading each iteration goal we can understand how the party plan comes together. The output is a clear and simple visual representation of our roadmap.
Step Five: Execute and Iterate
The purpose of Agile is to be able to quickly adapt your plan based on new information. As a project progresses, we may need to modify our plan based on what we learn. For example, we may need to add new user stories to the project or quickly change backlog priorities. When this happens, we can easily revisit our product roadmap, and decide how to adjust our plan based on this new information. If we need to add scope to the project, but cannot add resources, then we will drop lower priority items to make room for higher priority items.
Let’s take a look at how this works with our party planning example. Suppose that, after we complete our trip to the grocery store, you find out that an invited guest recently received a promotion. To celebrate, we should buy them a gift and some cake. Since we have a set amount of time before the party, and determine that these new items are higher priority than some of the existing items on our roadmap, we will need to adjust our plan.
In this case, we need to add a trip to the bakery and the gift shop. However, making a trip to both places will leave you with no time for setup before the party. To solve this, we decide to buy a bottle of wine at the liquor store for our gift, go to the bakery, and remove setting up a movie from our roadmap since we don’t think that is a priority. We now have the newly modified story map:
We now have a well thought out party plan that clearly communicates how we will execute it. Story mapping is not only useful for brainstorming ideas, but it also helps us effectively communicate and iterate our project plan. If you need help building a product roadmap, and are interested in how story mapping might be able to help your business, let’s talk.