User story mapping for developers

User story mapping for developers

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.

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.

User story mapping

What can you do? You can visualize the backlog differently. Most likely there is some user journey. How can you describe it? 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.

Are you interested in data engineering?

Check out my other blog


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 plan when necessary, avoid spillage, gather some data for the dashboard, display the dashboard. Is that everything? No, there is an implicit epic here. I want to water the plant automatically. I am going to need a water pump. A water pump needs a water tank. 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
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 ;)

Remember to share on social media!
If you like this text, please share it on Facebook/Twitter/LinkedIn/Reddit or other social media.

If you watch programming live streams, check out my YouTube channel.
You can also follow me on Twitter: @mikulskibartosz

If you want to hire me, send me a message on LinkedIn or Twitter.

Bartosz Mikulski
Bartosz Mikulski * data scientist / software/data engineer * conference speaker * organizer of School of A.I. meetups in Poznań * co-founder of Software Craftsmanship Poznan & Poznan Scala User Group