Story mapping when there’s no user stories

When your work doesn’t fit in a user story shaped box

Many of the challenges I’ve faced since becoming a product manager were ones I expected. Dealing with competing requirements, constant context switching and difficult stakeholders comes with the role.

Of course, the real challenges are often the ones you don’t see coming, especially when there’s no quick and easy solution. In my case, this has been the ‘messy middle’ between the overall feature or epic where the scope is defined, and the actual development work. This is the hard part, where you can spend hours going back and forth discussing things with your team. Hours of your life you won’t get back. Despite it being clear where you’re trying to go in the end, you can’t quite figure out how to get there.

At this point, you’re probably saying, ‘Isn’t this exactly what user story mapping is for?’

Where user story mapping works – and where it doesn’t

The clue is in the title: user story mapping is designed for when there’s a broad journey that can be sequentially explored based on the actions users need to take. It makes sense from a product perspective as it puts customer needs at the forefront and allows you to prioritise which ones need to be taken forward and at which stage. It’s also a great anchor for everyone to come back to for clarity on what you are building and inform how to break it down into tasks.

The problem is that a standard user story map isn’t always reflective of reality. Hidden complexity often lies in the backend development work, or if you’re bringing a specific user story into build, the traditional structure of the map doesn’t go into enough detail on what’s needed, resulting in the round in circles conversations.

Rethinking the story map

This is where adapting the traditional story map comes in. Instead of throwing the framework out entirely, we can steal its best attributes: its visual nature, chronological flow, and ability to force prioritisation.

Here’s where the differences lie:

Headings

If there’s still a user story tied to this, keep it. If there are no high-level user goals, these can be based on milestones to keep the focus on outcomes.

Steps

Directly beneath this is the chronological flow. Without user actions, this could be based upon how the system will operate sequentially, or how the data will flow through. This might already exist in the form of diagrams, but the aim here is to translate it into actual work for the team.

Take the example of a successful login. On the surface, it’s one user story: “I want to log into my account.” Within this is all the ‘invisible’ steps that need to be built for and can be visualised in the story map horizontally (Input login details > Send data back > Return response)

For each vertical column under a step, sticky notes can be added to flesh out three distinct things:

• The Core Requirements: A one sentence description of what needs to happen.

• The “Unhappy Paths”: In user story mapping, you focus on the happy path – when there’s usually lots of different cases that need to be covered. This could be error states or messages that might need to be accounted for.

• Dependencies & Unknowns: If there’s uncertainties this is the place to include them and often helps establish what to tackle upfront.

Slicing

Just like a traditional story map, horizontal lines go across your columns to create slices. But instead of slicing by user value, there are factors like feasibility and crossover between features which come into play.

If the map gets stuck

Since this isn’t tightly focused on users, there’s more need for input from engineering on this compared to a traditional story map for sequencing the steps. This creates the potential for rabbit holes when bringing this to a team focused on the details of the build.

Asking others to review and comment on the map before the session can help to isolate specific questions that need to be explored separately, without taking up the whole mapping session. The aim of this is to get a broad overview of the individual tasks, possible slip-ups and steps required, not to solve all the problems in one workshop.

Conclusion

We’re told that if we just write the perfect user story or map the perfect customer journey, everything else will fall into place.

But product management is messy, and the most critical parts of a product are often completely invisible to the people using it and the hardest to get right.

Stepping away from the story map and using something more tangible for a development team is sometimes the best option – and might finally put a stop to those endless meetings about the same subject.

---