Story Mapping: The Best Tool (Almost) No One Uses
Teams that engage in story mapping and have a story map to follow deliver better results
Program Manager
projekt202
In my time delivering software, I have seen and used a variety of agile methodologies: XP, Scrum, Kanban, “we just kinda made this up.” I have noticed that my best results have been in projects where we use one tool in particular: Teams that engage in story mapping and have a story map to follow deliver better results.
Story mapping clarifies requirements across multiple levels, finds gaps in understanding, and identifies where feedback, dollars, or any desired result can be collected through a release or test.
Best of all, by merely existing, a story map communicates all these things to a wide range of people. Paraphrasing Andy Grove of Intel, effective management is gathering information, making decisions and communicating those decisions effectively. The more efficiently that can be done, the more effective the manager. Story mapping does all three in a single motion. How great is that?
I feel that not enough product managers, program managers or product owners know how to create these artifacts, so here is a guide on the basics of story mapping.
BASICS OF STORY MAPPING
At its core, story mapping is placing the work to be done onto a two-axis plane to understand what that work is and to prioritize it.
While some story maps are considerable efforts involving multi-day workshops with large groups, others are just a whiteboard sketch done by one or two knowledgeable people. It can even be done as a solo exercise to help clarify what is known and unknown about the product or service.
There are six steps to effective story mapping:
1. Decide the goals of your product or project. Why does it exist?
For simple projects, it may involve just a note card that says “collect invoices faster.” For more complicated work, maybe you have outputs from a dedicated researching and design session with multiple details goals.
Place the goals at the very top of your mapping space.
2. What accomplishes these goals?
This step is about moving from “why” to “how.” If our goal is to collect invoices faster, then maybe we list what must be done in an invoice process (for example, “pull outstanding invoices,” “identify payers,” “write-off uncollectible revenue”).
This guide is intentionally avoiding specific nomenclature, but these would be your “Features” or sometimes “Epics.”
Place these actions just below your goal(s) in the order a user would experience them in your product or service.
Tip: There are probably many paths your customer could take. They can be in any reasonable order and it is only critical to keep hard dependencies in order.
Don’t allow this to bog you down. There is an excellent method for addressing this complexity coming later.
3. Breaking requirements down
If we had magic wands, this is the point where we would wave them and each card described above would spring into existence. Lacking wands, we are best served to turn these large requirements into smaller pieces that can be organized and completed separately.
Depending on the scale, this breakdown could directly generate user stories, work a team can begin and end within an iteration (usually 1 to 2 weeks). You could also find it useful to create an in-between layer of epics or features to be decomposed further. How do you know?
The most reliable method is asking your development team members if they believe each chunk can be completed in an iteration or the target cycle time. If you find that your product or service is simple enough to go directly into stories, that’s awesome! Save your time and just list stories under your “how” layer. It is more likely that what you identify will require further decomposition and so you are best served with a middle layer of work broken out.
If you are tasked with setting a strategic road map for a large product or portfolio of products, a middle layer is also more likely to provide value. It is much easier for people to understand the work if they have a chunk of functionality that they can break down into stories. It also makes you more successful as a PM or PO because you are delegating this work to keep focused on the overall product. I have seen many a product person undone by trying to execute tactical story breakdowns every couple of weeks while also attempting to keep ahead on a strategic mission.
This step of work-breakdown is more art than science, so a written guide can only go so far. My best guidance is to be willing to try a solution and modify it as you understand better what works.
Regardless of the number of layers, we should now be ready to prioritize our work.
4. Prioritizing
Prioritization is a topic that could have its own series of blog posts. There are many excellent quantitative and qualitative ways to prioritize work. The story mapping board can be used to discuss priority, especially in simple situations. In large multi-team or portfolio level conversations, we have found more success in treating prioritization as a special session or task with tools specific for that.
For mapping, showing priority is very simple. Lay each chunk of work underneath its epic/feature/whatever with the highest priority pieces closer to the top and the lower priority pieces further to the bottom.
5. Version/Release bucketing
Deciding where to cut releases is an area of story mapping that can provide a ton of value, but often people see the finish line and rush through or check out mentally around this time.
For complex products or large organizations, I favor breaking release planning into two sections. This split is designed to avoid groupthink or overweighting the opinions of more influential participants. As before, if your context is more simple, then remove what is not useful to you.
Business releases: The voice of the customers or users themselves draw lines around what stories they feel go together to add enough value to merit the overhead of a release.
It is helpful for this group to understand something about the organization’s release “costs,” but to not be entirely restrained by them. For example, a very mature development operation has less technical overhead so that the business can plan things like A/B testing or rapid evolution. A less mature shop may limit to once a month, and so require larger buckets. Business costs such as training and marketing should be considered as well, but the group making these choices should be aware of those.
Operation/Engineering releases: The other side of the coin, these conversations would focus on things like integration, expected performance or load, and anything about the stories that create logical breaks in what goes out the door. This is also where any known information of throughput or cycle time can be used to avoid over or under allocating.
Similar to the business group, it is good for these participants to understand business release costs and expectations.
With these two perspectives, it is now possible to find the overlaps, which should give us the information we need to create release swimlanes.
It is essential that both groups be involved and sign off on the final plan. The point of breaking apart is so we have clarity when coming back together, not to create two plans.
Something that I have noted in almost every session is that often a story can be split to satisfy business and operations need. For example, if it makes more sense to wait on a part of a story until another team makes a service available, that story can be split to deliver some part in one release and another in the future.
6. What now?
You have now poured some substantial time, sweat and maybe some tears into this mapping. It probably means a lot to you and has probably become a totem of accountability and predictability for stakeholders.
Your next step is … throw it all away!
Well, not really. Right now, take a moment to remember the immortal words of Mike Tyson: “Everyone has a plan until they get hit.” Before you are done, you will need to revisit this mapping and probably change every component. That is OK.
The beauty of a good story map is that it can change and flex as you and your team learn and adapt.
Your story map should always reflect what you know today and your vision for tomorrow.
