How to improve Agile software delivery with story maps

By Ian Reynolds

22 February 2016 Technology engineering

‎

As part of an Agile delivery team, you may be familiar with the usual project constraints of budget, time and scope. All too often, one or more of these elements needs to be reduced to allow for project delivery. But how can you quickly find out how close you are to delivery? How can you decide at what point your product becomes a releasable MVP?

Over my 10 year career as a project manager, I’ve always looked for better ways to visualise project progress. Recently, I have used story maps to help product owners and stakeholders see exactly how their projects are progressing.

What is a story map?

In its most basic terms, a story map consists of rows and columns to layout a plan of the overall project. The first row is a dotted list of site users who are able to interact with the site in different ways (also known as ‘actors’).

The second row defines the key journeys that an actor can take, and important workflows that happen within the product or system. A good example of this would be a series such as 'Administrators can adjust CMS content / Visitors can Interact with CMS content / Visitors can search for CMS content'. This acts as a 'walking skeleton' of the full project and can be used to pinpoint missing functionality quickly.

Further rows define the priority of all listed user stories related to the journey it sits beneath. The priority of these stories decreases as you progress down each column. These can be split further into release rows to identify potential release candidates (the total workload involved in a release toward the finished product).

Use colours to make the story map clear

In the example above, actors are represented by the blue blocks along the top.

The journeys that the actors take through the system are indicated in yellow in a row directly below them.

We used red to indicate spikes (unknowns) within the releases. Areas of larger complexity which could be deemed as risks to the project are highlighted in orange.

By assigning colour codes to the stories, it makes it even easier to understand how much complexity is in a planned release. It also helps to ensure a sensible balance of spikes, complexity, and deliverable stories without too much risk all across the whole span of the system.

I find the Story Map a great way to understand the overall release plan for a project, as well as a tool to ensure you have a varied spread of stories for your sprint candidates across the full workflow of the project.

The main benefit of this approach is that it helps to increase the chance of delivering a working project, regardless of when budget runs out. It also means that in all sprint demos, there should be a showcase of new functionality that appeals to each of the stakeholders, maintaining buy-in from all involved throughout.

Story mapping in practice

Some examples of where a story map has helped in my delivery include:

Scenario 1: Re-evaluating delivery

A predefined backlog from a client meant planning workshops were long-winded, unfocused and user stories had less business value than we would normally expect.

We decided to map the backlog items against the most valuable journeys the site’s actors went through. We then created stories which covered multiple backlog items, which made the workshop discussions much easier.

Following several sprints of delivery against the story map, the client was able to easily make sacrifices in order to steer their project and focus on the value of the business rather than functional 'requirements'.

Scenario 2: Guided sales plan

Following a successful discovery, we sat down with the client’s lead financial stakeholder who queried the price of the project.

The simple solution was to show the story map as it detailed everything we planned to do in delivery. This allowed the stakeholders to re-evaluate the project scope and the areas of uncertainty which had pushed the estimated project cost up.

Using the story map as a reference, we planned ways to reduce the risk involved in those areas and find ways to make the project less complex.