Software products are difficult things to build. I don’t think there’s any new news there.

One thing that fascinates me about this, though, is the number of great tools available to us as we seek to deliver great software. In this blog (and its follow up, coming soon), I’ll be focusing on one such tool, one which I find provides great visibility and clarity to the goal but is sorely underused: the story map.

The story map – originally conceived by Jeff Patton – is simply a visual representation of the product backlog. But whereas a product backlog is an unwieldy, linear list that represents meandering and lessening value the further you traverse it from top to bottom, a story map is a beautifully crafted and rewarding artefact. Key benefits of a story map to your team include the following:

• Simplicity – it uses exactly the same assets as the product backlog you’re already using (an index card with a single epic or story).
• It layers itself to convey information in such a way as to immediately convey need, relative priority and complexity.
• It’s rewarding in the way it evolves with a team and customers in their emerging understanding of the product.

But where a story map really comes into its own over a flat product backlog is in the way it allows you to collaboratively identify holes or gaps in the product, while visualising the user journey:

Identifying gaps:

When you lay out the product in this way, it presents the focus on detail within the context of the whole. When you can see the detail in the bigger picture, you gain a much freer understanding of the product as it exists at that point in time. And while it’s okay to have stories of lesser value and lower importance in a story map (just as you might in a backlog), the format allows you to see each one for what it really is – a fundamental foundational component, a valuable product functions/feature, or ‘nice to have’ (as the case may be).

Visualising the user journey:

Product backlogs just do not cut it here. Their linear nature has you running your finger over each story in turn, and requires you to piece together a mind’s eye’s view of how the customer benefits from the product. In contrast, a story map lets you lay out the customer journey from left to right, visualising how a user might actually use the product. This in turn also helps to determine priority, as there will naturally be tasks that your customer must do before they can do others.

A surprisingly underused tool

I’ve been able to introduce the story map into a few teams I’ve worked with over the years. Every time I’ve suggested its use, I’ve been met with scepticism but a willingness to ‘give it a go’.

In each case, once we’ve iterated through the exercise a few times, team members and customers alike have come away with a newfound understanding of the product in question, and a real interest to continue using the storymap throughout the lifecycle of the product.

One such example was when I worked with a national newspaper, for which I went in to deliver a new app and website. I joined them at the beginning of the discovery phase. Of the 20 or so product, development and supplier team members, only one had heard of a story map before, but not used one.

After the first session, working through a rough first pass and learning the tool as a team as we went along, we were able to lay out a skeleton of the product. Lo and behold, we spotted holes in the plan. These were holes that needed to be plugged by taking some time to think and discuss them with others in the business. In the subsequent sessions throughout discovery, the team coalesced around the value and the insight the map gave them. A great reflection I think on iterative and collaborative product elaboration and planning.

For me and many of the teams I’ve worked with, then, a story map is a key tool in a delivery team’s arsenal. In my next blog, I’ll look at one approach to building a story map, in more detail.