User story maps, impact mapping and progress metrics — a brief overview of what I have learned during a two-day workshop. Natalia Kolińska Follow Mar 13, 2017 · 6 min read

Introduction

Two years ago I attended a workshop by Gojko Adzic about specification by example. During two days I learned a lot of new techniques, got many useful ideas, but I didn’t feel at that time it was something special, unique or life saving…until I actually started practicing the knowledge in real projects, applying examples in discussions with business representatives and software developers. Genius!

This time I went to the workshop about product owner key skills with twice as high expectations…

Day 1

The day welcomed us with a question — how to deal with a huge backlog and how to agree on what’s important while creating software? At the beginning of the workshop each group ought to prepare a delivery plan for a new software. And?

We all failed.

Of course, we generated ideas, lots of ideas, some of them were not even so bad… but how could we decide on which feature is the right one to start with? The one and only that will help us achieve our goals and let us learn for further improvement?

The conclusion we came to is that too many people want too many things at the same time, but each project we are co-operating on with others needs some priorities determined. This time, we agreed that focusing on features would not get us far enough…

First hint that we got that day was to focus rather on outputs than inputs.

That helped us to narrow down the number of available choices, because it suddenly occurred that most stories in our test backlogs (I guess the real ones as well) were about inputs. Let users type their names, e-mails, phone numbers and get nothing from it in result…

Additionally, we came to a conclusion that what we all need — development teams and stakeholders — is a feedback to ensure that we are aiming in the right direction. But how could you possibly get some useful feedback on inputs? Or a discussion about risks? Of course, you cannot. That is another argument in favor of the outputs.

There are a couple of techniques to work with the outputs. We can either create a completely new output, modify existing one or create the same output but in a absolutely new way.

Second hint — the outcomes.

To be sure that we are making progress in achieving the goal, we have to define some metrics that could be compared with other solutions, so that it can be decided which approach is optimal considering our objectives.

Outcomes are subjects on which discussions on management level may be held. ‘Is this feature required right now or next month is fine?’ — this is a sample question that should be asked on that type of meeting. Voilà, prioritisation done (finally we reduced the number of stories to discuss — it is easy, right?)

And that brings us to the third hint — change in behaviour.

What I learned on the workshop’s first day is that even perfectly implemented features may be useless if they do not change people’s behaviour. What we want to achieve is the behaviour change — this change will help us define values as well as measure progress or success. ‘Do we want to have something done less or more frequently, easier, or faster?’ — this simple question should be asked each time we work on a user story. This definitely will help us in search of new solutions and game-changing ideas. Actually, correctly captured behaviour changes reflect current business objectives.

And finally, an impact map — a tool apprehending the behaviour change. In result of our previous actions (focus on outcome, prioritising, defining behaviour change), we have goals, actors and impacts defined. Knowing all that we can start thinking about the actual deliverables.

A project backlog can consist of many impact maps, but if we manage to capture it that way we will not stuck in discussing checkboxes and buttons, as we will be clearly able to talk about goals and values.

As in my professional life I am a person engaged only at the deliverables stage I need to adapt this knowledge and think, what I and my teammates can do to improve our everyday work. A tip from Gojko for people not involved on the managing phase — try to rephrase to user story to reflect the change in behaviour and monitor the progress. If we present the data to clients and they do not agree with our assumptions, then definitely they will complain, automatically giving us some insights on goals.

Day 2

Second day was devoted to the following topics: metrics, failing, slicing and story maps.

The key question usually is: when do we succeed? But what a success really is? I believe each person in the group of stakeholders might have different opinion on that. What Gojko was suggesting is that it is much easier to agree on metrics of failure. If we know at which point we fail, we will be definitely aware when it is the right time to re-plan and try a new approach to the issue in scope.

Moreover, if we know what a failure is we can ask more detailed questions about the accepted numbers, or we can discuss how changing one metric impacts another — if I ruin a metric because I focused on a different one, will that still be ok for the business? Not necessarily…This technique was called ‘slicing milestones’ (how much we can cut to still keep the balance on other metrics?).

What is also important about metrics is that we always need something for a comparison — if we are aiming for success we are aiming for improvement. To manage that, it is recommended to be aware of the current status of the metric in question (number of clicks, % of users).

It is also a good practice to discuss the set of metrics both for general goals and specific impacts that have to be generated to commit to that goal (but goal targets have to be defined better than values for impact).

Afterwards, the story maps were discussed. Story map is a tool that helps collecting user stories in a specific hierarchy but in the context of a particular user journey. What I remembered as really important is that a story map is always about one customer journey. Until now I used to think that is only a way of organising stories, but it occurs that there is something more relevant in it. So the story map will differ if we prepare it for different personas. Depending on whose impact is the project focusing at the moment, various stories will take the lead in our plan. In general, story map should back us up while ordering and prioritising the stories and then plan (or re-plan) releases.

It is worth remembering that impact maps help us to realise what problem we want to solve, as well as define actors of that process, whereas story map is a tool helpful while planning, because we already know why and for whom we develop features, so at that moment we can focus on optimising our path to achieving the growth.

Summary

At the end of the workshop Gojko advised that we should keep some digital notes of all knowledge and inspirations that we had, in order to organize all new information as well to find gaps — that is why this text appeared.

Knowledge and ideas are not the only benefits I gained from attending the workshop. Let me list some other:

Loads of inspirations:

books to read (e.g. ‘How to measure anything,’ Douglas Hubbard, ‘User Story Mapping’, Jeff Patton, ‘The Lean Mindset: Ask the Right Questions’, Mary Poppendieck),

people to follow,

conferences to attend,

facilitation techniques — ‘waste snake’ has a potential of a real life hack :).

2. Book with an autograph (yeah!).

3. And a task — how to implement all this in a real project (I made an attempt to rephrase the story to focus on behaviour change and it seemed to work!).

If you are interested in the topic, the book ’50 quick ideas to improve your user stories’ by Gojko Adzic and David Evans will give you a more detailed description on what I have mentioned in the text.

My ticket to the workshop was partially sponsored by XSolve — thank you!