Impact Mapping is a brilliant way to generate and organize a Product Backlog hierarchically. It is the brainchild of Gojko Adzic. In this Post I describe Impact Mapping and How to create and use Impact Maps.
Photo by James Toose on Unsplash
What is Impact Mapping?
Note: This post contains affiliate links
An Impact map provides a way to structure a Product backlog hierarchically. It allows you to trace each User Story in a backlog to a specific business outcome. Therefore, it is a great tool to help prioritize a backlog and to help drive an iterative approach because it highlights the assumptions behind each story.
Structurally it is a mind map that starts with broad business outcomes in the center of the map. The next ring of the map identifies the actors that are needed to achieve the goal (Eg. the user audience). Connecting to the actors are the behaviours or impacts that are needed from those actors to help achieve the goal. Finally, in the outer rings of the map are the tactics (features) that the product will deliver to enable or influence the actor’s behaviours.
Impact maps are the invention of Gojko Adzic, and I highly recommend using them. In this post I cover the basics, but his book Impact Mapping goes into greater depth than I can here, so I recommend picking up a copy.
In the Impact Mapping book Gojko describes impact maps like this:
An impact map is a visualization of scope and underlying assumptions created collaboratively by technical and business people. It is a mind map grown during discussions facilitating the following questions:
Impact Map Example
Framing business outcomes is key to a solid Impact Map.
I will go through a step by step exercise of building out a small piece of an impact map for a fictional product, but in case you are keen to see what they look like all at once, here is an example taken from Fifty Quick Ideas to Improve Your User Stories. If you are a Product Owner or a team member tasked with writing User Stories, I recommend this book too - also written by Gojko Adzic.
The goal answers the why, why we are doing this.
The actors answer the who - who is it for?
The impacts are the what, what effect it will have.
The how are the deliverables, or tactics to achieve the impacts.
Let’s work through an example to get a better feel for this approach.
Hiking Trail Weather Station example
Suppose we have a project to setup weather stations on a mountain with hiking trails. These weather stations feed data to the internet and can be accessed online so that hikers can see the weather conditions are various elevations on the trails.
This system helps hikers prepare for the weather they will encounter on the trail and may even help them to decide if they want to hike the trails that day. One of the business outcomes might be:
Provide information to help hikers prepare for hiking weather conditions
An Impact Map will likely have many desired business outcomes, but for this example we’ll stick with one.
Just writing this outcome down gets my mind thinking beyond the weather station idea, because I can already see that it only provides part of the information that people might need. What about weather forecasts? Having information about current conditions is great, but what will be happening in 5 hours when I am on top of mountain?
You can see how describing a desired outcome get you thinking about customer needs instead of just implementing a desired solution.
Here is the Impact map so far. The outcome with an actor attached to it. Actors are any persona that can help or needs to be involved in achieving the outcome. Obviously for this example we need hikers.
But let’s think about this.
This system will need to be monitored and maintained, so maintenance crew is another good persona that we should include. Whoever is paying for this system will likely be interested in how much use it is getting and perhaps monitizing the site to help pay for the upkeep of the system?
Now we’re really thinking about our audience and we’ll need to incorporate these other actors in other parts of our Impact Map. Let’s keep the map simple and leave them out for now. Defining our desired impacts is next.
Impacts - What Behaviours do we need?
Impacts are the actions and behaviours that our product needs to enable or drive.
In order for hikers to adequately prepare for a hike by including the information from our system in their plans, we need to make sure they know about and use the site in advance of coming to the trails. We will have to market this service. We also need to make sure they check the site prior to leaving home, Let’s add these behaviors to the map.
How do we enable or influence our actors to perform these behaviours? This is where our deliverables show up. Finally! These are the solutions we think will achieve the outcomes we have identified so far.
Deliverables are the features, tactics and solutions that will enable, influence and drive our actors’ behaviours.
Getting hikers to “Bookmark the Trails Weather Site” means we need to make hikers aware the site exists and that it is valuable enough to add to their bookmarks. Here are some ideas of things we can do to make this happen:
- Memorable domain for the site
- Market the site on social media channels, with popular hiking bloggers, government parks sites, traditional media
- Provide a downloadable app
- Include other resources on the site like trail maps, trail difficulty and durations, trail head instructions
- Suggest to hikers that they bookmark the site
With some of these tactics added to our Impact Map, it now looks like this.
Generating the Backlog from an Impact Map
Once you have an Impact Map, it should be easy to create User Stories from it. If you follow the connextra format this is simply a matter of pulling together the actors, tactics and impacts from the Impact Map.
Some examples from the Hiking Trail Weather Tracker:
As a Hiker looking for weather information I want a site with a memorable domain name So that I can quickly go to the site on any internet connected computer without searching
As a Hiker looking for weather information I want to be prompted to bookmark the Trail Weather Site So that I remember to bookmark it, so I don’t have to search for it again
The downloadable app tactic is an Epic User Story, and is likely too big to fit in a sprint. You will have to slice this story into smaller stories.
Hopefully you can see the benefits of this approach. I would list them as follows:
- Every User Story can be mapped back to a business outcome
- Backlog items can be prioritized based on the importance of the business outcome and the likelihood that they will achieve the desired impact
- Each tactic comes with assumptions regarding its desired impact on our actors, the map makes these obvious
- We may need multiple tactics to achieve a user behaviour, or we may only need one that map allows us to focus on results not deliverables
- Impact maps get the creativity flowing because the focus is on outcomes
- Impact maps are easily understood by business people, where User Story Backlogs can be very technical