Evolving the Story map

I can't say enough about how useful story maps are and how essential they are on any Agile project. Jeff Pattonis the undisputed (certainly in my mind) master of the story map and it's well worth looking at the materials on his site. Jeff summarises a story map as, "A prioritized user story backlog helps to understand what to do next, but is a difficult tool for understanding what your whole system is intended to do.

A user story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that delivery value to users and business with each release." Story maps really do help you sort the wood from the trees and make a great focus for the whole team when you are trying to get the project context into your head.

The picture below shows the map for our current project.

Our Story map

I thought it might be useful to describe what was going on on our old board:

1. The current stories for our next sprint that have met our definition of ready and are available for the whole team to look at before the next sprint starts.


2. The first row of the story map has our "themes" (really just big stories), these are the major process steps in the product we are building, for example "search".


3. The second row represents our "epics" (smaller than themes but still to big to build), these represent smaller more detailed steps in our system, for example "text search", or "video search"


4. These are the stories, the real meat of any Agile project, they contain the story title, size in points and a quick reference the story number in Rally. They are also sorted in relative priority for that epic. We use Rally as our story database, basically we make sure we have duplication to ensure that we don't de-scope the project on a windy day!


5. These represent "nice to have" stories that at our current velocity we do not have capacity to complete. They may get added if our velocity increased but that is up to our product owner.


6. The current stories for this sprint (the visible workspace is of screen , having them this close to the story map really helps keep things in context and if we get lost we can quickly refer back to the map.


7. We have actually done some work hence why the section is blank, one tip we got from Jeff was to create a ghost image to show where all the completed stories have been. As you can see we did not follow his advice (well this bit anyway) and those epics look rather lonely.


8. This is our definition of ready, it's the product owners version of a definition of done, it provides a check-list of things that the team needs to have completed before they start to build a story. We use the lean principle of "the last responsible moment" to hold off on doing the detail work on our stories until the sprint before they are due to be started.

You can see how easy it is to understand what's going on, and you can add other markers to show key risks, team information dates for external deliveries etc. So why did we need to take it one step further? The project we are delivering has lot's of workflows and business logic steps and flows for electronic items and physical items that get handled in subtly different ways. We were worried that we were missing key steps in the flow of information that the story map generalised too much or that it had so logic holes that we could not represent with Themes and Epics.

We had plenty of system documentation on the flows and could relate the stories to the steps in the documentation, but it was hard to keep them both in your head at the same time. The BAs on the team were the most worried about this so they put their heads together and came up with the story flow map, which combined the simplicity and ease of construction of the story map and the visible logic of a flow chart. The whole team has found this to be a really valuable resource, being able to understand the minimum viable solution for our product and spot steps in our processes that do not have stories covering them at a glance.

The subtle difference for this is that we only show the stories that directly relate to this release, that's because we don't want to clutter the map and it also shows the holes nicely.

Story Flow Map

So as you can see it's very different, gone are the neat (sort of neat) columns of stories and their parents and what we have is a clear view of where the stories fit into our system. I have highlighted the key points from this view too

1. The themes, epics and stories for this stage in the process


2. It's hard to read but these are the ghost story numbers (yes we listened this time) of the stories we have completed of that part of the process


3. User interaction point


4. We can now see the gaps in our story map very easily

To conclude story maps are a fantastic visualisation tool you should use as often as possible and if you are building a system with lots of logic then a story flow map should be your next evolution. Don't forget that the flow map came about by having a relatively detailed understanding of our final solution and may not work well in the very early stages where the flexibility of the story map is much more effective.

Jeff's fantastic presentation on story mapping can be found here