Effect Mapping is a game-changing technique for high level project visualization. It provides stakeholders and sponsors with an excellent level of visibility and helps to drive software projects towards delivering the right product with a high level of quality.
Effect Mapping facilitates the implementation of several techniques of agile planning, product design, prioritisation and scoping. In practice, I’ve found the combination of these techniques by far the most powerful way of iterative product management so far.
Also see this video with an experience report.
|
|
Thanks for posting!
I’ve been excited about effect-maps since I heard you mention it at Øredev
In your example you put all the players/users in one group, while in the original book Balic&Ottersten (in their example) spend quite some time dividing the users into lifestyle-, spontaneous-, regular- etc.
Any thoughts on this? Is it worth trying to divide the users into separate groups/personas?
I suppose in your example players as a group work OK, but have you done splitting into user-groups? And if so, any tips for how to categorize them usefully?
I think stakeholders are all valid examples of people who could help. In this case, all players help the same. In other cases, different categories of players could help differently. Try googling and researching for user personas. Good books on that are Inmates are running the asylum and User stories applied.
Thanks for your reply, and also for your pointers. I agree with you that in your example, all players are indeed one group
However, I have one related follow-up question, regarding your switching of ‘how’ and ‘what’. It seems to me that by doing this, as in your example, you ‘ask not what you can do for your users, but what your users can do for you’.
I.e:
How can players help with the goal of attracting 1 mill. players? => By inviting friends.
What are the capabilities of the system that enables this friend-inviting? => By having incentives, by allowing personalisation etc.
The focus seems to be on the business need/goal, and how users can help, rather than how you can reach your business goal by helping users and address their needs.
Of course, sticking to your example, I agree that the other way around gets more ‘fuzzy’:
What do players want? => Recognition of skill from their friends
How should the system adreess this need? => Enble invites, personal tournaments, etc.
But in your example, all the players are in one group.
In the orignal example in Effect-managing IT (they don’t put a measurabe goal in the center, but that is not the point), and their example of a Carpool-company:
In What-How-style:
Goal:Average travel-pattern for user is carpool:40, public tranport:30, taxi:10, rental:10, other:10
Who can help? => Occasional users (among other user-groups)
What are their needs? => Want to be able to be spontaneous
How should the system cover this need? => Flexible booking channels, Find cars close to me etc.
I How-What-style:
Goal:Average travel-pattern for user is carpool:40, public tranport:30, taxi:10, rental:10, other:10
Who can help? => Users
How can they help? => Use the cars more
What can the system do to increase usage? => Have flexible booking channels, Find cars close to me etc.
The point being that from the business perspective users look the same unless they have som special powers to help us reach our goal (the key differenting factor), while if we try to differentiate users based on different needs, we may have a better model and understanding of our users.
The How-What style also seems to contrast with what you write about Weinbergs definition of quality (value delivered to som person) and the concepts you say are key to specify quality:
- Who is that person? Or alternatively, who are the people affected by our work?
- What kind of value are they looking for from the system?
The second question (What kind of value..) does seem to be lost in the How-What-style?
I’m sorry this comment is so long, and it is not meant as an attack. I only wonder if you have reflected on these issues and/or find them neglible in practice?
Hi Gojko,
Interesting paper. I heard you talk where I’m working recently and was keen to investigate using these.
I’ve got a couple of points you may like to opine on.
1) The project goal, represented in the centre of the map, is one of a number of project goals. Would you expect to have one map per goal? If this is the case, I see a couple of issues: (1) you end up with a number of maps running at once that you have to keep track of, and (2) there is a fair chance that there will be some overlap between the items on each map.
2) I’m not sure this works for applications which are “low touch” – something which may provide a core function for a company/department, but does not have a great deal of user interaction. I tried it, and just ended up with a stakeholder of “IT” with a load of standard IT project tasks that needed to be completed (define interface, define class model, etc) which all have the same level of priority as without them the system wouldn’t function. This does provide some limited use in that you can visualise tasks and tick them off, but you can do that in microsoft project….
Perhaps I’m missing something
@Sjur
absolutely. from the perspective of the team creating an effect map, we’re doing a project to achieve our business goal in the centre of the map. stakeholders have needs related to that goal, and can either support or obstruct the goal. the benefit for them is in the need being supported. the benefit for us is that the goal is being achieved or obstructions are removed.
I think that the how-what is mostly language specific. I find it easier to ask “how” to tease out examples in English. As I said in the paper it’s the same semantic question, just asked differently.
@Luke
I did this for milestones with a single goal. For a project with several goals, the honest answer is don’t know, I haven’t tried it yet in a situation like that. My first attempt would be to prioritise goals and deliver them one by one as milestones with a single goal. Another way could be to have multiple maps and then look at them. this might not be a problem with only a few goals. If you have too many goals for a project, there are much larger problems waiting for you than not being able to draw a map. in fact, having the requirement to put everything on a map might tell you that the project is too broad. if you have too many goals, maybe what you consider goals are effectively stakeholder needs (level 3), not the overall goal (level 1).
low-touch stuff might mean two thins:
1. you don’t have a UI, but the system provides some clear business value (eg batch reports for regulatory purposes). in that case it’s clear who the stakeholders are
2. you are just looking at a technical component of a larger system, which in itself doesn’t give anyone any value. in this case, you’re not focusing your deliverables on business value increments and the map will help you do that. see also http://www.featureteams.org/ for information on feature vs component teams
Gojko!
Once again you have filled a gap in my knowledge. As for many agile techniques we often focus on details leaving the work putting it all together for “someoneelse”. At least that’s how I’ve learned TDD, BDD and user stories. These are all great stiff but how do they come about? How do you get to a knowledge level that gives you any cofidence in writing down a user story. Or scenarios for that matter.
There are not much out there to guide us (read: me) but now I have this tool!
Thank you!
Effect mapping seems very interesting, but the main problem here is setting a relevant goal. This is rather similar to the benefit part in usual user stories. But effect mapping does provide easier high-level plan prioritization and feature management. Seems so.
The example with Facebook game is nice, but is that goal actually a good example for effect mapping?
It is measurable that’s true. But no features that originate from the mapping imply one million users. They’re just features that will increase the number of users. But they don’t imply quantity in any way shape or form. By these features we can’t assure to reach the set goal.
That’s why I think although measurable, quantitative goal isn’t always good.
I can give another vague example of seemingly great goal definition: “Have >10k monthly revenue” but how can we assure features that will directly lead to this figures. I don’t think we can. We can only set out goal to be Increase income by 25% based on existing features. This leads to a growing income but maybe even this can’t be directly related to mapped features. Maybe all we can set our goal to is Increase income.
Relating features to actual goal figures seems unreliable, very hard or even impossible. If it was easy everyone could be successful I suppose.
It’s also harder to measure whether goal accomplishments are related to our newly defined features or just a result of existing ones.
To relate back to your Facebook example in the paper. You point out that having a goal of “1M players” is better than “more players”, but I’d argue that your who/how/what parts don’t relate to goal numbers. They just relate to “more players” and nothing more.
Maybe I’m not understanding this completely but maybe setting quantitative information to goals has more mental effect than actually features derived from the mapping. Maybe that’s the idea. Mentality.
You tell me/us…
Hi Guys,
wery nice and interesting debate on Effect Mapping! I am the author of the book, and is now currently working with those that wants to be certified effect strategists. I would love to discuss and give answers to all your questions but not in writing… Best would be to meet, is it possible for you to attend the course on Effect Mapping, next time in may (easily done in englsih) .http://www.inuse.se/kurs-effektkartlaggning/