Don’t you hate when you develop an application for a few months, new features are requested continuously and you no longer know why? Why do they need it? The application was supposed to do X. How does the new feature help them do X? You look at your backlog. You have no idea why there are so many tasks. You try to read them all, but it seems that the list never ends.

Table of Contents

User story mapping
Example
Building the story map

What do you do? You split them into sprints. It is supposed to make it manageable. It does not. Now, you feel even worse. You have a short sprint, but you still have no idea why someone needs those features. It looks like you were building two or three applications at once.

User story mapping

What is user story mapping? It is a method of visualizing the product backlog that emphasizes the user journey and shows the subsequent versions of the product. Every version constitutes a functional release of the product that moves it forward from the MVP to a fully implemented solution.

Let’s assume that you have well-written epics in your backlog. Those epics become steps of the user journey. Now we call them “the backbone.” Those are the things that describe the end-to-end flow.

Story maps are for breaking down big stores as you tell them. — Jeff Patton

Your backbone tells the story, and every item is a small, but essential step in the story.

Your user stories don’t need to change at all, but we have to group them differently. Instead of sprints, we have versions. A version is something that can be released. It is something that increases the value of the product, something that gets the job done.

Example

I have a problem. I kill plants. I used to have at least 8 of them in my house. They are all dead. I still have a plant on my desk at work. The plant is called Zdzisław, and it does not want to die.

Currently, I use a Slack to remind myself and other people working in the same room to water the plant. I want to automate that. Of course, I just want to play with Arduino, but I needed a good reason ;)

We are supposed to break down a big story, so there is the big story: I want to water the plant automatically, but I want to do it only when it needs more water. I don’t want to spill water on my desk and damage it. I want a cool dashboard with lots of charts because dashboards are awesome.
The last requirement is not mandatory ;)

Building the story map

The parts of the big story become epics. Epics become the backbone. I have four of them: water the plant when necessary, avoid spillage, gather some data for the dashboard, display the dashboard.

Is that everything? No, there is an implicit, hidden epic here:

I want to water the plant automatically.
Therefore, I am going to need a water pump.
But, a water pump needs a water tank.
So, I must refill the water tank! That is the 5th part of the backbone.

The idea of user story mapping is so simple you can do it using your favorite spreadsheet software. Let’s put the backbone items as the header row. What now? Now we need user stories, but we need to arrange them in the right way.

We don’t try to fill all backbone items with user stories. We want to divide the work into meaningful steps. Every step is one release.

Because of that, we must put a few horizontal lines in our spreadsheet and move the items around, so we have a useful solution at the end of every spring/release, but we don’t do anything that is not necessary for the next release.

A user story map of the Arduino water pump

The idea looks easy. I wonder how well it works in an IoT project. Let’s check that ;)

User story mapping for developers

User story mapping

Example

Building the story map

Is programming art or science?

How to visualise prediction errors

User story mapping for developers

User story mapping

Example

Building the story map

Is programming art or science?

How to visualise prediction errors

Related Posts

Theory of constraints in data engineering

Developers just wanna have fun

Support for old browsers — is it necessary?