Blog: March 27, 2015
Requirements and prioritization through Impact Mapping
If you’re at all involved with agile software development and you haven’t heard the name “Gojko Adzic,” it’s probably time to look him up. I’ve enjoyed Gojko’s insights ever since reading his book Specification by Example.
I follow Gojko on Twitter (@gojkoadzic) and had seen him reference “Impact Mapping” a number of times. After digging into it, I was really intrigued at its potential for helping us focus our requirement gathering efforts.
Though we’ve just started using it, early returns are very positive.
What is impact mapping?
In my words, impact mapping is a way to help think through and visually represent possible ways to address a goal or need. The last part is really the key, here. Everything traces back to a goal. I’ll explain why this is important in a second.
Impact mapping example
I won’t reinvent the wheel, here. If you want the basics, I strongly recommend that you check out http://impactmapping.org/drawing.php.
But, to paraphrase, impact mapping follows mapping out these levels:
- Why (your goal)
- Who (which actors can impact that goal – positively or negatively)
- How (how can the actor impact the goal?)
- What (what can we do to help the actor make that impact on the goal, or prevent the impact if a negative one)
Ship my widget faster!
Let’s say our business builds and ships some sort of widget. We’ve had a problem with deliveries to new customers taking a lot longer than we’d prefer, so we want to try and address that. Therefore, perhaps our goal is something like this:
Goal: Improve average time to ship our widget to a new customer by 75%
Next, we have to identify who could have an impact on that goal. A customer places the order, our support team completes that order over the phone, and our shipping courier delivers the product. Each actor involved is added as branches off of the goal:
Next, we’ll identify how each group can contribute to the goal. Let’s start with our customers; what can they do to improve shipment time? Say we’ve found that a lot of orders have inaccuracies in shipping info. When customers are more accurate, our shipping time improves:
Finally, we think about what we can do to help our customers achieve the How (in this case, being more accurate when entering address info). For our scenario, we’ve found that we don’t do a great job with order confirmation, and need to make that step more reliable. Also, we’d like to investigate a third-party service for verifying address information.
Note: Don’t hesitate to go to multiple levels within the “whats.” There can be multiple variations and ways to attack each feature.
Basically, you repeat this process until you’ve identified as many whos, hows and whats that you think you need to address your issue. (You may also need to do this exercise multiple times if you want to try and address multiple goals with a single project.)
After the maps are created, it’s time to start figuring out where you get the biggest bang -for- your- buck, or the biggest impact. Then, you’ve already got a good start to a backlog. Most of the “what” items will translate well to at least epic-level user stories.
What does impact mapping help to accomplish?
Every potential solution ultimately maps back to a goal, so impact mapping:
- Helps ensure you’re working on things with real business value
- Weeds out pet features - if you can’t argue how it addresses the goal, it goes bye-bye
- Aids in brainstorming
- Exposes assumptions
- For our example above, we have an implied assumption: shipments are taking a long time because of inaccurate customer information.
- If that assumption isn’t accurate, our solutions won’t address our goal.
- Identifies high level process improvements, not just technical solutions
What projects does impact mapping work for?
I think that impact mapping is probably best suited for greenfield projects, or projects that involve adding features for which there isn’t a singular or preconceived implementation.
Also, it’s very helpful in very large projects to help identify which items would have the biggest impact so you can prioritize better.
Where might impact mapping fail
I don’t see impact mapping being terribly helpful for a project such as a rewrite of a legacy application where you’re simply updating technology. However, if the rewrite was totally open-ended in terms of re-implementing existing features, it might work there as well. And, even with greenfield projects, you need a business team that buys in to the approach. They’ll find it hard to dispute once they see it, but, as we all know, there are product managers out there who want to dictate how things are built – logic be damned.