I just read a copy of Gojko Adic’s Agile Product Management using Effect Maps because I too still find high-level product visualisation problematic when trying to do iterative product management. Adzik explains “Effect Maps” (which are structured mind-maps) which allow for design, priorisation and scoping. It well worth the read. Here’s a few thoughts I had while reading:
Simple technique for a working meeting
It brings people together and always has at its base of discussion to the business value/problem to be solved. The mindmap starts from the question of the goal: Why are we doing this? What is the desired business change? I could see structuring early discussions with senior people. Likewise, I could all stakeholders in the room and use the technique.
How to get see the whole and defer ambiguity
The four-levels in the mindmap is detailed enough to move through the Why, Who, How and then detailed What. But in practice, there is loads of detail still to come in the What (the features) that the team will need to work. Be able to defer with the implementation details to when starting on the specific is an important strategy to avoid wasteful work and delays.
Good for Target Cost development-type contracts
I tend to work on Target Cost contracts but always struggle with what that end goal and target cost is. Few can articulate what their break-even (or often opportunity) cost is. The effect map should provide a good way to identify needs and the potential investment required. Usually, in the end, while I might suggest a cost clients also usually have a sense of what they can afford against there (often implicit) view of its value. Interestingly, investment is the correct vernacular over cost. Most of my clients want to capitalise my work rather than pay for it out of operational budget.
Avoids lists of stories
If you really wanted to get me started of a rant then start sputing that user stories are the technique to counter requirements documents. In my experience, this assumption always leads you back to the same root-cause analysis: the analysis wasn’t refined enough (ie the story was too big, not well defined, could have been broken-up more). Although all those reasons are true, I tend to see that there wasn’t enough context because the stories while grouped (into themes) they really didn’t have good prioritisation, scoping at a higher level. Or as he puts it, user stories are being used for managing long-term release planning. The effect map helps by not using the user stories at level. This is nice because it keeps in the front of our mind that user stories are a merely rubric, albeit a very useful one. The effect helps us keep user stories at the outmost leaves of the map and not toward the root. As he says,
User stories are de facto standard today for managing long term release planning. This often includes an “iteration zero”, a scoping exercise or a user story writing workshop at the start of a milestone. During the “iteration zero” key project sponsors and delivery team together come up with an initial list of user stories that will be delivered. A major problem with the “iteration zero” approach is the long stack of stories that have to be managed as a result of it. Navigating through hundreds of stories isn’t easy. When priorities change, it is hard to understand which of the hundreds of items on the backlog are affected. Jim Shore called this situation “user story hell” during his talk at Oredev 2010, citing a case of a client with 300 stories in an Excel spreadsheet. I’ve seen horror stories like that, perhaps far too often.