Bitacora: impact mapping

Introduction

1. The diary (aka bitácora): towards alignment in distributed environment.
2. Bitacora: environment definition.
3. Bitacora: personas

Why Impact Mapping?

The steps taken so far are standard for me since long time ago. At this point though, depending on the nature of the product, I did not have a fixed procedure to follow until the creation of user stories. At some point I ended up creating use cases and relating them through mind maps.

A few months ago I read Impact Mapping, from Gojko Adzic, a reputed Agile consultant and writer. He proposes a method to go from business model to Epic/stories description that I found interesting. It fills my gap with a systematic approach using a tool I love, mind maps.

It also helps deprecating a common challenge with use cases. When you get dirty with them, it is easy to write many that are not key for the main goal of the tool. Once you have many of them, it might become tough to relate and prioritize them.

Gojko propose to get rid of use cases and go directly from impact mapping to describing the epics/user stories. I have not been able to do so. It might be that I am simply too hooked to use cases and it is only a matter of time before I follow exactly the new process. It can be also that impact mapping is rigid compared to use cases so you can only get rid of them in a second/third iteration of the impact mapping process…

In any case, for Bitacora I started with an impact mapping. Once it was mature enough, I started from scratch doing the use cases. My impact mapping ended up containing 75% percent of the use cases…. and already structured. I assume that, in a collaborative design process, this percentage will be greater. I assume also I can get better with practice. So I am confident to adopt Impact Mapping exclusively. I might loose some use cases but I gain structure. Relevant but at this point ignored use cases will probably pop up later in the design process or during development. Mistakes in the prioritization due to structure deficiencies has a bigger (negative) impact along the product life cycle.

What is an Impact Mapping? 

Mr. Adzic describes in his book Impact Mapping as “a mind-map grown during a discussion facilitated by answering the following four questions: Why?, Who?, How?, What?”

1. Why: center of the map, represent the goal of our application. It should include the desired achievement based on a key metric.
2. Who: first level of the mind map, it refers to actors who can influence the outcome. These are the personas. At this point of the process, it is not mandatory to describe them in detail
3. How: second level of the mind map, it refers to impact we are trying to create on the actors, that is, how the product change their behaviors.
4. What: third level of the mind map, it refers to the scope, that is, what can we do to achieve the desired impact. Depending on the dimension and complexity of your product/service, this third level will be close or far away from a user story. You can either extend the What section into sub-levels (product approach) or define epics (scrum of scrums). 

You can get further information and diagrams in the website impactmapping.org I am still unsure about the direct relation between the What section and what engineers understand as a derivable. I prefer to reserve derivable as concept to a later stage (user stories) so they are analyses in detail by the product team, together with acceptance criteria. I find this arguable though.

• understand the root of the problem I am trying to “mitigate/solve”.
• know where the idea for the solution (Bitacora) comes from. 
• get yourself in context (environment and personas).

you should be able to understand the coming Bitacora Impact Map.

If not, I have probably done something wrong, which wouldn’t surprise me 🙂 or you are not familiar with the problem to solve. Some of the ideas like “tag page” will be described in the user stories, so don’t panic, we will get there.

Since these graphs has gone through several review processes, it might happen that the partial pics are not 100% up to date. The general impact map should be though. 

The center lacks the quantitative goal. Since this is an ideal exercise, I will ignore it for now. We will go down to metrics and measuring impact at the very end.

At the end of the previous article, about personas, I wrote that for a introductory analysis, we could reduce them to 5. Since I went further, I considered groups and described personas for each group since we will use them at some point.

 This is the second level that defines the impact for the other personas.

 As you can see, the impact is described in the following areas:

• Participation: the tool should promote an increase of interactions based on what each persona did.
• Team/project follow up: bitacora should make following up a team or project activity easier.
• Analysis: analize what the team is doing or has done should be easier with Bitacora. Self analysis is as important.
• Report: Bitacora is designed to improve reporting in both, vertical and horizontal direction (matrix).
• For Team Member, Bitacora should work as the central point for everyday (short term)  information.

Level 3: What?

For a easier visualization I have divided this level in three different images. The first one correspond to Product Team:

This is the third level for the Scrum Master persona:

 And this is the third image, corresponding to the other three groups:

You might be wondering what are the icons for.  

I mentioned earlier that one of the advantages of using Impact mappings is the structure. As a consequence, you can start to assign priorities to the different scopes which is very useful before writing down the User stories.  

Note: 

The result of this process should in general be features, but in certain circumstances, at this point it could also be processes. I used the “help” icon to reflect them. his concept is arguable. I am at this point unsure if it will survive the story description.