Visualising your product with story maps (part 2)

In the first part of this blog post, I set out to explain what a story map is, and why it’s such a valuable tool for delivery teams.

I recommend reading that before the piece that follows. If you’re now convinced you need a story map in your life, let’s get to it!

The basics

There are some basic components to a valuable story map, but as with everything it’s something that can be tweaked and adapted to suit your needs. Indeed, I’ve used different flavours of the story map and it’s structure with different teams – a case of adapting the tool to meet individual team and client needs, rather than being wedded to any ‘one true way’. This is something that’s very much in keeping with Equal Experts’ delivery values.

The important thing is to ensure there’s a sense of collective ownership – your story map needs to work for the team, so it’s best to let the team find their own path to find what works for them. It may take a few goes to get right, but the end result should speak for itself.

The basic components are a hierarchy of map items, represented across a backbone, walking skeleton and ‘the rest’:

The hierarchy of map items: The approach I like to use is a common Feature -> Epic -> Story hierarchy. The essence is to visualise the structure of the product through elaborating your understanding of what’s required to support the customer journey.

The backbone: The backbone represents the basic capabilities of the product, without which the product cannot function and cannot expect to deliver the basic customer value that is expected. I typically place the features and epics in this backbone.

The walking skeleton: These are the stories that will provide the user with the tasks that they can perform within the product – aligned to features and epics in the backbone. I like to use the walking skeleton to describe the essential elements of the minimal viable feature set; in other words, what’s required to release a viable and valuable product.

The dressing: These are the clothes – the ‘nice to haves’ of the product. The product could be released without these stories, but delivering them may make the product more useful, valuable or desirable. Using the Kano model might help here, too.

An example

In the illustrations that follow, let’s use these colours to illustrate features, epics and stories:

In the beginning
Below, we see the first iteration of a product. Take your features and epics and lay them out across the top from left to right (epics under the features), following the customer journey from beginning to end, left to right:

Visualise the product
Next, add your user stories from your product backlog, laying each underneath the relevant feature and/or epic. Once we have this view, we can review it in the whole context of our customer journey – helping us identify any holes or gaps in the product that we couldn’t see before.

MVP

And finally (for now), we might identify what we believe the first release will be on our product roadmap – to satisfy a Minimum Viable Product (MVP) or release 1.0:

When, how and where to use a story map

A story map has a valuable role throughout a product’s life. It’s best initiated at inception, as you start to elaborate the backlog; even at epic level, a story map can be a useful tool to visualise the product in context and as a whole.

As with all new software products, we know least of all at the beginning of a new initiative, and your story map will grow with you as you understand more about what it will take to satisfy user needs and what a valuable product will look like. In other words, view the story map as a living and breathing artefact that will evolve over the life of your journey with the product. Some good ways to help this happen:

Put it on a wall. The story map is a perfect information radiator. It’s a conversation starter. It speaks volumes to anyone reading it, and offers an opportunity for all stakeholders to understand, discuss and iterate it.

Roadmap and planning. Use it to form opinion about the product roadmap and to facilitate release planning and iteration planning. The story map is a fabulous precursor to the product roadmap, since it’s a pretty short leap to draw a line and put a stake in the ground for your target MVP or release 1.0.

Once you have the roadmap, you can still use the story map to help with release planning. In iteration planning, it helps to keep focus on the detail without losing the wider context of the release scope.

Go digital – if necessary. In today’s distributed delivery model, it’s not always possible for everyone to be in a physical space where they can see, collaborate with and influence a story map in person. Putting the story map online can be valuable, then, but it needs some additional thought. The best solution is one that is integrated with your backlog and planning tool. If you create a separate story map online, it will become another asset to maintain and manage – making it likely to be seen as a chore that is eventually discarded.

Hopefully this piece and its predecessor have given you some fresh insight into the value of story maps. So what do you think – could a story map help you visualise your product in a more valuable light? Or do you use story maps in a different way? I’d love to hear your thoughts – you can find me @_projectAlly on Twitter.