I have used story mapping many times but on items that I would not feel comfortable casually publishing as they are not released. In lieu of being able to directly share those with you, I will explain the basics of story mapping with a fictional problem.
Story mapping is a very valuable tool. It allows us to break down ideas or existing functionality into a visual representation of the basic parts that make up the total workflow, allowing for greater understanding of the most basic needs to complete that workflow. It’s also a valuable tool for prioritizing the features needed to complete that workflow and rough estimation of efforts for each section without necessarily prescribing the UI.
For a very simplified example, let us say that I am working for a fictional start-up who is going to change the world by making a fabulous toast company. My team needs to make a decision about our first, simple product to our customers. We have a lot of questions about what particular features we should have. We are also uncertain of how much work it will take for us to get to our most basic toast feature. So, we turn to story mapping to get a better understanding of what our customers currently do when they make toast to better understand what we should offer.
Story mapping can be done in a variety of ways, through post-its on the wall, white boarding or on a virtual drawing board, such as Google Drawings. Even if I start with post-its on the wall, I prefer to make a digital artifact when we are done to keep as a record. (A picture may also work if you do not feel there will be any changes to your story map later.)
The first thing you do when you are story mapping a product is create the ‘backbone”. This is essentially the basic steps or needs the workflow performs or satisfies. The should be at a high level, as the next step is underneath each of those backbone steps you break down what that step entails. You need to balance being too general in your assessment with being too granular. For example, if we were to story map “Making Toast”, the backbone would look something like this:
Then, as you go in deeper you start breaking it down further, asking questions like: Where do I get bread? What kind of bread is it? How do I toast it? This is your second level to your story map and using another color for your post-its or boxes is recommended for each level so you can tell them apart more easily. (This example is not intended to be all inclusive of what a true, deep story map might entail.)
Next, you go at least one step deeper. You can keep going if you find there are more levels to your workflow but in this simple case, only one more level is necessary to start noting things like options for where you will get your bread or possible fruit toppings.
The final stage of story mapping is prioritization. Now that you have a visual of every component that can or does make up your workflow, you can start organizing them into spaces of time for when you’d like to do that work as well as a rough level of effort to create that functionality. Our team decides we want to organize our work for the next two quarters and will have our toast engineers give a rough estimate (small, medium, or large) for the amount of effort it would take to add that ability to our toast offerings.
That, in a nutshell, is a very simple example of story mapping. Each story mapping experience is going to be different. In the past, I have used different shapes or added icons to indicate when there is a dependency on a different team for example, or a potential major technical constraint that needs researched. Story mapping is flexible enough for your team to make a clear picture of what needs to be done in the way that works best for your team.
Katie Cissell 