How Impact Mapping Gives You Multiple Options to Pursue

[article]
Summary:

In this article, Lisa Crispin explains how impact mapping allows your team to generate multiple options to pursue. Be creative with your solution experiments. You won’t solve all your problems or achieve all your goals quickly, but small wins and steady progress mean you’ll enjoy the journey of continually improving how you work.

In “Problem Solving with Impact Mapping,” I explained the basics of impact mapping, starting with the “whys”—the SMART goals your team wants to achieve. For each goal, you identify who can help or hinder your path to the goal, how each person will help or hinder, and what they can do to help you along. Since you’ll come up with multiple “whos,” you’ll have several alternative paths to consider.

Try Something Out!
Mapping out several branches that start with a “Who” and flower into “How” and “What,” you now have lots of places where you can try improving on your problem area. Resist the temptation to “fix” everything at once. Use dot voting or a similar technique to identify the top one or two problems to tackle. Take the sticky note for your top goal and start creating your impact-map skeleton.

Once your map is done, choose one or two paths for a small experiment. Gojko Adzic’s book Impact Mapping encourages us to think about the simplest way to support each activity. So, how can we test that the assumptions we made are correct?

One of the advantages of impact mapping is that it gives you multiple options to pursue. They provide “real options” that help us take a more direct path to our goal. Each option has value, but some may expire. We should keep our options open as long as possible, in order to adapt to changes.

Getting our CFO to enable us to buy new hardware is a great option, but what if the company has to freeze the budget for some reason? We’d better have more options ready to go. Perhaps we can reduce story rejections by having the programmer working on a story pair with a tester to go over the story requirements before checking in the code, or we can spend time in iteration-planning meetings to go over requirements for each story in more detail.

Look for the simplest way to support an actor taking the action that will help you make your problem smaller. Is there any high-value, low-hanging fruit? Is there something that limits our options? Have we made some assumptions that may not be correct? As with your goals, use dot voting or some other technique to choose a few options to try.

I also recommend trying set-based development or a “divide-and-conquer” approach. Choose what you think are the best two paths to the goal, and have one pair work on each for a set time period. They can present their results to the team, and the team can decide if one of those options is worth pursuing further.

Set milestones to review the measurements for your SMART goals as you proceed along a path in your impact map. As soon as you see that one option isn’t going to help solve your problem, try a different one. But don’t have unrealistic expectations. It’s unlikely you’ll solve your problem in one go. If the option you try makes your problem 20 percent smaller, that’s a win. That might not even be your biggest problem anymore, and you need to go back to your goals and choose another one to work on.

Another Example
Consider the following situation. In your team’s most recent retrospective, you decided your biggest problem was that too many bugs were going out to production, despite spending a great deal of time on regression testing. To deal with this, you decide to create an impact map to identify some ways to cut down on regression testing time while still preventing defects.

A goal such as "Cut down hours spent on regression testing by half" is measurable, but what's the purpose behind it? Possibly too many bugs are getting out to production, because there’s not enough time for the exploratory testing that would find the bugs in time. Perhaps the team’s real goal is "No more than six high bugs in the next three months." Cutting regression test time isn’t necessarily going to achieve that goal. The team members then start identifying the “Whos”, “Hows,” and “Whats” that might lead them towards their goal.

Tags: 

About the author

Lisa Crispin's picture Lisa Crispin

Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), co-author with Tip House of Extreme Testing (Addison-Wesley, 2002) and a contributor to Beautiful Testing (O’Reilly, 2009) and Experiences of Test Automation by Dorothy Graham and Mark Fewster (Addison-Wesley, 2011). She has worked as a tester on agile teamssince 2000, and enjoys sharing her experiences via writing, presenting, teaching and participating in agile testing communities around the world. Lisa was named one of the 13 Women of Influence in testing by Software Test & Performance magazine in 2009. For more about Lisa’s work, visit www.lisacrispin.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03