Mapping, but not as we know it

Inspired by the recent Lean, Agile and System Thinking (LAST) conference we decided to use Story Mapping to help us manage and understand a project we’re working on. I thought it would be interesting to share a few thoughts on our experience.

Essentially on any project we work on we always build and maintain some kind of list (usually called a backlog) which defines the things we need to deliver as part of the project. Our aim when we build this list is to identify things which are of value to our customers. Once we have the list we work as a team with our customers to prioritise the list into an order which will enable the project team to incrementally deliver the project with the the most valuable items delivered first. We’ve been using variations on this technique for a while now and one of the issues we’ve found is that when we work on larger projects it can be challenging to understand the overall solution from a single long list of items on our backlog, and this is where Story Mapping is useful.

Story Mapping is a technique originally developed by Jeff Pattern. As a technique it aims to organise a backlog in such a way that you can easily understand the big picture. It provides a way for you to understand how users flow through the system as well as how you can logically break down the overall system into incremental releases. If you’re interested in learning more about Story Mapping then I encourage you to read Jeff Pattern’s original article ‘It’s all in how you slice it’.

Here are a few things things we noted from our first go at mapping stories

1. What makes a good story?

When we started our project we had a long list of requirements supplied by our customer. Some people dismiss traditional requirements, but we think they can often be a good starting point. However what can happen with traditional requirements is that they are actually a collection of a range of different things such as technical constraints, user expectations, pre-emptive solution designs and more. So when we did our story mapping we tried to rationalise each requirement provided by the customer into a ‘user centric story’ (to use Jeff Patterns term). So for example a requirement like:

The system will display the entry form(s) relevant to the type chosen.

we would change to be:

An analyst using the software only wishes to see options relevant to their operation so they do not waste time filling in unnecessary fields.

We use a simple story recipe based upon Mike Cohn’s which identifies the type of user, the goal of the user and the reason behind the goal. What we ended up with was a new set of user centric stories, mapped to the original requirements, but the process of building the user centric stories actually helped us identify missing stories and elaborate on those requirements which needed further discussion.

2. Who is your system for?

As part of the story mapping process we quickly began to see that our system had three main users. So when we started organising all the backlog stories we actually did so in three separate groups – each group organising those stories which ‘belonged’ to the specific system user. We found this useful because it helped us start the process with a much smaller set of stories per group. Once we had organised the stories we then came together to weaved each group into a larger story map – this process was quite interesting because we began to evaluate how important a particular users story was against another users story – which made for some interesting debates!

3. Get people up and active!

Story Mapping seems to work and it’s a very effective way of taking a long disorganised list of stories and putting them into a sequence which closely relates to both logical user flow and user demand – however we found that the best way to go about building the story map was to get all those who are involved in the process up and out of their seats and actively collaborating. It didn’t take long before this collaboration lead to discussions about how important a story was, or how a story needed to happen before another story, or how the overall map was missing some stories.

So now that we’ve done it what happens to our map – well it’s up on the wall for all the project team to see and engage with and we’ve already found us going back to it again and again to discuss how the work we’re doing on a day to day basis fits in with the overall goals of the system. We’ll continue to use the technique in the future to help us build better solutions for our clients, solutions which focus in on real and valuable user needs.

Comments are closed.