Mastering User Story Mapping: A Complete Guide to Agile Requirement Definition

1. Overview

We recommend using user story mapping and user story methods for product requirement definition.

2. Role Responsibilities

PM : Assist the product manager in arranging requirement definition work and submit requirement review requests.

PMO : Receive project team’s requirement review requests and coordinate the review process.

QA : Participate in requirement analysis, user story evaluation, and confirm acceptance criteria.

SDM/SDE : Participate in requirement analysis, user story evaluation, and confirmation.

TPM : Own product requirement definition and submit related artifacts.

UED : Participate in requirement analysis, user story evaluation, and confirmation.

3. Basic Process

Step 1 – Identify and Analyze Users : Analyze product users, segment them into roles, and produce a complete list of user roles.

Step 2 – User Research and Collect Stories : Gather raw user stories through interviews, surveys, observations, workshops, etc., and create a list of stories for each role.

Step 3 – Create User Story Map : Organize collected stories, discuss, split, prioritize, and assign to release versions; iterate until a satisfactory map is achieved.

Step 4 – Estimate Story Points : Estimate points for stories planned for the upcoming sprint.

Step 5 – Update Backlog : Update the backlog document and import it into JIRA (template: product backlog).

Step 6 – Refine Stories : Detail the stories for the next sprint, update the PRD, and discuss with the team.

Step 7 – Confirm Acceptance Criteria : Work with development and testing teams to confirm acceptance criteria and update the PRD.

Step 8 – Clarify Non‑Functional Requirements : Discuss with the development team, confirm non‑functional needs, and update the PRD.

Step 9 – Requirement Review : Proactively apply for a review, self‑check against the requirement checklist, and pass the review in the definition phase.

4. User Story Writing Guide

4.1 Identify and Analyze Users

The first step is to list all user roles and refine them:

Brainstorm to generate an initial set of user roles.

Organize the list, merge overlapping roles, and group similar ones.

Consolidate and prune the roles to a manageable set.

Detail each role’s characteristics such as usage frequency, domain knowledge, computer skills, and special experience requirements.

Two additional techniques help enrich the analysis:

Persona : Create a realistic fictional character for important roles to represent target users.

Extreme Persona : Imagine extreme users (e.g., a drug dealer for a PDA) to uncover hidden stories.

4.2 Writing User Stories

4.2.1 Main Content

After identifying roles, collect stories that describe valuable functionality for users, systems, or purchasers. Use interviews, surveys, observations, workshops, etc. Remember that story collection is ongoing and should be revisited each product cycle.

A user story consists of three parts:

Card : Title and description, often in the format “As a , I want to so that .”

Conversation : Dialogue to flesh out details.

Confirmation : Acceptance criteria that define when the story is done.

4.2.2 Writing Principles – INVEST

Independent : Stories should avoid inter‑dependencies.

Negotiable : Details are discussed, not fixed contracts.

Valuable : Deliver real user value.

Estimable : Able to estimate using story points.

Small : Fit within a single sprint; large stories must be split.

Testable : Must have clear acceptance criteria.

4.2.3 Signs of Poor Stories

Not written from the user’s perspective.

Too large (spanning multiple sprints) or too small (inflating estimation noise).

Excessive inter‑dependency.

Speculative features added without evidence.

Overly detailed business requirements that turn the story into a large document.

Premature UI or technical details.

Difficulty prioritizing because stories are vague or overly granular.

4.3 Organizing Story Hierarchy

After gathering an initial list, structure stories into three levels:

Module : Highest‑level grouping of related features, often aligned with strategic product areas.

Epic/Feature : Large functional pieces that can be broken down into multiple user stories.

User Story : Smallest deliverable unit, completed within one sprint.

These levels form a tree that can be visualized with a user story map (see images).

5. Estimating Story Points

5.1 What Is a Story Point?

Story points represent relative effort, complexity, and risk. One point roughly equals one ideal person‑day of work (coding, unit testing, and delivering quality code).

We use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34) because humans differentiate large numbers less precisely, making estimation more reliable.

5.2 Estimation Process

The product manager drafts initial points.

The whole team discusses and refines estimates in a requirement‑review meeting.

Typically 2–3 rounds are performed, comparing stories to a few benchmark stories to achieve consensus.