User Story Mapping
A simple, agile way to define a project scope
There’s the vision and the idea of the product, there are the high level requirements and mock-ups. How do we document the user experience and quickly align the team and stakeholders to create a working plan?
The solution we use to describe a project’s scope is User Story Mapping: an Agile tool that illustrates the functionality of a software from the user experience point of view.
User Story Mapping consists of creating a post-it grid that describes each activity that one or more user roles play in the use of the product.
Describe the user flow
Map the user experience of a product through the description of its features, minimising the possibility of misunderstandings.
Align the work team
Quickly communicate the project’s scope to internal and external stakeholders, maximising ease of reading.
Simplify project estimation
Allow the project team to evaluate the time and cost to implement a project, feature by feature from design to implementation and testing.
Schedule incremental releases
Evaluate and agree incremental releases by minimising market access time, identifying the minimum set of features needed to enter the market quickly.
We were lucky enough to discover and learn the technique of User Story Mapping from its creator, Jeff Patton — Product Manager and author of the book “User Story Mapping: Discover the Whole Story, Build the Right Product”.
What we learned from the User Story Mapping technique
How do we describe the features in a Story Map?
The easiest way is to use the Agile paradigm of Story (or User Story): a textual description of the experience that a user has when using a specific feature.
As a <type of user>, I want <some goal> so that <some reason>.
Template of a Story — learn more about Mountain Goat Software
… and everything which isn’t UX?
There are generic development activities which it isn’t convenient to link to a Story; in this case we use a grouping for everything that is “Non Story”: initial setup, configuration tools for continuous integration etc.
How do we assess an individual Story?
We define and discuss the individual Stories with the project team (who will design and implement them). Each Story is evaluated by assessing the effort required for each type of activity (analysis, design, implementation, testing).
How do we move from a Story Map to a release plan?
By organising sprint work, it’s particularly easy to estimate the number of iterations needed to complete release stages. To fix a speed (“velocity” in Agile jargon) for doing the sprint, i.e. how many points or workdays a team is able to “burn”, just divide the total or partial effort by the team’s speed of execution.
For example, let’s take a project with total effort estimated at 70 points. The team speed is estimated at 5 points. The number of sprints needed to complete the project will be 70 / 5 = 14 sprints.
What’s the difference between the Story Map and the Customer Journey Map?
Customer Journey Mapping is a tool frequently used by marketing or service design professionals. It’s a different technique from User Story Mapping: the first is a more formal document, which describes an experience through a user’s needs and emotional states — including contact points and channels. User Story Mapping is a more streamlined technique specifically designed for software development (but which can also be an inspiration for other design contexts).
These are some of the tools we use in the design and development of the user experience. We’re constantly looking for new processes to improve our work.