Much has been written on the topic of story mapping, creation of user stories, use cases and scenarios in the world of agile.

I’ll not be the first or last one to cover this topic. 

These are some ramblings about my recent experience with my product work for a new product concept and some reflections on the story mapping and the sequence of my product approach for it.

Product Discovery and Story Mapping

I personally find the story mapping an integral part of the full Product Discovery.

Story Mapping belongs to your Product Discovery.

Don’t feel caught up in discussing features, writing a long list of user stories for your product designer before you understood the problem. They say: fall in love with the problem and not the process. OK, in this case we’d need both 🙂 . This is my point, there is no solution (not the right one at least) before we have the problem. Is the problem clear for you? Or do you think that it’s clear?  Be honest with yourself.

Even if your boss tells you to ‘go and find out what those features are and create the scope of your MVP’, don’t get fooled to start writing like crazy, take a step back and start exploring the problem space by understanding the potential customers, their problems, emotions and present those findings to your agile team to brainstorm solutions.

What is a user story mapping?

User story mapping is a visualization of the journey a customer takes with a product, from beginning to end. It includes all the tasks they’d typically complete as part of that journey.

sOURCE

Why do I bother with Story Mapping in the Product Discovery phase?

Right now I’m working on a new product concept with quite a lot of unknowns 🙂 Very exciting 🙂

I’ve done my product research, included some benchmarking, prepared my product hypothesis and conducted a series of exploratory customer research. I’ve synthesized my findings and next steps. Happy to talk about it next time. Now comes this BUT..

I’ve a very solid foundation, BUT one crucial missing point. My team knows that this is a key company initiative and we’ve a tentative release date as demanded by the business. 

However, I’ve reached the point where I want to leave aside my ‘solo’ product work (getting into that customer’s problem area) and involve my agile team with whom we will ultimately build the solution (the real experts on the solution area). I want to keep them informed about the progress so far and share where we are at.

So far so good, but I’m missing one (albeit most important) part of the customer journey (automation, which system we’d automate and why).

Without this piece of the puzzle, a new hypothesis and another round of interviews, I cannot ‘finalize’ my work for this new product concept and validate its business viability. Yet, I want to share the work with my team and tell them why we’re not ready to build it yet.

I might have simply prepared the first round of feature sets and shaped up the Minimum Lovable product (lovable > viable especially for a new product which will undergo users/pilot testers, feedback collection and refining to then reach the MVP aka minimum viable product) with a long list of prioritized features. Yes, but I am missing the part which will potentially bring the most value to the customer.

Embrace uncertainty, but still open the discussion for timeliness (now or later)

We need to embrace uncertainty if we work with agile and iterations, but still we want to set the expectations of the business and visualize what we’re working on.

Story maps can make our life easier. Our planning efforts can focus on the following buckets of time-based work:

Now ->  Next ->  Later -> On Hold (v2)

Each time period (e.g. now) has its set of user story maps. 

From User story mapping to time-based blocks and progress!

Avoid the waste

The long list of user stories forms my product backlog and could have been the starting point for the product development and design work. However, I call this ‘WASTE’ for something that may remain at a product concept level OR would find the fit for.

Additionally, I think that this user story approach is ‘broken’ in that case. I shouldn’t be the ‘giver’ and the team to be ‘receiver’. My team should be aligned with the common goal and the findings along the way. I ‘own’ the problems of potential customers and we (team + myself) must work on solution ideas together, brainstorm and prioritize based on the experiences which our product would deliver. 

First, they are a way smarter than me and they have this engineering vision which I don’t necessarily have. Second, they should have their say about HOW we will deliver solutions for experiences.

Here is the trap, if I provide a list of features which I ‘think’ that can solve the problem I’ve been researching, we fall into the trap of building something that neither my client nor the team loves enough. My point is: my team should fall in love with the customer’s problem AND understand the piece which we’re missing so far. The customer should love the product and not the literal implementation of WHAT they described as ‘I think that this solves my issue’. 

OK, we still want to choose the minimum set of features to solve the problem of our customers. I don’t argue about that, I just argue about setting that set of features as user stories in a flat product backlog which doesn’t tell the full story about the experiences which the product will bring towards solving the customer’s problem.

