Impact mapping is the technique I reach for at the start of any significant feature or product decision. It forces the team to answer "why are we doing this?" before discussing "what are we building?"
The map has four levels:
- Goal → Why are we doing this? (a measurable business outcome)
- Actors → Who can help or hinder achieving it?
- Impacts → What behavior changes in those actors would make the goal happen?
- Deliverables → What can we build that would trigger those behavior changes?
"Impact Mapping breaks down organizational goals into actors (who can influence goals) to specific impacts (how actors influence goals) to deliverables (what activities help actors complete goals)." — IIBA Agile Extension
The key insight: if your deliverable doesn't change how an actor behaves, it probably won't move the goal. A feature that's logically related to an outcome but doesn't change any behavior is waste.
"It helps the team focus on user needs rather than features and keeps them aligned with the broader objectives defined in the Vision Statement."
That's the practical value. In delivery, teams naturally drift toward features — what to build next, which ticket to pick up. Impact mapping pulls the conversation back to the need and the outcome. I've used it at the start of discovery sessions when the team had a vague goal and too many competing feature ideas — the map cut through the noise in about 90 minutes.
Impact maps are best created collaboratively in a workshop. The BA facilitates the identification of each level. The disagreements that come up during the session are often more valuable than the map itself.
Exam tip: Impact mapping is a Strategy Horizon technique in the Agile Extension. It's about behavior change, not feature delivery. Questions may test whether you know the difference.