Effect Mapping

A Game Changing Techique for Agile Product Planning
Member Submitted

and achievements didn't come into the development pipeline for the next six months.

Product management using effect maps
Effect Maps are useful for much more than just an initial scoping exercise. I found them very useful as a catalyst in product management. They facilitate the implementation of several very good ideas for iterative product management, crucial for successful delivery of agile and lean projects:

  • setting clear goals
  • providing a shared understanding of quality
  • prioritising based on business value
  • iterative long term product release planning
  • deriving scope from goals
  • focusing deliverables on business value increments
  • preventing scope creep
  • supporting scope change and reprioritisation

Setting clear goals
If a project succeeds in delivering expected business value, it is a success from a business perspective. This is true even if delivered scope ends up being different than what was originally envisaged. On the other hand, if the project delivers exactly the requested scope to the word but misses the business target, it is a failure. This is true regardless of the fact that delivery teams can blame customers for not knowing what they want. Unfortunately, I've seen far too many projects where this business value is not clearly communicated to everyone. Very often it is not even defined, and in the cases when it is defined it is too vague to be useful. Such definitions make it hard to objectively measure whether the project actually delivered what was wanted. As a consequence, teams focus on ticking boxes by delivering scope as a measure of success.

Effect Mapping helps to define goals because it requires us to identify the expected goal as the first activity. But we can go further. Clear goals help teams design appropriate solutions. A solution to increase the number of players by 5% over 12 months is completely different than one that would increase the number of players by 100% over 6 months. To support the team in delivering the right system, we need to clearly define the business target. A great trick to ensure a shared understanding of the expected business effect is to decide how to measure it. After we have answered the question " Why", we should go further and answer the following question:

  • How will we measure how much any future delivery matches the expectations?

Defining the goal in a measurable way requires sponsors to think really hard and define precisely what they really expect out of a software project. That will help to align the expectations of the sponsors, the stakeholders and the delivery team. It will also allow the delivery team to design the appropriate solution and invest effort proportionally to the expected return.

Identifying measurable goals (such as “one million players” instead of just "more players") is key to ensure a shared understanding of what a project is supposed to deliver. Tom Gilb argues that measuring such effects and deciding how to measure them significantly improves the chances of success of a project [Gilb05]. He also presents several techniques for measuring things that do not seem easily measurable. For further examples of measuring seemingly intangible things, see [Hubbard10].

Providing a shared understanding of quality
Similar to the way that project goals are often vague and not universally communicated, software quality is rarely defined precisely. This causes misunderstanding, misinterpretation and confusion about what a project needs to deliver. The interpretation of quality and the argumentation around that is delegated to a quality assurance role without much involvement from any business sponsors.

With an arbitrary interpretation of quality, there is nothing to help teams decide how much to invest in certain aspects of their

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!