We would then prioritize these topics using our team’s Priority Sliders
from the last article to organize them for our next practice, Impact Mapping.
Impact Mapping is used to understand a strategic initiative and make the value of that initiative clear. This is typically used to achieve strategic alignment and a shared understanding of the team’s goals and problem statements. An optional output of this practice is a collection of Stories, which are then placed into a Backlog. In the context of this series of articles, we will use Impact Mapping to reinforce the team’s understanding of the vision, align on deliverables, and produce Stories for our new team’s Backlog.
There are five headings for our Impact Map; in order, they are: Goals, Actors, Impacts, Deliverables, and Stories. The input to our Impact Map is a Goal. For this exercise, our Goal is “High level of Stability and Performance”. Note that we’ve taken our “Stability and Performance” topic output from Affinity Mapping and have framed it positively. This is important because the change we are trying to drive with our solution is always positive.
An Actor in the context of an Impact Map can be a person, system, or process. Something that acts on our goal to make an impact. It’s important to note that the Actor does not have to readily exist; it can be something or someone that has yet to be created or hired to achieve an impact. An example of this might be an Automated Test Suite or a continuous integration/continuous delivery (CI/CD) Pipeline. Let’s use those two Actors for our current exercise:
We need to think of the Impact each of our Actors has on our Goal of high stability and performance. Let’s focus on our first actor, “Automated Test Suite”. What are some Impacts an “Automated Test Suite” can have? A couple of examples might be:
For this exercise, we’ll stop there. Focusing on our one Actor, our Impact Map now looks like this:
The next item we need to identify is “What deliverable results from this impact?” Let’s focus on the “Presents errors” Impact and see if we can come up with some Deliverables. Think about every test you’ve ever taken in school. The result of that test was usually a score or grade granted by whoever reviewed your test answers. That would lead to a report of all of your scores on something like a report card. With that example, some deliverables might be:
These example deliverables would go under our Deliverables heading in our Impact Map and be visually connected to the Impact that originated them--in this case, “Presents errors”.
Now that we have identified some Deliverables, we can take the next step to identify Stories on our map. If we take our Deliverables as a whole, we can group them under the topic of “Test Reports”. We know we want to have something that shows the number of errors a test presented and the number of successes, and we want some kind of stability grade. We can achieve this by creating a report that assigns a grade to whichever feature was being tested based on the number of errors and passed tests. So we may have some Stories such as:
We would repeat this process for each identified Goal, Actor, Impact, and Deliverable until we have a list of Stories that can be placed into our team’s Backlog. Those Stories would then be further refined using our team’s Definition of Ready
Define stability grade formula
Generate a test report after each run of the suite that shows feature stability grade
Send test report to team email distribution list
before we begin work.
It is important to note that Impact Mapping can be a very time-consuming practice, but it can yield many benefits. The team can more easily visualize the direct connections between Stories, Deliverables, Impacts, Actors, and Goals related to their Vision Statement. With Impact Mapping, every team member shares this understanding and contributes their expertise to creating work items that will achieve the team’s vision. It is recommended that the team be prepared to allocate two to four hours for an Impact Mapping session, not including breaks, depending upon the Vision Statements and Goals..
In this post, we described some slightly more advanced practices to ensure the team is working on the right thing. We were able to define a vision, goals to achieve that vision, risks, actors, impacts, deliverables, and ultimately, stories that represent units of work. Most importantly, we described how, through these open practices, team members could align on and understand everything from the vision down to those work items to maximize the team’s ability to succeed.
At this point, our team has everything prepared to begin planning a release, executing on their stories, and showcasing their completed work, something we will dive into in the next article in this series.
Open Practice Library series on the Red Hat Blog
Learn more about our community-driven collection of exercises for making incremental progress along the product delivery cycle from the full Open Practice Library series: