From The Blog

Impact Mapping to Better Understand Features

Crisp’s Blog » Impact Mapping – the developer’s cut Do you, a developer, have a feeling that the user stories your product owner is but a...

Do you, a developer, have a feeling that the user stories your product owner is but a list of ideas prioritized on gut feeling only? That the relationship between them and their purpose are vague? Impact Mapping is an agile conversational tool by Gojko Adzic that may be primarily for product owners but hey, a developer needs a purpose too! An Impact Map makes it easier to understand the link between a business goal at one end and a system feature on the other. The goals and the impacts are measurable and easier to prioritize than a long list of user stories. So what is it then? Let’s see it from a developer’s point of view.

 

An Impact Map makes it easier to understand the link between a business goal at one end and a system feature on the other. The goals and the impacts are measurable and easier to prioritize than a long list of user stories. So what is it then? Let’s see it from a developer’s point of view.

Here is my definition: An Impact Map connects a business goal with actors that experience an impact when following user stories. Goals are measurable business goals and user stories are the deliverables. The map gives you the opportunity and structure to discuss what the current roadmap is.

An example, a bit small to give you an idea. Let’s say that the PO comes in to the office in the morning during the stand-up. She has a wonderful idea for your webshop, when the customer has gone to the checkout, entered all payment information, then there sometimes will be a new page with socks. There are several possible reactions here, the immediate could be anxiety over the technical complexity involved given your current solution. But you need to come on speaking terms with your PO so you head over to the whiteboard instead.

From the little you’ve heard so far, you understand that there is at least some customer involved and it is about the checkout process. But you have only a vague idea on why this is such a good idea. Neither how you will know if it was a good idea, once implemented.

At the whiteboard, you start on the far right and write some user story outlines, as this is all you know at the moment. From them you aim to work backwards to the business goal. Yeah, backwards, it is not always like that but often we come up with ideas before we even tried to formulate the problem.