We rarely solve something with a single action, right? E.g. the customer will login, they will check their created alerts, the results of their recommendations engine and only then apply the action to solve the problem. 

This is a sequence of events / experiences which tells the story of the solution journey. The story may fall short for a new product concept. As every single thing in life, that product will be conceived and then born. 

My revelation was that: the flat product backlog wouldn’t show the customer journey + the impact we want at each step

 I’d need to share the problem areas with the team & highlight that missing part.

The flat backlog actually misses the crucial part about the experience which each touchpoint in the customer journey brings and the impact behind it.

 The backlog has a linear structure and has the tendency to grow or bloat over time.  OK, I agree that it’s ordered, but doesn’t present the customer experiences that the agile team should know about to feel empathetic with the user. 

Story mapping allows us to bring the customer story to life and show each impact element in the customer journey.  

Any deficiencies are far easier to identify in a dynamic journey. 

My personal take is that the story mapping helps me bring the findings about my user’s problem back to my team and help my team understand the experiences, put themselves in the shoes of the customer.

Thus, they will not work with a lifeless list of user stories. And, hey, I won’t write down a series of user stories which may change as I get the most valuable missing part 😀 

Each bigger theme has its experience point behind it, e.g.  ‘Notification of an Automatic Change’. Then this consists of various actions: receive the alert, add other people who should know about the change, group alerts in the dashboard, mute alerts etc.

The user story mapping ‘notification of an automatic change’ can then break down to its individual stories (receive an alert, add people, eliminate alerts over a certain threshold etc). However, the experience gives us some emotional state to work with and would help us find a solution that delights at every step. Ultimately, the product should stand out from the rest. 

The flat product backlog will always miss something and this is why we keep adding, purging or merging stories.  

Users have activities which lead to experiences that have impact. The outcome of the latter is the solution of the user’s problem. 

Story Mapping = the sequence of activities → Solution

We can call them Epics or Themes, no problem with that in my humble opinion. It’s just that the ‘story mapping’ implies ‘story’ (activity + experience for each activity) AND ‘mapping’ (a logical sequence of activities within the ‘big picture’). 

This raises the question about ‘dependencies’ as well. Would an element depend on another one in the mapping process? If so, show this properly on the map.

Far better than interlinking user stories in a flat backlog and smaller tasks here and there. It’s chaotic and difficult to follow when we think about the big picture.

First Block to Think BIG

Based on the discovery from the first exploratory phase, we meet up with the team to think BIG without any bias, think of solutions, ideas, better ways to solve the customer’s problem without getting obsessed with the problem. I’d call this the ideation phase. 

From Ideation to Story Mapping and High Level ‘Birth Plan’

The story mapping is a good starting point for an exercise with the agile team (engineering, product design and product) to start mapping out together the customer’s journey, the impact of the user’s activity at each part of the journey and thinking big about solution ideas without any bias (again this is prior to the next round of customer validation interviews). 

Once the user story mapping is done and the prioritization is completed, it gives me the basis of the draft user story writing. We’re ready to split the stories with the team based on the user perspective, the impact and any considerations in terms of technical implementation. 

Visualization of progress

How often do your stakeholders enter JIRA? How much time do you spend on counting story points and drafting project status reports?

I’d challenge you to use a better way in the case of a new product concept. The user story mapping is a powerful stakeholder management tool as it helps easily visualize the delivery progress and the status later on.

Again, the flat product backlog is not ideal. Either use Excel with color coding or Google Slides with nice shapes that show the sequence or a tool like Monday.com, but stick to your mapping, it goes a long way.

At the end of the day, a user story map can have a status ‘done’ or ‘in progress’ and this will do the job for someone who wants a high level overview. You may spend 4 sprints (or even more!) on a complex user story map, the flat product backlog cannot visualize your team’s progress.

Resources which I recommend on the topic of user story mapping:

New User Story Backlog as a Map

A nice presentation you can learn a lot from

Ultimate Guide on User Story Mapping

I’m always happy and curious to learn, give me a shout about your experience and thoughts!