When and How to do User Story Mapping

What is a User Story map?

User Story Mapping or Feature/Epic Mapping is a visualisation technique where a product team maps out their user’s journey. It is used to elicit and capture requirements, but also helps to build a common understanding of various problems that need solving. This enables stakeholders to think about, and visualise, what they want to get out of the product.

User Story mapping is most commonly used at the start of a new engagement, and at the beginning of conceptualising a new capability or feature within an existing product. It brings form and structure to requirements that are scattered and uncategorised, and helps to define an MVP and/or and MMP when working with stakeholders. The team can refer back to the User Story map to stay on track with what’s being developed, to create and maintain roadmaps, and also for prioritisation of features.

The User Story map is a living breathing thing. Changes can be visually made and updated easily, allowing stakeholders to quickly understand how they impact the overall product, as well as any milestones or dependencies.

What does a User Story map look like?

A User Story map is split out by horizontal and vertical axes.

Below is a User Story map for an event booking system. The activities and tasks a user could perform on the product (or the epics/features) are listed on the horizontal axis. Jobs to be done (User Stories) to enable these activities reside on the vertical axis. Then Swim Lanes split the stories into their required/anticipated release phases.

Definitions

  • POC – Proof of Concept
  • MVP – Minimal Viable Product
  • MMP – Minimal Marketable Product

When is a User Story map handy?

User Story mapping is mainly used to create a shared understanding of your customers and the activities they would perform on your product. However, there are a few more reasons why you should create a User Story map.

Key Activities

The key activity streams, integral to successful User Story mapping outcomes, are:

  • Define your features
  • Create some Indicative User Stories
  • Prioritise your features/stories by release
  • Identify stakeholders who may not be engaged already

Define your features

Determine what a user would do to use the product (these are your activities).

Create Indicative User Stories

Indicative User Stories are a great way of sketching out some obvious (and in most cases key) user stories that create starting points and conversation starters. This is used to flesh out the more detailed requirements that are needed to develop the capability/feature with stakeholders.

Prioritise features/stories by release

Your User Stories can be mapped out as an initial take of what you and the stakeholders feel is required to initially prove that the product is workable. That is, whether or not it’s ready for an MVP release, and what desirable features would be needed for an MMP release.

Identify stakeholders

Identify any stakeholders who may not already be engaged but might be integral to the success of the delivery.

Some of the suggested roles to consider are:

  • Product Owner/Business Analyst (uncovers requirements/facilitates)
  • Business Stakeholders/SME’s (clarifying requirements and pain points)
  • Program/Delivery Managers (determine priorities)
  • Solution Architects (determine architectural impacts/changes)

Example initial concept User Story map

In the below scenario, we want to understand the problem that needs to be solved, determine how the user will perform actions in the product, and identify what’s needed to develop the product further.

The scenario: As a Patron, I want to be able to find music event’s near me and book a ticket, so that I can attend the event.

Potential outcomes of the initial User Story Mapping session

  • The session provides your business with a powerful visualisation of what is required to develop your ideal product.
  • Stakeholders feel empowered to contribute – not only through providing requirements, but by seeing a great example of how thinking iteratively and collaboratively can produce a clearer view of the product that they want to develop.
  • The product development team come away with an indication of priorities and dependencies and, in most cases, a starting point, as Features, Epics and User Stories are defined and developed.

Key Concepts

  • User Story map process
  • Workshops
  • Visualisation – steer away from words, use pictures to tell the tale

Key Inputs

  • Ideas for the product
  • High level understanding of the product
  • The right audience

Outputs

  • All ideas are captured
  • Structured visualisation of requirements
  • Prioritised features
  • Input into the product roadmap
  • A clearer understanding of what’s next

Nathan

Nathan Bruce
Lead Business Analyst

Nathan Bruce is a Lead Business Analyst at Terem. He has more than 10 years of experience in API Platform integration for a large government agency and software companies, with a strong focus on Agile, technology and integration.

LinkedIn: linkedin.com/in/nathanbruce

Back to Blog