several items that could contribute to that feature. In typical agile jargon, items on the fourth level could be epics. We can split them further into items on the fifth level or even sixth level, that represent user stories which can fit into an iteration. Another way to look at further levels could be feature themes at level 4, minimum marketable features at level 5 and user stories at level 6.
I also found it useful not to dive in too deep early. Going up to the level of stakeholder needs at the start proved to be quite enough for anything not immediately important. This approach allowed the teams I worked with to focus on the things that were important immediately but still keep a high level overview of the entire scope for later.
Not all stakeholder needs will be equally important or risky and not all software features will be equally complex. Visualising those aspects of needs, activities and features can help to identify low hanging fruit and to avoid death marches. Having this information on the map supports effective planning and prioritisation, so I extended the maps with simple visual symbols to represent importance and technical complexity of stakeholder needs and features. I use stars to represent importance and numbers to represent complexity. All these are rough, relative estimates, so don't worry too much about getting them right.
An example: Facebook games project
For an example, see Figure 2. This is a simplified Effect Map from one of my previous projects, an online games platform. The business stakeholders originally asked for levels and achievements in games as the next milestone. Instead of implementing that straight away, the team and the business stakeholders drew the map together.
It turned out that the reason why the business users asked for levels and achievements was to significantly increase the number of active players (the target was set measurably to one million). Once we have understood the goal, we started thinking about who could contribute to it. One obvious group were advertisers, who could send bulk invitations or publish our ads. Another group were the existing players, who could invite their friends, write about our games or recommend them to other people online. A third group was the development company itself, who could organise PR events or send out invitations. These high level examples directly translate into the second and the third level of the map.
We then added stars to mind-map elements to visualise the expected importance. Inviting friends works virally, because invited people can also invite others and it is a direct call to action. For that reason, it is likely to provide an exponential return on investment. Posting about games is not going to be that effective because it does not have a direct call to action. Recommending games is going to be even less effective because has a more limited reach.
We then came up with ideas how our software could support players in inviting their friends, posting about the games or recommending. We mostly focused on inviting and posting, as they seemed the most effective. With some branches we went to the fifth level, breaking down scope into smaller tasks and assigning numbers to those tasks to show a very rough estimate of implementation complexity.
The original requirements (levels and achievements), showed up on the map under giving existing players more content to post about. We decided together that inviting friends is more likely to bring large numbers because it is viral. So we focused first on redesigning the web site to provide incentives for invitations. Levels