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