User Story Mapping, a Business Analyst and Product Owner design technique

If you’ve never heard of User Story Mapping before, it’s a great tool that Business Analysts, Business Systems Analysts, and Product Owners should know. When working with project managers, domain experts, and other business customers, it’s a terrific way to create a shared understanding of the requirements and design of a complete software system. It’s surprising how many people jump into creating a software system when many people on the project don’t have a complete understanding of the system.

User story mapping: Overview

To at least partial demonstrate User Story Mapping, I thought I’d share a couple of example images from a software/hardware system I worked on a few years ago as a personal project. I call it Radio Pi, and a simple way to think about it is that it’s like TiVo (or more generically as a DVR) for the radio and podcasts. An important thing to know is that this system runs on a Raspberry Pi system.

This first image shows a very high-level overview of the initial system components. A few key points about the image are:

User Story Mapping overview

  • The highest level items are considered activities, and in this case I have these activities:
    • Initial setup
    • Radio stations
    • Podcasts
    • System
  • The cards beneath those activities are known as steps.
  • As you’ll see in the next image, as you get into more detail you’ll rearrange the cards, and beneath the steps you’ll have more cards to represent the details.
  • I also show a pile of cards that I threw out for one reason or another. I include this because it’s a great feature of the technique: Made a mistake? Just throw it out, and start on a new card. (There’s actually a joy in throwing out or ripping up cards, because you realize how flexible the technique is.)

I find that activities are like what I call Process Groups in Function Point Analysis, a construct to help you organize the overall system into logical groups. After that, depending on your approach, the steps and/or details are like use cases or user stories.

User story mapping: activity details

The next image shows details about one activity within the overall application, the activity I refer to as “Radio Stations.” Activities are usually named as a short verb phrase in active tense, so it might be better to refer to this as “Manage Radio Stations,” but because I did this for myself I used the shorter phrase.

User Story Mapping - story details

Underneath Radio Stations I added these steps:

  • Add online station to favorites
  • Add antenna station to favorites
  • Listen live
  • Listen to radio recording
  • Configure antenna recording

Because Radio Pi lets you listen to both (a) online radio station streams and (b) local radio stations over an antenna (which I soldered onto the Raspberry Pi), I have to make a distinction in some cases as to whether I’m referring to “online” or “antenna.” (There’s probably a better word to use than “antenna,” but I find that that word gets the point across to multiple people I’ve discussed this project with.)

The user story mapping process

I’ve only shown part of the user story mapping process for this project, but hopefully it gives you an initial idea of how things work. What you might also notice is that some of these cards feel like they need more detail. What I like to do in some situations is:

  • Sketch a quick UI
  • Show some sample data

Both of these techniques help me confirm that I (as the business analyst) am thinking the same think that you (the product owner, project manager, and/or domain expert) are thinking.

Summary

There’s much more to say about how to use User Story Mapping to analyze, model, and understand complex business software systems, but I hope this example helps get you started. Or, if you need to model a new software application and need help modeling and understanding it, feel free to call me at the phone number listed below, or contact me using [the contact form].

About Valley Programming

Valley Programming is currently a one-person software consulting firm that works with clients in Boulder, Louisville, Broomfield, Lafayette, Westminster, and Longmont, Colorado. I can help design and program (create) all types of software applications, including web, mobile, and desktop applications.

Valley Programming is currently a one-person business, owned and operated by Alvin Alexander. If you’re interested in anything you read here, feel free to contact me at “al” at (“@”) this website name (“valleyprogramming.com”), or at the phone number shown below. I’m just getting back to business here in November, 2021, and eventually I’ll get a contact form set up here, but until then, I hope that works.