Prioritizing and Slicing Releases on a Story Map

Prioritize a story map by necessity and slice it into releases that each let target users reach their goal from start to finish.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Slicing is where a story map pays for itself. Once the map holds the whole journey, a line across it shows exactly what a release lets users do, and what it leaves out. Jeff Patton's first article on the idea opens with a team that built the highest-value features first and found customers were not using the release, because "there's not enough here for me to get my job done" (How You Slice It). Slicing across the whole journey is his answer to that problem. For the method's background, see the User Story Mapping page.

Prioritizing on a map is different from ranking a list. Patton does not prioritize the backbone at all. He prioritizes the cards hanging below it by moving them up when they are "absolutely necessary" and lower when they are less so (The New User Story Backlog is a Map). When every column is arranged this way, the top cards across the map form the smallest system that works end to end, which he identifies with Alistair Cockburn's walking skeleton.

Release lines then mark the slices. Patton describes running a long strip of masking tape across the map to create "horizontal swim lanes for each release," and moving stories up and down into each lane. His Story Mapping Quick Reference defines a viable release as the smallest number of tasks that lets your specific target users reach their goal, and asks you to write each slice's target outcomes on a card to its left.

This skill covers the whole sequence: arranging columns by necessity, drawing the first slice, checking it, slicing later releases, and splitting the first release into a delivery strategy.

How It Works

Height on the map means necessity. Patton's original model labelled the vertical axis from "always used" at the top to "seldom used" at the bottom, and asked the group to place each card by how critical it is to the business process. The same article gives the first slice a precise target: "the smallest set of features necessary to be minimally useful in a business context" (How You Slice It). In its retail example, the first span supported only receiving and selling items, leaving the merchandise buyer and the sales analyst for later because their work "doesn't always happen."

Prioritization happens inside columns. Patton's car example in The New User Story Backlog is a Map shows why: nobody should be asked whether the engine or the brakes matter more, but it is fair to ask whether the first car gets a four-cylinder or six-cylinder engine, or anti-lock brakes. Each column therefore offers a choice between a basic version of a task and richer versions below it.

When a necessary task will not fit, there are standard moves. Patton suggests asking, for each user, whether they can do their work with the slice, whether a paper process or software workaround covers an omitted feature, and, in his words, "Could the feature be split into a crude minimal version for earlier release and a more elaborate version for later release?" (Patton, It's All in How You Slice It). The Nielsen Norman Group adds that risky cards, such as ones not backed by user data or not technically feasible, can be swapped for leaner alternatives with the same value so the team learns before investing (NN/g).

Later slices are chosen by the business. After the first span, Patton's article has the business people responsible for the release pick features below the line that group together logically and fit the time available, producing lines that "wander up and down" across the map. One option is to take the highest-value features first. Another is to complete one business process column. Developer estimates written on the cards let the group add up what sits above each line.

The first release then gets its own development strategy. The quick reference splits it into an opening game that builds a "functional walking skeleton," a mid game that completes and enriches major functionality, and an end game that refines the product for release. It also asks for product success metrics per release, ideally specific changes in user behavior. Atlassian's guide shows a common set of slice labels teams use in practice: MVP, first release, future release, needs validation and not now (Atlassian).

Step-by-Step Guide

Step 1: Confirm the map is ready to slice

Walk the map left to right and check that every activity has decomposed tasks below it and that the columns are in narrative order. Make sure developers have seen the map and flagged risky or expensive cards. If whole activities are still empty, finish decomposition before slicing. Name the business owner who will make the scope calls.

Step 2: Arrange each column by necessity

Move the cards in each column so the most necessary version of each task is highest and richer or rarer versions sit lower. Do not rank the backbone. When a card is contested, ask each person why, using the disagreement to surface assumptions. Check the result by reading only the top card of each column: it should read as a thin version of the whole journey.

Step 3: State the goal of the first slice

Write down who the first release is for and what they must be able to achieve. Use the quick reference's framing of target outcomes, and add the measure that would show the release worked, such as a change in what users do. Keep the goal specific enough that a card can be judged in or out against it.

Step 4: Draw the first release line

Place tape or a line across the map under the smallest set of cards that lets the target users reach their goal. Include at least a basic version from every activity the journey needs. Where an activity has nothing above the line, decide explicitly whether the user can manage without it, for example through a manual workaround. Write the target outcomes on a card to the left of the slice.

Step 5: Test the slice against users, risk and effort

Walk the slice as each target user and ask whether they can do their work with only what is above the line. Ask developers to add rough estimates and total the slice. If it is too large, split cards into crude and elaborate versions or replace risky cards with leaner alternatives. Scan for dependencies on cards below the line and resolve them.

Step 6: Slice later releases

Let the business owner choose the next set of cards below the first line, with the group asking questions. Group cards that belong together and fit the time available, even if the line wanders. Give each slice its own outcome card and success measure. Leave the lowest cards unassigned if nobody can yet say when they will matter.

Step 7: Split the first release into delivery phases

Divide the first release into an opening game, a mid game and an end game, as the quick reference suggests. Put the walking skeleton in the opening game so it can be shown to users and tested for performance early. Move the riskiest cards early as well, so uncertainty is resolved while there is time to react. Share the phased plan with the team that will build it.

Best Practices

• Slice the whole journey, then deepen it. A thin release across every activity gives users something they can use, where a deep release in one activity does not.
• Keep outcomes on the map. An outcome card beside each slice turns scope debates into questions about what users will be able to do.
• Use workarounds deliberately. Patton's paper-process question often frees a slice from a feature it does not need yet.
• Split before you cut. When a necessary task is too big, a crude first version usually beats dropping it.
• Let the accountable person draw the line in front of the team. Patton's article gives the slicing decision to the business people responsible for the release, with others asking questions.
• Revisit the lines as you learn. A release line drawn before users see the skeleton is a hypothesis, so move it when evidence arrives.

Common Mistakes

• Slicing by activity: Putting whole activities in the first release and others in later ones gives users half a journey. Take a thin layer from every activity.
• Ranking the backbone: Arguing about which activity matters most wastes the session. Prioritize the choices within each column.
• Leaving a column empty by accident: An activity with nothing above the line may block the whole journey. Decide on each empty column explicitly.
• Slicing without estimates: A first slice that nobody has sized often turns out to be most of the map. Get rough developer estimates before committing.
• Treating the MVP as the whole product minus a few features: The first slice should be the smallest set that works end to end. If it is large, keep splitting.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: User Story Mapping

Related Skills

• Story Map Backbone: Identifying User Activities
• Story Map Personas: Mapping Personas to User Journeys
• Story Map Decomposition: Activities to User Tasks
• Story Mapping Facilitation: How to Run a Workshop
• User Story Mapping Template: Build One Your Team Reuses
• Refining a Story Map Across Sprints

Sources

• Jeff Patton: It's All in How You Slice It (Better Software, January 2005)
• Jeff Patton: The New User Story Backlog is a Map (October 8, 2008)
• Jeff Patton: Story Mapping Quick Reference (Story Map Concepts, copyright 2013 Comakers LLC)
• Nielsen Norman Group: Mapping User Stories in Agile (2021)
• Atlassian: What is user story mapping? An Agile planning guide

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.