The why of impact mapping: from outputs to outcomes

The first of the twelve principles behind the agile manifesto says it clearly:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

The word valuable holds a world of meaning here. Agile software development is about value for the customer, delivered early and continuously.

So, how do we do this in practice?

In previous blog posts such as Waterfall with sprints and You get what you measure!, we discussed the importance of measuring value and how the organisational structure plays a key role in making value creation possible, easy and fast.

At the heart of the collaboration between Customers, Product Owners, Team members and Stakeholders, we find the product backlog. Backlog items do not just serve as a TODO list, but capture ideas for what value we may want to create for our customer in the near future.

In our experience, teams that are inexperienced with agile development do not dedicate enough time to refining their backlog, in particular to breaking down their backlog items into smaller slices of functionality that can be delivered independently to enable a fast feedback cycle. But lack of value slicing skills is not the only missing piece.

Often, even in a relatively mature agile setup, what we’re missing is the ability to create high-value backlog items that are linked to our business objectives.

Formally, we know that the Product Owner’s responsible for maximising the value produced by the Team. Therefore one of the first actions we take to help teams conquer value creation is to work with Product Owners to ensure they know how to link deliverables to business goals, in their product backlogs.

Impact Mapping

The first stop on the road towards outcomes is Impact Mapping.

Made popular by Gojko Adzic’s award-winning book, Impact Mapping is a strategic planning technique that helps organisations focus on building software that has an impact. And it’s not of course confined to software products.

An impact map looks like this:

Basic structure of an Impact map.

We start the map with a goal.

Goals can be impacted by a number of actors: these are people who can produce the desired effect or even obstruct it, in other words their impact can be positive or negative.

Each actor will have one or more measurable impacts: these are found by asking ourselves the question: “what can the actors do to help us (or prevent us from) achieving the goal? How should their behaviour change?”

When an impact has been identified, we can now generate actual deliverables that will help us realise such impact. Deliverables can be software features but also activities.

Let’s imagine an example from the world of mobile games. Let’s suppose that our product is a popular Fantasy Football app which players can play for free provided they accept the displaying of ads. Our goal is now to grow the revenue from ads.

This is what a potential impact map could look like for this goal:

Impact map example: increase revenue from ads.

In our example, our hypothesis is that if we increase the time customers spend in our app then they will be more likely to view and click on ads displayed which increases our ads revenue.

To achieve this, we decide to introduce more competitions in addition to the basic ones, also target content and push notifications to increase the probability that our users spend more time in the app. Obviously these are all hypotheses we’ll need to test, and that’s where agile delivery comes to the rescue as it allows us to take small slices of functionality to the market sooner and test customer uptake.

The key take away is that with impact mapping, we have a recipe to connect backlog items (deliverables) to business goals. And because the deliverables have an impact hypothesis attached, we can measure the impact of a feature or an activity and check that it’s actually what we expected when we decided to make the investment.

It’s not just about software

I personally find impact maps extremely valuable and intuitive. They are a great tool that helps us identify ways in which we can drive customer behaviour. Impact maps work outside of software products too. In fact, I see examples of impact mapping everywhere.

Recently, I was buying fresh fish at a large UK supermarket chain. When I approached the fish bar I was happy to see that the queue was not too long. My basket was still half empty. I asked for what I needed and when the person at the counter offered to clean my fish for me, I immediately said “Yes, please. That would be great!” – thinking that it would save me some time and hassle later at home. At this point the lady said “Perfect – it might take 5 to 10 minutes, is that okay? You can continue shopping and come back a bit later if that’s alright”. I accepted.

Walking around the floor, I began to think about what had just happened.

I now had to kill 10 minutes and I was in a really large branch selling basically everything. I started to look around and fill up my basket with stuff I hadn’t necessarily planned to buy.

The supermarket staff has identified an activity that affects customer behaviour in a way that is certainly aligned to their business goals 🙂

This is what the impact map may have looked like when they discussed offering this particular service:

Example of impact mapping in a retail setting.

An extended Definition of Done

Up to a few years ago, I thought the best Definition of Done I could possibly aim for would be something like “Tested and deployed to Live”. After all, if it’s live, then the customer has it therefore it’s done. This is a pretty good definition of done, already. But we can do even better.

Now that we know Impact Mapping, we can say that it’s done when we know the impact it has had on the customer.

This is really what enables continuous learning: being able to know whether what you brought to market was a success or not. If it was a success, do we continue refining this idea or is it time to move on to something else? Have we spent the right amount on this? Could we spend even less time next time?

If it was not a success, how long did it take to “fail”? Could we fail faster next time?

Whether you’re doing Scrum or Kanban, there should be an extra column added to the right hand side of your board: Outcome.

Some teams may never get to this level of agility. But teams who embrace technical excellence and achieve a fast feedback cycle have the opportunity to enhance their business agility to satisfy the customer through early and continuous delivery of valuable software.

This site uses Akismet to reduce spam. Learn how your comment data is processed.