User Story Mapping: Build a First Release Around a Complete Journey

A flat backlog can hide a broken journey

A volunteer coordinator wants people to find a community cleanup, reserve a place, and cancel if their plans change. A backlog containing “event cards,” “profile page,” and “confirmation email” does not tell the team whether a volunteer can actually complete that journey. Story mapping makes the missing connections visible.

Jeff Patton’s public account of Mad Mimi is a useful real example. He describes a broad product vision narrowing around creating and sending mailers and tracking responses. The lesson to borrow is the way activities preserve the whole user journey while smaller tasks define a release. It is not a reason to copy that product’s features.

We will build a worked map for the cleanup service. The first release covers one free event with morning and afternoon sessions, each with a fixed capacity. Volunteers need no reusable profile. Organizers need a current attendee list, but a separate organizer workflow should not be mixed into the volunteer’s left-to-right story.

Tell the story before writing feature cards

Start with a specific task: “You can help on Saturday afternoon. Find a suitable cleanup, reserve a place, and check where you need to arrive.” Walk through the journey in the volunteer’s language. Use activities such as choose a session and check the reservation, rather than database setup or API integration.

Put the broad activities across the top. Under each one, record what the person does and needs to know. Order alternatives or smaller tasks below the relevant activity. The map is a conversation aid, so a task can move when the team discovers that the story makes more sense another way.

Keep engineering work connected to the task it supports. Capacity enforcement belongs beneath reserving a place because it protects that promise; it is not a competing user activity between choosing and confirming.

Cut a thin release that still works end to end

The first release line must cross the whole journey. Building a polished event browser while omitting confirmation leaves people unable to tell whether they have a place. Conversely, one plain event page can be sufficient if the reservation and recovery paths work.

The table separates required release tasks from later conveniences. It includes retrieve and cancel because this service promises both. Another service might make a different promise, but it must state the alternative, such as an organizer handling changes through a published contact channel.

Estimate the selected slice only after walking it through. If it is too large, reduce optional breadth: support one event rather than an event marketplace, or email retrieval rather than a full account dashboard. Do not reduce scope by removing the outcome feedback or capacity checks that make the transaction trustworthy.

Walk the awkward paths before accepting the map

Now put a volunteer at the final available place. They open the form while another person completes a reservation. On submit, the service must check current capacity and explain that the chosen session has filled. Keep their entered details so they can choose the other session without starting over.

Next remove the network after submission. The interface may not know whether a reservation was committed. It should offer a way to check that same request instead of confidently saying no booking exists and encouraging duplicate submissions. This is a different branch from a known full session.

Finally, use the cancellation link twice. The second visit should show that the reservation is already cancelled; it must not return capacity twice. These paths add acceptance criteria to the release slice, rather than disappearing into an undifferentiated “edge cases” card.

Use the map to run a scope conversation

Invite the coordinator, a designer, and someone responsible for implementation. Ask one person to narrate the first-release row while the others identify missing information, dependencies, and outcomes. A card called “confirmation” should prompt “What is confirmed, where can it be found later, and what happens if delivery fails?”

When someone proposes a volunteer profile, locate the benefit in the story. It saves repeat typing for returning volunteers; it does not make the first reservation possible. Place it below the release line unless the release depends on verified membership or another requirement that changes that reasoning.

After the workshop, link selected tasks to delivery tickets and keep the map as the overview. A story map is not a substitute for acceptance criteria or an owner. Update the release boundary when the plan changes so the attractive picture on the wall does not disagree with what the team is building.

Copy a map brief and verify the completed slice

Use the brief below before adding cards. It keeps the map anchored to one actor and a successful outcome. If organizers also need to create sessions, make a separate organizer map and connect the dependency: an available session must exist before a volunteer can reserve it.

At review time, demonstrate the selected journey using the acceptance checks, including full capacity and cancellation. Mark a task complete because its outcome works, not because its screen has been drawn. The map has done its job when everyone can explain what the first release enables and what remains outside it.

References

• Jeff Patton: The New User Story Backlog Is a Map