Story Mapping- Visualizing Your Backlog

A common problem we all face when starting a project is how do we make the first iteration of work visible to a newly formed team? A backlog in JIRA or Rally is great for finding and entering stories, but isn’t as helpful when visualizing how the stories will tie together. Delivering an MVP (Minimum Viable Product) will allow us to honor the agile principle of getting fast feedback, but how does the team define that MVP? Choose too large an increment and you will not be able to get feedback quickly enough, choose too small and you will risk not delivering a piece of functionality that end users want. A story map will help provide that "right sized" feature set. 

In this post, we will explore story mapping as a mechanism for understanding and visualizing a feature and defining the MVP. 

What is a Story Map? 

Story mapping is an engaging and interactive exercise where all participants are involved in the process of building a visual version of the product backlog on a wall. Through experience (and training) I have found that a robust story map provides a valuable tool for a cross-functional team to understand the big picture in the context of a set of features. It ensures that as a team we see the entire scope of work and understand the desired end user experience. Once created the story map is often left in a common area that the team occupies and is referred to frequently as a reference to what should be delivered. 

There are a couple of main components found in every story map 

· The Backbone – the backbone is comprised of the big "actions" found at the top of the story map. These actions are generally too big to be delivered in a single sprint. The above example maps a customer journey for purchasing a banner from an online retailer. The backbone consists of actions such as "Explore Banners", "Configure my Banner", and "Review my Banner". This provides foundation for the desired customer experience but is not granular enough to pull into a sprint. 

· Epics – Epics are really big work items that need to be broken down into manageable chunks to be reasonably completed within a sprint. For example, in the "Review My Banner" backbone item there may be several themes such as "Review Design", "Edit Design", and "Select Accessories" 

· Stories – These are the user stories that are stored within tools like JIRA or Rally. They are the items that are prioritized and sized, ready for a team to add to their sprint. 

Creating the Story Map 

Generally, the story map is created in a series of sessions in which the team comes together for this purpose. We’ll start with the backbone. Prior to the session, we organize the following material: 

· Different color stickies, one for each level (Backbone, Epic, and Story) 

· A conference room with a lot of empty wall space for creating the map, preferably in an area the team has access to (for visibility) and where the map can remain until completed 

· Magic markers for writing tasks 

· Use magic charts/whiteboard in case walls are not a good surface for stickies 

· A camera to capture the final map 

· A designated scribe to capture all the good ideas 

· And most importantly, the key people! (I have found that 4 - 6 people in a session make the most progress) 

 Set the rules of the road for the session. Story mapping for a complex feature is not a quick process and it is important to set expectations that the map likely won't be completed in one session.

Now that you have what and more importantly who you need for the story mapping exercise, it is time to make it happen.  Try to schedule it a few weeks in advance to get all needed parties in attendance. Be sure to let them know how important it is that they attend and be active. Once a successful story map is created getting people to come will no longer be an issue. Use techniques to ensure everybody has a voice and that the process is not dominated by one or two vocal stakeholders. One approach is to spend approximately 20 minutes having people write down their thoughts on stickies. These should be in the form of Action + Noun. For example, "Edit Address”, "Add tax", etc. When 20 minutes is up or you see a slowdown in activity, stop the team. 

The next step is to review the actions created by the team and identify gaps. One by one, have each person talk through their items and post them to the board. Group these items in terms of affinities (similar items grouped together). This will help determine backbone, themes, and stories. Once this is completed, have the group walk through the map from beginning to the end. This will help identify remaining gaps. 

Prioritizing the work 

Once you have a solid draft of the story map, it is time to carve out the first increment of work, the MVP for the feature. We do not prioritize the backbone as it cannot be prioritized! We must prioritize the stories in the feature. To prioritize the stories in the map, you move cards or stickies up and down to indicate high or low importance. The higher the stickie on the map, the more important it is to the feature. In the image above, the items lower on the page represent stories that are not included in the MVP, but to be considered for a future release. The position on the page can indicate how far into the future a story might fall. 

Updating a story map 

As with any development documentation, if you build the story map at the start of an engagement, it will be outdated before the first iteration is complete. A story map must be continually updated throughout the project. It should be updated when new steps or details are discovered, or priorities change and to show the team’s progress. 

Have you ever been on project where there have never been gaps in requirements? I haven’t either. While the aim of story mapping is to reduce those misses, the team will likely find that there are holes in the story map after its initial creation. The initial story map should be created by key participants, but after its creation, it should be shared broadly with other stakeholders (especially those who will contribute to the development of the product) to help identify gaps in the map and ensure there is agreement on the details of product that will be built. Each review of the story map will likely reveal missing requirements or details that would have been found later in the project. Beyond requirements changes, teams should update the story map with findings from research spikes, revised estimations, and user feedback from earlier sprints and releases. 

Tips for updating the story map: 

• Epics and features should remain static, however new stories will need to be added 

• Updating the story map is as simple as adding new stickies to the map and/or moving the stickies up and down to change the priority of a story. 

• Perform updates as a team or alternatively review all changes with the team at grooming to ensure that the team maintains the vision of the program 

Story map usage by the team 

A story map should always be in a place that is frequently visited to keep it in the minds of the team, stakeholders, and users. Having the story map in a location where the team commonly meets allows the map to become a constant point of reference for the product that the team is building and helps solidify the collective understanding. 

During the execution phase of the project, the story map will often become the sprint or iteration planning board. The team should identify or mark off stories that have been completed in the prior sprint as well as identify those that will be committed to for the next iteration directly on the map. During the actual sprint the team can copy the stories that were committed from the story map onto the sprint tracking board to managing their development. But the story map lives on reminding us of the big picture. A great side effect is that it shows the team and stakeholders the great progress the team has made. 

TIP: A great way to show  progress is by checking them off using a bright color. 

By keeping the story map consistently up to date and in sight of the all it will allow the team and stakeholders to share a common vision of what they are trying to achieve. It will encourage flexibility to make changes when gaps are identified and provide insight into where the program is in terms of development.