User Story Mapping

What is User Story Mapping? It is a technique he developed over time and with experience, which helps writing effective user stories for a product backlog. In fact, the crucial point here is not writing them but living them and making them happen together with your team. The stories have value as long as there is a shared understanding for them among the team and the stakeholders, i.e. that they make sense and the same sense to everybody on the team. So much so that they want to deliver it.

User Stories are typically little stories composed of a sequence of tasks that a user of a (software) product would do to accomplish something. For example, a user story can be “Reserve a Thai Restaurant online for tonight” and it would consist of the following tasks: Open your favorite search engine — Search for a Thai Restaurant — Select your favorite — Visit the restaurant website — Click on online reservation — Enter reservation date and time — Confirm and send. Now, this is a very basic illustration of a story, but it can give you the idea. The tasks in the story are to be read from left to right, in the so-called narrative order, so that with the last task you read you know the whole story.

Why is User Story Mapping good a thing? Because it gives structure and a backbone to your product development process. It helps you to frame the who, the what and the why for your product. In other words, it lets you define your users, your product, and the benefit your users will get out of your product. All makes sense, no? Otherwise, why would you bother producing your product?

User Story Mapping’s structure is like this:  On the way to developing your product you have several Goals to achieve. Each one of these Goals is composed of Activities, and those are broken into Stories. A sequence of Tasks in a given order (left-to-right) make a Story. Tasks may have Subtasks (e.g. putting on my shoes is a subtask of getting dressed). In this way, a Story can but doesn’t have to yield an MVP (Minimum Viable Product), but a few of them together should yield at least a Minimum Viable Solution (MVS).

If there are too many Stories, then there are potentially multiple MVPs (or MVS for that matter). So those Stories should wait for the next iteration(s) to be included.

A User Story typically has the following format: As an <Role> I want to <Functionality> so that I can <Value>. For example, as a <jazz music fan> I would like to <know the weekly concerts in my town>, so that I can <buy tickets online automatically>. This format conveys the necessary information in a clear and concise way. It gives a first overview of what the system has to offer for that type of user (also called Persona) i.e. the jazz music fan.

For the fun of it, I did a User Story Map for myself, while hoping it can show you its power. It shows the structure that I have been describing. My product is Pinar’s New Life in Barcelona. This product offers me a new life in a new city, therefore I think it will add a lot of value to my life in general. I expect it to be a wonderful product and this is the User Story Map towards the first MVP.