Advantages of Story Mapping

So what makes story mapping so effective? First let's take a look at some things that teams often find hard, then we can address how story mapping can help.

Some common difficulties

Developers, or other team members protest that they can't see the "bigger picture" of the product

What you release to the world is defined by your sprint cycles, as opposed to when a feature is ready to ship

Your daily tracking tool is cluttered with future work, and not focused on the next couple of sprints

Stakeholders struggle to see all the good work your team is doing as they don't understand the tracking tool, or don't care to look

Planning big pieces of work or features is daunting

User stories are not user focused, and are not part of a genuine user journey

The development team don't know where a user story fits into the full user journey

You're not actually sure what to build

You often find gaps where a key part of the feature has been missed out altogether

You keep over-building and adding features that aren't required for a minimum viable product

So there is a lot of stuff above. It might not all apply to you and your team, but even if you can solve a few of those issues, you will be more productive and efficient in delivery. Let's take a look at how to address these issues with the advantages of story mapping.

Advantages of story mapping

Bigger picture view

Without doubt — the most obvious benefit about a story map is the fact that you can see the whole of your product — almost from a bird's eye view. If you have a purchase journey that has dependencies on something to have happened in your registration journey, you can put these two items in the same release and easily see the horizontal slice (or release) across your product or application.

Releases need not be tied to sprint cycles

A lot of dev teams will work to a release per sprint — often on a given day. Some teams aren't so lucky and have to release at larger intervals inline with the company at wide. We don't really want to have to stick to these confines as an Agile team. We should be free to push a small release at any time. That way, we can gain insights faster and hopefully improve, or remove the feature accordingly.

Story mapping encourages smaller releases, which should be able to be released at any point in a sprint. The idea is that your team can release as many times in a sprint as needed. Let's illustrate this with a simple diagram:

Planning by journeys

Let's take a look at a simple example. Here is what a typical backlog might look like for an upcoming Checkout feature:

This is not too bad for small products. However, as we get more features across the application (not just the Checkout — in this case), the list just grows longer. So we need a way to visualise the whole product and then prioritise our list into much smaller chunks, or releases.

Here is the same set of user stories in a story map:

Okay, well things are looking slightly easier to digest and we can now clearly see the user's journey too. Notice how we now have a hierarchy of journeys (top row), steps (second row) and stories (below). The steps run from left to right in the order that the user would undertake the journey.

However, we're still lacking our prioritisation of features, so let's create a release. We'll call it "MVP". This MVP can contain all the stories we need to launch the Checkout.

Now we're talking. The work is starting to look a bit more manageable. This release can now be worked on by the development team — whilst the next release is prepared in the background. A nice way to handle this is to transfer the release to a more traditional work tracking tool — like Trello, Jira or VSTS.

If you want to see a full explanation of the above example, check out How To Story Map