A ranked backlog can hide an unusable release

Harbor, a hypothetical equipment-rental service, has a backlog of search, filtering, payment, confirmation, and return features. Search has the most votes, so the team proposes building all its refinements first. A customer could find a tool in impressive detail and still have no way to reserve it.

User story mapping organizes work around the sequence of a user’s activities, with detail beneath them. Jeff Patton explains why a map preserves context that a flat backlog loses. Harbor’s journey, release choices, and proposed checks are fictional.

Tell one user’s story before writing tickets

Harbor starts with an occasional renter who needs a drill for a weekend project. The journey is to find a suitable tool, check availability, reserve it, collect it, and return it.

These activities are the backbone of the map. Under them, the team records smaller tasks such as selecting dates, understanding the deposit, receiving pickup instructions, and confirming the return. A story map is a conversation aid; writing more cards does not automatically produce shared understanding.

Keep the chosen user and situation visible. A contractor renting repeatedly may follow a different journey from a first-time household customer. Combining every audience immediately can produce a map too broad to guide a release.

Horizontal: journey order · Vertical: details and release choices

Across the map

Backbone

Arrange user activities in the order of the journey.

Below each activity

Details

Break activities into tasks, alternatives, and exceptions.

Across activities

Release slices

Select enough work to support a coherent end-to-end outcome.

After a slice

Learning

Review real use and revise later slices.

Story maps retain the journey while exploring detail below it. A release slice crosses the journey; it is not simply the first column of tasks.

Add the details that change delivery

Under “reserve,” Harbor initially writes only “pay.” Discussion reveals that the team must also prevent double booking, explain cancellation conditions, and confirm what has been reserved. Those details change what a workable reservation means.

Alternatives and exceptions matter when omitting them would break the journey. What happens if the drill becomes unavailable after checkout? How does a renter get help? A first release can have a narrow audience and a manual exception process, but that process needs a real owner and capacity.

Do not confuse journey order with development order. Engineers may build availability services before the interface. The map explains the user experience; it does not replace technical dependency planning.

Slice across the journey

Harbor proposes a first slice for one location, a limited set of tools, and payment at collection. That could reduce delivery scope while still supporting a complete reservation and return journey. Staff would manage pickup and returns through an agreed manual process.

Activity Candidate first slice Later possibility
Find Browse a small tool list Advanced comparisons
Check See availability for chosen dates Flexible-date suggestions
Reserve Hold a tool and receive confirmation Online payment
Collect Show reservation details to staff Self-service collection
Return Staff records return and gives a receipt Automated reminders

This is an invented release plan, not a universal minimum for rental software. Local obligations, payment requirements, reliability, and operating constraints could change the necessary scope.

The slice is coherent because the renter can complete the task and staff can support it. It is not coherent merely because its cards fit under a line on the board.

Explain the learning goal

Harbor wants to learn whether customers can reserve the right item and arrive with the right expectations. The first slice therefore needs clear dates, conditions, and pickup instructions. An advanced filter is less central to that learning question.

Before delivery, walk through the map with someone representing the intended audience and with the staff who will handle the manual work. Mark assumptions and confusion. A walkthrough can expose missing steps, but actual use is still needed to assess whether the service works reliably.

After launch, inspect incomplete reservations, support contacts, mistaken pickups, and return problems. Keep the journey on the wall while revising later slices. Otherwise, new requests can flatten the map back into an unrelated list.

Run your own mapping conversation

Choose one user situation and outcome. Tell the journey in ordinary language, arrange activities across the top, add task detail, and discuss exceptions. Draw a first slice that supports an outcome and identify what staff, technology, and policy must make possible.

Use Jobs to Be Done to investigate the progress behind the journey before assuming the requested workflow is right. Use MoSCoW to make scope commitments explicit within the chosen release window.

A story map does not establish market demand, estimate work, or guarantee a usable design. Its value is shared context: Harbor can now explain why a limited but complete reservation journey deserves attention before an elaborate search experience.

Sources and further reading