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.
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.
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.
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:
Obviously, your dev-ops and infrastructure needs to be able to support this way of working, but this is essential to any successful Agile team.
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
