Determining value using impact mapping

This short blog post is the second of three this week where I describe methods for determining the value of features.

In the previous part, we looked at value poker, a method for working out the relative value of features.

In this part, we’ll be looking at impact mapping.

What is impact mapping?

Impact mapping is a visual method that helps us take a step back from the features and think about what we’re actually trying to achieve. Starting from the big goal, we create what is effectively a mind map of roles (users and others) and what they can do to help us (or prevent us!) reaching the goal. The final step is to identify the features that would allow this to happen.

Why use this method?

The impact map, and the discussions we have while creating and maintaining it, helps us understand which features will contribute the most to our goal. Importantly, the map also makes visible the assumptions we make (“Social sharing tools will increase the number of new users”), which allows us to design experiments to verify these assumptions.

Impact mapping is a very collaborative method where we can involve both stakeholders and representatives for the development team. The result is a big picture (quite literally!) that allows us to understand how each feature contributes to our goal. This way, we can prioritise features against each other, based on their impact. This map, which will evolve over time, will help us improve our roadmap decisions and the ordering of our backlog.

How to use it

Typically, the impact map is built up in a workshop with the relevant stakeholders and representatives for the team.

In the session, everyone collaborates to identify the following, one level at a time:

1. Goal — This is the most important bit. What is the one big goal we’re trying to achieve? Make sure this really is a goal (objective), rather than a deliverable. For instance, a goal could be “6 million weekly signed in users”, whereas “New sign in system” is not a goal in itself.
2. Actors — Who are the users of our product? Who else is impacted? In the example above, we might list “Signed In Users” but also “Guest Users” as well as “Customer Services”.
3. Impacts — How can the actors we have identified help us achieve the goal? How can they prevent us? How else are they impacted? Some examples: Signed in users may help us by inviting friends or visiting more frequently (so that we can class them as “weekly”). Customer Services might be impacted through additional support requests.
4. Deliverables — What can we deliver to achieve / mitigate the impacts? For example, we might encourage users to invite friends by us adding social media share buttons or a referral system (maybe offering them some kind of award). Note that not all deliverables have to be in the shape of features to build. In our example, we may consider recruiting additional support staff.

From impact map to backlog

If stretched for time or if your impact map grows very big, you may want to use a method like dot voting to identify the top few most important items on a level and limit the exploration in the next level to those.

An impact map allows us to have important discussions, both while building the map and off the back of the results. Some examples:

• Features that don’t fit into our impact map, and therefore don’t contribute to our goal, can be descoped. This saves us from spending effort on building them.
• Depending on how important we consider an impact to be, the deliverables contributing to that impact can be moved up or down the backlog.
• Where multiple features contribute to the same impact, we can discuss which feature is likely to contribute the most. Let’s prioritise that feature!

Final thoughts

The usefulness of impact maps stretches far beyond prioritising features against each other. The exercise helps us come up the features in the first place. The way in which we do this ensures that each and every one of them contribute to the goal we’re trying to achieve. Last but not least, an impact map highlights the assumptions we make, so that we can verify them.

All good stuff!

For more reading about impact mapping, see the book Impact Mapping by Gojko Adzic.

Thanks for reading this post! If you found it useful, it would be awesome if you spread the word by hitting the 💚 button.

And if you’ve got a few minutes to spare, it would mean a lot to me if you would complete my short survey about Scrum. ⬅⬅⬅

I first published this post on my personal blog Magnus Dahlgren — Thoughts from a Scrum Master.