too few stories upfront doesn't give sponsors the confidence they need to support a project. Managing and delivering projects with dynamic scope scares people who are responsible for successful delivery. Many iterative planning and delivery practices might sound like black magic at a higher level and they do not allow managers to see the forest for the trees, so they push for huge lists of stories and ask for more control.
"People asking for control really want visibility", said Elisabeth Hendrickson during her keynote at the Agile Testing Days 2010. She supported that statement with data from more than 100 workshops on team transitions she ran, which is as close to a scientific experiment as you can get with software development. The statement is certainly true from my experience. Clients and project sponsors want commitment and sign-off because they are afraid that their goals will not be met and because they have no visibility over software deliverables. User stories, as great as they are for short-term planning, are useless for high level visibility.
Effect Maps address this problem better by clearly visualising stakeholder needs and allowing us to prioritise at that level. Drawing an Effect Map up to the third level and sharing it ensures that stakeholders and their needs will be addressed. This also means that we only need the first three levels of the map for mid term and long term prioritisation and release planning, which enables us to postpone the discussion on detailed scope for everything but the highest priority stakeholder needs.
Defining the first three levels of a map in a measurable way ensures that there is a clear target for iterative delivery, without actually defining how we'll get there. Such definition of quality frees us to come up with the best possible scope, just in time when we need it, and not waste time on defining or managing scope too much up front. It also enables us to clearly provide visibility to project sponsors of how much we have delivered up to any point in time.
Effect Maps allow us to provide good visibility instead of control. As the project progresses, we can mark areas of the map that have been delivered, identify stakeholders whose needs are satisfied and plan whose needs will be fulfilled next. This high level visibility provides the delivery team and the project sponsors enough information to track progress and plan effectively further scope iteratively. In addition, this high level visibility enables people to see the big picture so that they can prioritise and analyse further scope for immediate delivery.
Deriving scope from goals
Techniques for collaboratively deriving scope from goals, such as Feature Injection [Matts09], are becoming increasingly popular in software development. Although still in an early adoption phase, such techniques are used by teams to build in quality from the start and further enhance the effects of techniques such as specification by example [Adzic11].
Effect Maps facilitate this process by helping a team to clearly focus on a business goal while planning scope. Drawing an Effect Map requires us to define implementation scope to satisfy a business goal. By allowing us to postpone the discussion on system features too soon, Effect Mapping enables us to derive scope from goals just in time. This fits in nicely with flow-based software delivery methods, such as Kanban.
Focusing deliverables on business value increments
Focusing delivery on increments of business value instead of increments of technical functionality provides fast feedback to project sponsors about their assumptions in iterative deliveries. It also supports the delivery team in learning more about the business domain and