User Story Mapping

In a previous post I made clear my dislike for User Stories, and how there are fundamental problems with them that make them unfit for defining and tracking a projects development. I ended that post with the line…

There have been some very good attempts to work around some of the issues with User Stories, the most successful has to be User Story Mapping

I thought it would be interesting to walk through a User Story Mapping session I recently went through.

(As this is work related, images in this post have been blurred, but it should be easy enough to get a good idea of what is being shown)

Epic and User Story Overviews

We start with an overview of the epics and some examples of high level user stories, ideally put together from the Product Owner. This usually takes the form of a written document walking though the epics and pulling out detailed examples of how a user would flow through the epic, or by simply describing, explaining and documenting the users incredibly high level journey through the product.

Once we have that, we can start pulling out more extensive user stories

Building up More User Stories

We can do this in a couple of ways

• We can read through the Product Owners document, asking for more clarity around the epics, the stories and how the users interact with the app
• We can step into the users shoes, walking through the application starting from when the user starts using it, to when they finish

My personal preference is to walk through the application as a user would, as it gives the developers a real feel for how the user will interact with the product, how they will approach it and how they want to feel about it.

By using either method we come up with a collection of user stories describing what the finished product would be. We might not have very many of these, and some of them might be quite big, but that’s OK because it’s what the application will be like when each part is in the hands of the users, and has probably gone through a number of iterations to get to that point.

It’s easy enough to jot these down on some post-its as you go through the users journey. None of these stories use the ‘As A … I Want To … Because …’ (or any variation of the theme) because I don’t think it brings enough value to warrant the time it takes.

Once we have these, we should have a good description of what the final application will look like from a users perspective. Remember, this is the finished article, we’re not interested in interim releases or iterative

Breaking Down Our Stories Even More

The easiest way to do this is on a white board as we’ll be writing on the board later. Though you better hope the post-it notes are sticky otherwise you’ll spend half of the time picking them up off the floor!

We group the stories on the board in epics. We don’t have to do it this way, but it helps to keep your mind in the right frame when discussing the each user story before moving onto the next group.

In the picture below, we’ve taken the initial user stories (the orange ones) and placed them in a row, which follows the journey of the user from the start of their experience all the way to the end.

We then start to break the user stories down, into smaller user stories that could be delivered that would provide value on the way to completing the ‘final’ user story we created earlier.

On their own, the green tickets build on each other to provide the functionality of the main one we pulled out earlier. But, while the they are not good enough for a final product, it provides clear value that allows the user to do something meaning we can release it but we know it won’t be the finished article.

We do this for every user story, building up a map of broken down, but deliverable stories that will constantly provide value as we build towards the final product.

Building Up Our Minimum Value Releases

A Minimal Viable Product is useful, but it still requires a lot of time to get there. If we were to try and complete all the broken down user stories before we released anything, we’d be bunkered down for months on end, with nothing to show for ourselves until we emerge. Probably having built the wrong thing.

Instead, we now build up our set of Minimum Value Releases.

We break the board up into horizontal releases (the release numbers are not important here) which will signify the ‘official’ releases we’ll go through as we work towards our final product. Each one of these vertical releases is a single Minimum Value Release.

For each release, we pull out the minimum amount of work required to deliver something that works. It helps that as you go through this process, you define what the main purpose of each release will be allowing you to focus each story into a valuable release.

Each one of these releases offers a distinct, usable, testable build that allows for feedback. We might have interim releases within the team that no-one sees, but we track them internally as we go through each sprint.

Don’t get me wrong, some of these releases might not set the world on fire when it comes to releasing something to your customer (of course, it depends who your customer is here), but each one offers value that does a number of things

• Shows progress, which is vital when you want to release early and often
• Offers constant opportunity for feedback which will feed into future Minimum Value Releases
• Gives the team a constant feeling of success as they release iteration after iteration

Tracking Dependancies

Now we get a bit messy, as we start to link the broken down user stories to each other. Specifically which ones naturally follow on from each other or need to be completed before the next one can be completed.

This is a really good exercise in validating the order in which you’ve specified the stories to be completed. If we have any arrows going upwards, it means we’ve placed something in a later version is actually needs to be completed before an earlier version can even be started. The arrows should generally flow from left to right as well, as it’ll prove a narrative of releases as we build on the start of the application (where the user will get their initial value) to the end.

It’s often the case that a few user stories need to move around here as we spot the inconsistencies.

It also helps us track anything we’ve missed. Pretty much every story as you move from top to bottom and left to right will have some kind of dependancy on the work before it. If we can’t link a dependency, then chances are we’ve missing something we need earlier in the process.

Estimating Our Stories

Finally I like to estimate our stories at this point. We don’t have to as we can do this later, but it helps when links between stories are clearly identified, and that you can group individual sized tasks together and bucket the estimates as you go along.

Each story in the above has a red Story Point value, and from the bottom left you can see we use a slightly modified version of the fibonacci sequence to generate our available points.

And That’s It

That’s our initial planning process done, and we’re ready to start breaking it down into sprints and estimated release dates (note we’ve not mentioned time or schedules once at this point).