Are you having a hard time prioritizing backlog and setting releases?

Let’s talk about Story Mapping!

If you’ve ever participated in a software development team, you’ve probably come across the difficulties faced by product professionals to prioritize the backlog and set releases. These tasks can become even harder without the ideal tools and techniques, distancing releases from key project goals and creating unnecessary features for the product.

To help solve these problems, we will detail in this blog post the use of Story Mapping, known to some and a great mystery to others. This tool was created by Jeff Patton and described in detail in the book “User Story Mapping” by the same author.

At first, by name, you must be thinking that it is just for mapping work items. What if I tell you that by using Story Mapping you can also optimize value delivery for each release, align delivery expectations between stakeholders, and remove the priority for everything that is not essential to delivery? Story Mapping will not save and solve all problems of your project, but it will be extremely useful particularly in two moments: at the project start, when you are creating a product and don’t have a direction to follow, or after a goal change that alters the entire planned scope.

STEP 1 – Assembling the Value Flow

To start Story Mapping, we first need to have a workflow or a Big Story that will tell the user’s interaction with the product, considering the path that the user goes through to achieve the goal that this product proposes to solve. This will be the baseline for Story Mapping.
If you don’t have this flow yet, it can be assembled dynamically with the product owners and the team involved in creating it, displaying their visions of the ideal product features. We typically use the value stream or the main artifact (main product object) to guide the discussion.

STEP 2 – Mapping Stories

The second step is the moment to analyze the flow, identifying steps that have the same context or that originate from the same user action, thus generating the main epics, which will serve as the foundation for mapping work items. The epics will serve as a backbone of story mapping.

It is now time to detail what needs to be done in each epic. These will be the user stories (or work items, if you prefer to call them that) that will be developed. It must be clear that these stories will still go through refinement, which is the moment that we will in fact discuss thoroughly the task details and remove more technical and business uncertainties. The goal here is to just map the work items, not detail and write them. In the example of the image below we also have themes, this being a logical grouping of epics with the same context inside the system.

Before listing the next step, a tip: have clear, prioritized and feasible goals for the project so you can set releases with higher value added. When you plan a product, you usually have a goal to achieve and expect to add a reasonable value to the business. If the goals are generic or too broad, I recommend splitting this goal into smaller pieces that could become other product delivery milestones. For example, you can have an MVP (Minimum Viable Product) for your product. This first release can deliver value to the business faster and even if it’s a simpler solution, will enable you to collect product metrics, validate assumptions about what is being done, and increase delivery value for future releases.

STEP 3 – Setting Releases

The third and final step is, after mapping and prioritizing the key goals, to distribute the work items from the previous stage among these goals. A good way to do this is to draw lanes on your Story Mapping board, where each lane represents a goal and thus facilitates distributing cards. See the example below:

If we slice the backlog, in the horizontal slices we will have the goals and stories, while in the vertical slices we will have the epics with their respective stories. During the distribution of stories and goals, or even during product development, other items that previously had not been mapped will surely appear, but the scope will be much more detailed and directed to what needs to be done after the discussions.

With the participation of all stakeholders in the group dynamics to set flow, epics, stories, and releases, we have better alignment of expectations on deliveries, definition of an MVP that makes sense for the business and a direction for the next project stages.

To continue the topic of backlog prioritization and setting valuable releases for the business, here is a recommendation for a post about product metrics, written here at Plataformatec: What would be good metrics for digital products?

And you? Do you already have the vision of backlog and releases for your project? Leave your comments below about your experience with Story Mapping!