Effect Mapping

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

technology. This is a key element of planning with User Stories (see [Cohn04]). Focusing delivery on the most valuable Minimum Marketable Features (MMFs) allows the management to plan releases to achieve the best level of return on investment from the project [Denne03].

By focusing our planning and prioritising on addressing stakeholder needs, we ensure that deliverables actually provide business value. Effect Maps facilitate structuring a project around stakeholder needs. They help us break down how to satisfy stakeholder needs into MMFs and User Stories hierarchically.

In the "iteration zero" approach, teams need to define a large number of stories quickly. They focus on deliverables ("I want ..." part), and invent stakeholders ("as a ...") and benefits ("in order to...") halfhazardly to obey the form. Stories become generic such as “as a trader I want to trade so that I can trade”, with dozens or hundreds of stakeholders and benefits. This completely defeats the point of user stories that are supposed to communicate intent. The need to fit stories into something easily deliverable in isolation disconnects the deliverable piece from the value expected by the customer, in particular when the benefits and stakeholders are invented on the fly. Note that this is not an issue with user stories as a technique, because they were designed to deal with this very problem, but an issue with how teams commonly misuse them.

Effect Maps facilitate the correct application of User Stories as they help us directly answer who is a stakeholder for a particular feature and how that feature helps the stakeholder achieve something useful.

Preventing scope creep
With a clear map from features to the end goal, it is easy to spot if a particular suggested feature is not relevant for the ultimate goal of a project. With large flat backlogs of ideas it is less easy to spot such things. Effect Maps achieve the same effect as the Goals-Features-Requirements hierarchies described in [Berkun05], ensuring that everything in scope really contributes to the goals. This helps to avoid scope creep by providing an argument against unnecessary pet features.

Supporting scope change and reprioritisation
Business priorities really change at the level of stakeholder needs. If a product backlog is described with an Effect Map, the team can effectively react to such changes.

Effect Maps allow us to derive scope incrementally and just in time. We do not have to make many decisions on scope for individual stakeholder needs before we really need to start investing in them. Even if we have already defined several levels of features for the reprioritised stakeholder needs, there is a clear hierarchical map that shows us what gets moved. We can stop working on any features related to needs that do not need to be satisfied now and start working on more important business deliverables. With product backlogs that are just linear stack of stories, we don't have anywhere near this kind of visibility, which is one of the reasons for "User Story Hell."

Shifting the mindset from cost of IT to investment in IT
When we discuss priorities and plan without an assumed software implementation scope, my assumption is that we can change the tone from how much is it going to cost/take to have something delivered to how much the sponsors want to invest in supporting a particular stakeholder need. (This is the only assumption in this paper, I've tried all the other ideas in practice successfully). By applying Gilb's measurability ideas to how much satisfying stakeholder needs will contribute to a goal, we can get an idea of what is the expected outcome of the

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

Oct 12
Oct 15
Nov 09
Nov 09