From Journey to Story Map

Part six of the product owner toolbox. We have an epic and a user journey for the leave tool. Now we connect them.

Features

A feature is a piece of functionality, or a part of a user journey, seen from the perspective of one group of users. It delivers value that meets the needs of that group. A feature is built through several user stories that belong together from the user’s point of view. It takes more than one sprint and fits within one release.

Features usually come from the product manager, the product owner and other key stakeholders working together. I describe them on a card with six fields:

Field	What goes in
Title	The feature’s name
Benefit hypothesis	The measurable value for the user or the business
Measures	How we’ll know
Acceptance criteria	What has to work
Business value	Why it matters
Out of scope	What this feature explicitly doesn’t include

Features and user stories are similar, because both describe a user need. A feature is larger and more abstract and gets split into several stories. Don’t write a feature in the story format (“As a team lead, I want…”). It makes features and stories impossible to tell apart, both in the backlog and in conversation.

The leave tool’s “team calendar” feature:

• Benefit hypothesis: Team leads see conflicts before they approve, so understaffed weeks in August drop to zero.
• Measures: Number of shifts below the minimum staffing level in July and August, compared to last year.
• Acceptance criteria: A team lead sees all approved and pending absences of their team for any month. Weeks below the minimum are marked.
• Business value: No last-minute temporary staff in the warehouse.
• Out of scope: Public holidays per canton. Absences of other teams.

The out-of-scope line is the most useful one. It’s where the next discussion starts, and it’s written down before that discussion happens.

Story maps

A flat backlog is a list, and a list is bad at showing how its items relate to each other. Jeff Patton’s story map lays the backlog out in two dimensions.

• Horizontally is the backbone: the user’s flow from left to right. It can be a process, a set of activities, a workflow or, as here, a user journey.
• Vertically, under each step of the backbone, are the stories for that step, sorted by priority, with the most important at the top.
• Horizontal lines cut across the map and divide it into releases.

The map gives everyone a shared picture of the product, which is especially useful when you brainstorm an initial backlog. It also shows two things a list hides: gaps (a step with no stories under it) and dependencies (a story that can’t work before another step exists).

Building one takes four steps:

1. Define the backbone.
2. Write the stories for each backbone item, using card, conversation and confirmation (more on that in the next post).
3. Prioritise the stories within each column.
4. Draw the release lines.

A good story map depends on two things: a backbone that reflects how the user really moves, and clear criteria for priority. Prioritise by value to the user wherever you can.

The leave tool’s map

The backbone is the journey from the previous post:

	Check balance	Check the team	Request	Approve	Get decision
Release 1	Show remaining days	Team calendar, approved only	Full days, holiday only	Approve or reject by link	Email with decision
Release 2	Show planned vs. taken	Show pending requests, mark understaffed weeks	Half days	Approve in the app, add a reason	Absence appears in personal calendar
Release 3	Carry-over from last year	Public holidays per canton	Other leave types	Delegate approval during absence	Notification in chat

Release 1 is thin, but it goes all the way through. An employee can do the whole journey from start to finish. That’s the point of the map: every release is usable end to end, instead of having a perfect request form and nothing behind it.

The map also shows a gap: nobody had written a story for cancelling a request. It doesn’t fit in any column of the journey because the journey only covers the happy path. It goes into release 1, because without it the first cancelled holiday becomes an email to HR again.

Release lines need numbers

Where the lines fall depends on what the team can actually deliver. Use the team’s measured capacity from past releases, not the capacity the plan would like. A release line drawn without numbers is a wish.

Next

The map is made of user stories. Next time: what a story really is, and why it’s not a requirement.