Visualising your backlog: Impact Mapping

This post is the first in a 2 part series on visualising your product backlog. The second post will look at Story Mapping.

Recently on a trip to Sweden I was introduced to Impact Mapping, sometimes refereed to as effect mapping, as a collaborative work-shopping technique for identifying software features and mapping them back to organisational goals and user personas. The following article is a summary of the technique, as described in the book Impact Mapping: Making a big impact with software products and projects by Gojko Adzic, along with a mix of my own observations from being involved in facilitated Impact Map sessions.

So what is impact mapping?

Well according to Gojko Adzic, an Impact Map is [1]:

A visualisation of scope and underlying assumptionsm create collaboratively by senior technical and business people. It is a mind-map grown during a facilitated discussion

Impact Maps can help you build products and deliver projects that make an impact, not just ship software. Impact mapping is a strategic planning technique that prevents organisations from getting lost while building products and delivering projects, by clearly communicating assumptions, helping teams align their activities with overall business objectives and make better roadmap decisions.

How do I impact map?

Working your way through the following questions with your team or customer will allow you to build up an impact map from scratch. These are often best achieved in a facilitated workshop environment with a number of key stakeholders represented.

Why

Defining the business goals is essential for any project and its the focus of Impact Maps. Why are we doing this? What is the goal that we are trying to achieve above all else?

Goal definition is about understanding the problem, not the solution. It should not be focused on specifically creating a product or application, rather explaining why its existence would be useful. It can be useful to try and tie the goal to the organisations value chain.

Examples:

  • Increase online conversions by 15% in the next quarter
  • Attract 20% more customers in the next financial year

Who

The first branch of an impact map looks at actors. For anyone who has spent some time with UML or traditional use cases you will know that actors can range from end-users and external suppliers to third-party applications or systems. Try and capture decision makers and those able to achieve the goal you defined or aid/block it from being achieved by others.

Consider the following questions at this stage:

  • Who can produce the desired effect? Who can obstruct it?
  • Who are the consumers or users of our product?
  • Who will be impacted by it?

These are the actors who can influence the outcome of your goal.

Examples:

  • Students with a tablet device or smart phone in the classroom
  • Corporate employees with access to the secure drive

How

The second branch level of an impact map sets the actors in the perspective of our business goal. Don’t list all the activities that an actor might want to take, just the ones that are focused on achieving your goal.

Consider the following questions at this stage:

  • How should our actors’ behavior change?
  • How can they help us to achieve the goal?
  • How can they obstruct or prevent us from succeeding?

These are the impacts that we’re trying to create. Note: They are not product features.

Examples:

  • Get faster access to accurate information
  • Have access to a wider network of colleagues to collaborate with

What

Once you have answered the goal, who and how questions you can start to consider and define your scope. This is the third branch level of your impact map and starts to identify the top level features of your product.

Consider the following questions at this stage:

  • What can we do, as an organisation or a delivery team, to support the required impacts?
  • What is the minimum that you can deliver to achieve your goal

These are the deliverables, software features and organisational activities. Do you not get too detailed at this stage and consider what the shortest route is through your map to the goal. It is very unlikely, and is potentially not a wise investment, to deliver all the features identified in your map.

Examples:

  • Product galleries
  • Online purchasing

When

This is a section that I have added but its a step that I find useful to help understand how a feature will help the organisation to achieve their goals. Agile uses the phrase “Definition of done” and in a similar way I like to think about “What success looks like”.

Consider the following questions at this stage:

  • How will you know when your goal has been achieved?
  • What action or level of engagement will signify a success for your feature?
  • How long will it take to get usable data from this feature?

The outputs from these questions will help formulate your measures or metrics. Where possible you should measure the smallest individual unit Avoid vanity measures, page views and impressions are worthless unless they prove an increase in conversion or engagement from your intended users.

Examples:

  • A completed signup form
  • A social media share

What are the outcomes?

In Adzic’s book he describes deliverables as being features, lines of code that helps organisations in achieving their goals, and of course he is right. However, I’ve often found it’s useful to understand at what point your Impact Map will be ‘finished’ and what the immediate deliverable from the exercise are.

Firstly if you are creating your Impact Map in a workshop then it will be produced within a timebox and will most likely be completed within the one session. Impact Maps are collaborative artifacts and unless you have all your stakeholder representatives available after the workshop, it’s not wise to carry on developing them in isolation.

Secondly, the largest deliverable from me as a business analyst are a prioritised list of features and measures, mapped against their actors (or personas) and goals. This allows you to quickly slice your Impact Map into a product backlog, understanding that what you have is probably high level epics that will require some breaking down into smaller stories.

user_stories

The diagram above shows how you can map the who, how & what into stories that can be worked up.

What do I need to impact map?

When I first drafted the outline of this post my intention had been to discuss different types of mind-mapping software here. And for the record, I use Xmind and have had some great results with it.

However, having written this post now, it’s clear to me that what you need in order to effectively Impact Map is a good mix of stakeholders who can represent both your organisations goals and your users needs. Without access to them you will not produce an effect map that adds real value and your roadmap and backlog will be flawed from the start.


Impact Mapping: Making a big impact with software products and projects by Gojko Adzic

If you’re interested in Impact Mapping you’ll need to get a copy of Adzic’s book. This colourful and illustrative book take you through the basics needed to facilitate and create an Impact Map for your team or customers.

[1] Adzic, Gojko. 2012. “Impact Mapping.” [online]. impactmapping.org