Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Extending Impact Mapping to Gain Better Product Insights

DZone's Guide to

Extending Impact Mapping to Gain Better Product Insights

There's something missing here. See what improvements the team at Scrum.org discovered they needed to add to their impact map.

· Agile Zone ·
Free Resource

Download this white paper to learn about the ways to make a Scrum Team great, brought to you in partnership with Scrum.org

Impact Mapping is a powerful technique that helps teams understand how to link the work that they do with results that their organizations would like them to achieve. We've been using this technique for a while in our Scaled Professional Scrum and Professional Scrum Product Owner courses, but I have had a growing discomfort with the approach that I couldn't well articulate until we were using it recently in an Agile Measurement (EBM) Workshop. There seemed to be something missing in the usual Goal-Actors-Impact-Deliverables chain (see Figure 1).

Figure 1: A "classic" Impact Map Example (for a ride-sharing service)


The thing that we discovered was missing was the outcome that the "actor" is looking to achieve. The "impact" is what we would like to achieve, but in order to achieve that result, we need to help our customer achieve some outcome that they desire.

As long as we were going to tweak the Impact Map, I also wanted to better align with the User Experience (UX) modeling terminology that we've been using to talk about users and customers and the outcomes they are looking to achieve, so we changed the term Actor to Persona, and we changed the word Deliverable to PBIs, short for Product Backlog Items (PBIs), which is the term with which the organization's Scrum Teams are familiar. Finally, we added Outcomes (see Figure 2).

Figure 2: Extended Impact Map


In this extended Impact Map, we show the Outcomes that people matching the Persona need to achieve in order for our organization to achieve the Impact. Furthermore, we show which PBIs we believe that, when we deliver them, will produce the Outcome for the Persona.

As part of the workshop, but not shown on the Extended Impact Map, we also identified the measurements that would tell us whether the outcomes and the impacts had been achieved. This was important because it forced us to make the outcomes and impacts concrete — if we could not measure whether we had achieved them, then we really did not have enough insight to start working on the associated PBIs. Being forced to decide how we were going to measure stimulated interesting discussions about the outcomes and impacts, and helped us to come up with better PBIs.

Business stakeholders often complain that they can't connect work that teams are doing with the things they want to achieve. Adding Personas and Outcomes also helped the Scrum Teams better understand the people who would use the product, and why. The Extended Impact Map provided a useful way to show how goals are linked to PBIs, and helped foster better discussions about those goals and how better to achieve them.

Learn more about the myths about Scrum and DevOps. Download the whitepaper now brought to you in partnership with Scrum.org.

Topics:
Agile ,impact map ,extended impact map ,outcomes ,user mapping ,user stories

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}