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