Effect Mapping

[article]
A Game Changing Techique for Agile Product Planning
Member Submitted
Summary:

Effect Mapping is a game-changing technique for high-level project visualization. It provides stakeholders and sponsors with an excellent level of visibility and helps to drive software projects toward delivering the right product with a high level of quality. Effect Mapping facilitates the implementation of several techniques of agile planning, product design, prioritization, and scoping. The combination of these techniques is by far the most powerful method of iterative product management.

Effect Mapping is a game-changing technique for high level project visualization. It provides stakeholders and sponsors with an excellent level of visibility and helps to drive software projects towards delivering the right product with a high level of quality.

Effect Mapping facilitates the implementation of several techniques of agile planning, product design, prioritisation and scoping. In practice, I've found the combination of these techniques by far the most powerful way of iterative product management so far.

Introducing effect maps
Effect maps are charts of project scope which help teams ensure that software delivery is focused on business goals, stakeholders and their needs. Mijo Balic and Ingrid Ottersten present the technique in in Effect Managing IT [Balic07] , where they show that creating such a map helps to ensure that a project is focused on achieving the desired business effect (hence the name Effect Map). To create an Effect Map, draw a mind-map by answering these questions:

  • Why are we doing this? What is the desired business change? This is the business goal . Put that goal in the centre of the map so that you can always keep that in mind.
  • Who are the people that can create the desired effect? Who can contribute to the goal or affect it? These are the project stakeholders. Put the stakeholders on the second level of the mindmap.
  • For each element on the second level: How can the target group contribute or obstruct the desired effect? In real life, not in software. These are stakeholder needs. Put them on the third level of the map.
  • For selected elements on the third level: What are the business activities or software capabilities that would support the needs of the stakeholders? These are features. Features are at the fourth level of the map.

In practice, I've found that asking sponsors for examples of how someone could help them achieve the goal is a great way to identify the stakeholders and their needs, in effect to drive the second and the third level of the map. Answers such as "For example, existing customers might help us by buying from us again” directly map to the Who and How levels.

Note that Balic and Ottersten ask What the target group wants on the third level and How a product should be designed on the fourth level. I found it more useful to ask the same questions differently. Asking How is a good way to tease out an example, so it is more useful to ask that when looking for stakeholders and their needs. Likewise, What is better when describing software features as it helps us focus on business functionality rather than implementation detail (I write more about this in [Adzic11]). As a consequence, the summary diagram in Figure 1 shows How and What on different levels than the summary diagram in Effect Managing IT, but the levels in diagrams are essentially the same from a semantic perspective.

I also allow non-software items to be on the fourth level, because software is not always the answer. Paying advertisers has nothing to do with software but might be a very effective way to contribute to a business goal and allow a delivery team to focus on building parts of software that have to be built.

The maps described in Effect Managing IT have only four levels. The teams I work with came up with ideas for the fourth level that were too big to fit into a single iteration, even too big to be user stories. I found it more useful to break down large feature ideas into

Pages

About the author

Gojko Adzic's picture Gojko Adzic

Gojko Adzic is a software craftsman with a passion for new technologies, programming, and writing. Gojko was bitten by the agile testing bug five years ago. Since then he has helped numerous teams implement agile testing practices, written three books on the subject—Specification by Example, Bridging the Communication Gap, and Test Driven .NET Development with FitNesse—and contributed to several open source projects in agile testing. Over the past eleven years, he has worked as a developer, architect, technical director, and consultant on software for equity and energy trading, mobile positioning, e-commerce. and online gaming. Gojko now helps ambitious teams—from web start-ups to large financial institutions—to implement specification by example and agile testing.

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

May 04
May 04
May 04
Jun 01