Opportunity Mapping / Epic Mapping Exercises

I’ve had the chance over the last few months to create an “Epic Mapping” (also known as Opportunity Mapping) for some products that I’ve been involved with.

I first came across the Epic Mapping technique in the book User Story Mapping, by Jeff Patton.

The main idea behind User Story Mapping is to move from a traditional, flat, one dimensional scrum backlog, to a two-dimensional user story map. The user story map shows the activities (user stories) for the different users involved moving along the horizontal axis across the top, against the tasks required to build the feature to support each activity listed vertically underneath.

The tasks can then be grouped and prioritised according to which features and user stories need to be delivered first. The User Story Mapping technique is summarised in this blog post.

The Epic Mapping (or Opportunity Mapping) technique is the big picture product version of User Story Mapping. Instead of outputting User Stories from the exercise, we are outputting “Opportunities” to solve user problems and deliver value to the customer. These “Opportunities” translate into Epics in the Product Backlog (hence “Epic Mapping”).

The Epic Mapping above is taken from Jeff Patton’s “User Story Mapping” and shows the backbone or “Big Story” of the users’ journey through a product to achieve their goals. The details of what needs to be built can then be listed vertically under each step.

The first Epic Mapping exercise I was involved in recently took place in a friend’s conservatory:

The final version, mapped out on a map on the floor, was as follows:

The main benefits of the exercise were in identifying:

1. the different areas of the product that would need to be build
2. which areas would be toughest to build, and require more research
3. which areas had unknowns that we needed to look into more
4. what we could start building right away
5. what might be a useful Proof of Concept or MVP

The second Epic Mapping exercise took place in my day job as a Business Analyst. The purpose of the exercise was to map out what features we would need to build to allow friendly users to test out our product on a production-like environment.

The (blurred) final version, mapped out on the conference room table, is below:

The main benefits of the exercise were in identifying:

1. What do we need to do to get a production-like environment up and running?
2. What do we need to do to make the product usable and self-manageable for a friendly user?
3. What are the high-priority and high-value features we would like to build first with the goal of getting feedback from the friendly user?
4. What features currently listed as high-priority on the roadmap can be de-prioritised?

As with all of these techniques, the value gained is not in completing the mapping, but allowing the mapping exercise to structure your thinking and priorities with regard to the product. It also serves as something to return to as a guide when different crossroads are reached in building the items in the map.

The Epic Mapping exercises above were small, but proved valuable as a technique to map out where we were, and allow us to get moving with at least with some sense of direction.

‍