Prioritizing Stories and Slicing Release Increments in Story Mapping Agile
This skill teaches you how to draw horizontal swim lanes across a story map to carve the backlog into an MVP and sequenced release increments, so every release delivers a coherent, end-to-end slice of user value rather than a grab bag of features.
Draw horizontal lines across your completed story map to group stories into release slices. Start by identifying the thinnest possible walking skeleton that delivers end-to-end user value as your first slice, then layer additional stories into subsequent releases based on user impact, risk, and dependencies. Each slice should be independently shippable and testable, forming a complete, if minimal, version of the user journey.
Outcome: You produce a story map with clearly drawn horizontal release lines where each slice represents a shippable increment, starting with the thinnest viable end-to-end experience and building outward. This artifact directly feeds sprint planning, roadmap conversations, and stakeholder alignment.
Prerequisites
- A completed story map with user activities forming the backbone and user tasks decomposed into stories arranged vertically by detail
- Familiarity with the concept of a walking skeleton or minimum viable product
- Understanding of basic story mapping structure (backbone, body, and vertical priority ordering)
- Stakeholder access or at least documented knowledge of business goals, user research insights, and technical constraints
Overview
Once your team has built the Story Mapping backbone and populated the body with decomposed stories, the map presents a common challenge: everything looks important. The map is rich with detail, but without explicit release boundaries it remains a wall of sticky notes rather than a plan. Prioritizing stories and slicing release increments is the skill that transforms that wall into a sequenced delivery strategy. You draw horizontal lines across the map, and each band between the lines becomes a release slice, a set of stories that, taken together, deliver a coherent version of the user experience.
The first slice is the most critical. It defines your MVP or walking skeleton, the thinnest possible end-to-end path through every major user activity. This is not the same as cherry-picking the easiest stories or the loudest stakeholder requests. A good first slice touches every column of the backbone, even if only with the most basic story in each column, so users can walk the entire journey from start to finish. Subsequent slices add richness, alternate paths, edge-case handling, and polish. The discipline is in resisting the urge to gold-plate any single column before the full journey is walkable.
The concrete artifact you produce is the annotated story map itself, with release lines drawn, each slice labeled (Release 1, Release 2, etc.), and optionally a summary card per slice listing its scope, target user outcome, and rough timeline. This artifact becomes the primary input for sprint planning, roadmap presentations, and scope negotiations. When a stakeholder asks "can we add X?" you can point to the map and show where X lives, what slice it belongs to, and what moves down if it moves up. The skill is essential for any team practicing story mapping agile because it converts a shared understanding of the user journey into a shared commitment about what to build first, second, and later.
How It Works
Release slicing works because it exploits the two-dimensional structure of a story map to make trade-offs visible and concrete. The horizontal axis represents the user journey in chronological order, and the vertical axis represents depth or sophistication. When you draw a horizontal line, you are literally saying: "Everything above this line is what we ship in this increment." Because the line crosses every column, you are forced to make a decision about every activity, not just the ones the team happens to be excited about. This prevents the common failure mode where one part of the product is deeply built out while another is completely absent.
The underlying mental model is the "walking skeleton" concept from Alistair Cockburn. A skeleton is a system that can walk, meaning it performs the full journey end-to-end, but it has no muscle or skin, meaning it does so in the simplest possible way. The first release slice is the skeleton. Each subsequent slice adds muscle to one or more parts of the body. The analogy is useful because it makes clear that a skeleton with one massively muscled arm and no legs is worse than a skeleton that can walk, even if the walking is clumsy. Teams that internalize this analogy naturally resist over-investing in any single feature area.
Priority within each column follows a general principle: stories closer to the top of the map are more essential, more common, or more valuable. But "more valuable" is not a single dimension. When deciding where to draw the line, you are weighing at least four factors: user value (does this story solve a real, frequent problem?), business value (does it drive a metric we care about?), risk (does building this early reduce uncertainty about feasibility or market fit?), and dependency (does other work depend on this being done first?). These factors often conflict. A story might have high user value but low business value, or high risk reduction but low direct user impact. The slicing conversation is where these tensions surface and get resolved.
One important nuance: slicing is not the same as prioritizing a flat backlog. In a flat backlog, you rank stories 1 through N and work top-down. In a story map, you are selecting a coherent horizontal band. This means a lower-priority story in one column might still appear in the first slice because the journey is incoherent without it. For example, a basic "confirmation email" story might be low-priority in isolation, but if the first slice includes "place an order," users need some confirmation that the order was received. The map makes this dependency visible in a way a flat backlog never does.
Finally, slicing is iterative. Your first cut is a hypothesis. You draw the lines, step back, and narrate the user journey that each slice represents. If the narrative breaks, if there is a step where the user hits a dead end or a confusing gap, you adjust the line. You might pull a story up from slice 2 into slice 1, which means something else in slice 1 might need to move down to keep the scope manageable. This negotiation is the core of the skill, and it is best done collaboratively with the full cross-functional team so that engineering constraints, design insights, and business priorities are all represented in real time.
Step-by-Step
Step 1: Review the completed story map and confirm readiness
Before you start slicing, verify that the map has a stable backbone of user activities across the top, that each activity is decomposed into user tasks, and that stories are arranged vertically under each task with the most essential stories near the top. Walk the backbone left to right and narrate the user journey out loud. If anyone on the team cannot follow the narrative, the map is not ready for slicing. Resolve gaps by adding missing activities or tasks first.
Also confirm that the team has a shared understanding of the target user persona and the primary outcome that user is trying to achieve. This context is essential for making value judgments during slicing.
Tip: If the map was built in a previous session and team members have changed, spend 10 minutes having someone walk the map end-to-end for newcomers. Slicing decisions made without shared context produce incoherent releases.
Step 2: Define the criteria for your first release slice
Before drawing any lines, align the team on what the first slice must accomplish. " This is not a feature list. It is a user outcome. " Post this outcome statement above the map where everyone can see it.
Then discuss constraints: is there a deadline? A budget cap? A maximum number of stories? These constraints set the tension that makes the slicing exercise productive rather than aspirational.
Tip: If stakeholders struggle to articulate a single outcome statement, ask them to finish this sentence: "If Release 1 could only do one thing end-to-end, what would it be?" The answer almost always reveals the walking skeleton.
Step 3: Identify the walking skeleton across the backbone
Move across the map column by column, from the first user activity to the last. In each column, identify the single story (or the smallest set of stories) that enables the user to complete that activity in the most basic, functional way. Mark these stories with a dot, a color, or physically move them to the top row. Do not skip any column.
" Sometimes the answer is yes, in which case you can leave that column empty in the first slice. But be cautious, because gaps in the journey often create confusion or dead ends that undermine the whole release.
Tip: A useful heuristic is the 'demo test': could you demo this slice to a real user and have them complete the journey without you narrating what is missing? If you would need to say 'and then imagine that this part exists,' the skeleton is incomplete.
Step 4: Draw the first horizontal release line
Using tape, a marker, or your digital tool's lane feature, draw a horizontal line beneath the walking skeleton stories. Everything above this line is Release 1. Label it clearly: "R1" or "MVP" or whatever naming convention your team uses. Now narrate the user journey using only the stories above the line.
Walk through each activity and task, describing what the user does and what they experience. " Those moments reveal missing stories that should be pulled above the line, or assumptions that need to be challenged. Adjust the line as needed, pulling stories up or pushing stories down to maintain a coherent, shippable slice.
Tip: Physically walking the line with a finger (or cursor) from left to right and narrating aloud is far more effective than silently reading the cards. The verbal narrative surfaces gaps that visual scanning misses.
Step 5: Validate the first slice against constraints
With the first line drawn, do a rough sizing check. Have the engineering members of the team estimate the total effort for everything above the line. You do not need precise story points. T-shirt sizes or a simple "small, medium, large" per story are sufficient.
Sum the effort and compare it to your timeline and team capacity. If the slice is too large, you must either extend the timeline, add people, or, most commonly, thin the slice further. Thinning means finding stories above the line that can be simplified or deferred. " This is vertical slicing within a single story, and it is often where the most scope is saved without losing journey coherence.
Tip: When the slice is too large, resist the urge to cut entire columns. Instead, look for stories that can be replaced with a simpler version. Replacing is almost always better than removing, because removing breaks journey coherence while replacing preserves it.
Step 6: Slice subsequent releases
Move down the map and draw a second horizontal line to define Release 2. This slice should add the next most valuable layer of sophistication: alternate paths, error handling, richer UI, secondary user flows. Again, narrate the cumulative user journey (Release 1 plus Release 2 stories combined) to verify coherence. Repeat for Release 3 and beyond.
Most teams find that three to four slices are sufficient, because anything beyond the third release is speculative and will change based on what you learn from shipping the earlier slices.
Tip: Each subsequent slice should have a clear 'why now' rationale. If you cannot articulate why Release 2 stories should come before Release 3 stories, you may be slicing arbitrarily. The rationale usually ties to user feedback, competitive pressure, or risk reduction.
Step 7: Mark dependencies and risks across slices
Review the sliced map for cross-column dependencies. A story in Release 2 of one column might depend on a story in Release 1 of another column. Mark these dependencies with arrows or connecting lines. Also flag technical risks, stories where the team is uncertain about feasibility.
Consider pulling high-risk stories into an earlier slice so you can learn whether they are viable before committing to features that depend on them. This is the "risk-first" slicing principle: when in doubt, build the uncertain thing first. Document any dependencies that cross slice boundaries, because these are the most common sources of sprint-level rework.
Tip: If you find a tangled web of cross-slice dependencies, it often means your user activities are not cleanly separated. Revisit the backbone structure before trying to resolve the dependencies at the story level.
Step 8: Create a summary card for each slice
For each release slice, write a brief summary that captures: the slice label, the user outcome it delivers, the approximate number of stories, a rough effort estimate, key risks or dependencies, and any open questions. This summary card sits alongside the map and serves as the primary communication artifact for stakeholders who will not study the full map. It is also the input to your roadmap. Photograph or screenshot the sliced map and attach it to the summary cards so there is a durable record of the slicing decisions and their rationale.
Store these in your project wiki or documentation system.
Tip: Write the user outcome for each slice as a before-and-after statement: 'Before this slice, users had to [workaround]. After this slice, users can [capability].' This framing keeps the focus on user value rather than feature lists.
Step 9: Validate slices with stakeholders and commit
Present the sliced map to stakeholders who were not in the room. Walk them through each slice using the summary cards and the narrated user journey. Invite challenges, but anchor the conversation on trade-offs rather than additions. If a stakeholder wants to move a story from Release 2 to Release 1, ask what they would move down to compensate.
" Once alignment is reached, the first slice becomes the committed scope for the next planning cycle, and subsequent slices become the tentative roadmap. Update sprint backlogs accordingly, pulling stories from the first slice into your backlog tool in priority order.
Tip: Stakeholders often try to negotiate by adding to Release 1 without removing anything. Keep a running count of stories in each slice visible during the conversation. When the count grows, the conversation naturally turns to what to trade off.
Examples
Example: B2B SaaS invoicing tool for freelancers (small team, 3 developers)
A three-person engineering team with one designer and one PM has a story map for a freelancing invoicing app. The backbone covers: Create Invoice, Send Invoice, Track Payment, Manage Clients, and Generate Reports. There are roughly 45 stories on the map. The team has 8 weeks to ship an MVP that can support a beta group of 20 freelancers.
' The team walks the backbone and selects one story per column: 'Create a single-item invoice' under Create Invoice, 'Email invoice as PDF' under Send Invoice, 'Mark invoice as paid manually' under Track Payment, 'Add a new client with name and email' under Manage Clients, and nothing under Generate Reports (the team agrees the journey is complete without reports for now). That gives five stories above the first line. Rough sizing puts this at three weeks of work. The team adds two more stories: 'Edit a draft invoice' and 'View list of sent invoices,' bringing the total to seven stories and roughly four weeks.
The first line is drawn. Release 2 adds recurring invoices, automatic payment reminders, and a basic revenue dashboard, targeting the following four weeks. The map now has two clear slices, each with a summary card. Sprint planning pulls the seven Release 1 stories into the first two sprints.
Example: E-commerce checkout redesign (large team, cross-functional)
A 12-person product team at a mid-size e-commerce company has mapped the checkout journey from Cart Review through Payment, Shipping Selection, Order Confirmation, and Post-Purchase (returns, tracking). The map has 80+ stories. Stakeholders want the redesigned checkout live for Black Friday, which is 14 weeks away. The team must preserve the existing checkout in parallel during the transition.
The team defines three releases. Release 1 (weeks 1-6) is the walking skeleton: simplified cart review, credit card payment only, flat-rate shipping, basic confirmation page, and a link to the existing returns flow. This is 18 stories. Release 2 (weeks 7-10) adds PayPal and Apple Pay, real-time shipping rate calculation, order tracking emails, and guest checkout.
This is 22 stories. Release 3 (weeks 11-14) adds gift cards, saved payment methods, multi-address shipping, and a redesigned returns portal. During the slicing session, the engineering lead flags that real-time shipping rate calculation depends on an API integration that has a 3-week lead time. The team moves the API setup story into Release 1's first sprint as a technical enabler, even though the user-facing shipping feature stays in Release 2.
A summary card for each slice is created and shared with the VP of Commerce, who agrees to the sequence after negotiating gift card support from Release 3 into Release 2 in exchange for deferring saved payment methods.
Example: Mobile fitness app for casual users (B2C, early-stage startup)
A two-person founding team is building a fitness app. Their story map covers: Set Goals, Browse Workouts, Complete a Workout, Track Progress, and Social Sharing. They have 30 stories and four months of runway. They need to ship an App Store-ready version in six weeks to start acquiring beta users, then iterate based on feedback.
The founders write the outcome statement: 'After Release 1, a user can pick a beginner workout, follow along with a timer, and see their workout logged in a simple history.' They walk the backbone: 'Set a fitness goal' gets one story (choose from three preset goals), 'Browse Workouts' gets two stories (view a curated list of five workouts and filter by duration), 'Complete a Workout' gets three stories (step-by-step exercise display with timer, rest timer between sets, and workout completion screen), 'Track Progress' gets one story (list of completed workouts with dates), and 'Social Sharing' gets zero stories in the first slice because the journey is functional without it. The total is seven stories, estimated at four weeks. Release 2 adds custom goals, a workout builder, streak tracking, and share-to-Instagram. Release 3 adds social feeds, friend challenges, and Apple Health integration. The founders photograph the sliced map and use it as their investor update roadmap, with each slice tied to a user growth hypothesis: 'R1 tests retention, R2 tests engagement depth, R3 tests viral growth.'
Example: Internal HR onboarding portal (enterprise, regulated industry)
A corporate IT team is building an onboarding portal for new hires at a 5,000-person financial services company. The story map covers: Pre-Start Setup, Day-One Orientation, Compliance Training, Benefits Enrollment, Team Introduction, and 90-Day Check-In. There are 60 stories. The VP of HR wants the portal live for a cohort of 40 new hires starting in 10 weeks. Compliance training must be trackable for regulatory audits.
The team recognizes that compliance training is non-negotiable for the first slice due to regulatory requirements, even though it is not the most exciting user experience improvement. Release 1 (weeks 1-6) includes: 'New hire receives login credentials via email' (Pre-Start), 'View Day 1 agenda and office map' (Orientation), 'Complete three mandatory compliance modules with completion certificates' (Compliance), 'Select health insurance plan' (Benefits), and 'View team org chart with photos and roles' (Team Introduction). The 90-Day Check-In column is left empty because the first cohort will not reach day 90 before Release 2. The compliance module requires integration with the existing LMS, flagged as a four-week effort.
The team front-loads this work in Sprint 1. Release 2 adds interactive orientation videos, elective training modules, 401k enrollment, mentor matching, and the 90-day check-in survey. The sliced map is presented to the VP of HR and the compliance officer together, with the compliance officer confirming that the Release 1 training tracking meets audit requirements.
Best Practices
Always slice horizontally across the entire map rather than vertically within a single activity. A horizontal slice ensures every release delivers a walkable user journey. Slicing vertically (deeply building one feature before touching others) produces releases where one part of the product is polished and the rest is missing, which makes user testing and feedback cycles nearly useless because users cannot complete the journey.
Write a one-sentence user outcome for each slice before you start assigning stories to it. This outcome acts as a filter: every story in the slice must contribute to that outcome, and any story that does not contribute belongs in a different slice. Without this filter, slices tend to accumulate stories based on technical convenience or team enthusiasm rather than user value.
Include at least one engineering representative, one designer, and one product or business stakeholder in every slicing session. Engineering catches dependency and feasibility issues that product managers miss. Design catches journey gaps where users would be confused. Business stakeholders catch misalignment with strategic goals. If any perspective is absent, the slice will need rework.
Keep your first slice aggressively thin. Teams consistently underestimate the effort required and overestimate what users need for a usable experience. A good heuristic: if your first slice does not feel uncomfortably minimal, it is probably too large. You can always merge Release 1 and Release 2 if Release 1 ships early, but splitting an over-scoped Release 1 mid-sprint causes planning chaos.
Re-slice after every major release. The map is a living artifact. What you learn from shipping Release 1 will change your priorities for Release 2. Stories that seemed essential before launch may turn out to be rarely used, while stories you deferred may turn out to be the most requested. Schedule a brief re-slicing session (30 minutes) after each release retrospective.
Use physical or visual markers (tape, colored lines, swim lane features) that are easy to move. The first version of your slicing is a hypothesis, and you will adjust it multiple times during the session. If moving the line requires re-drawing or re-configuring, teams will resist adjustments and lock in premature decisions.
Limit slicing to three or four releases maximum. Anything beyond the third slice is speculative. Detailed planning for Release 4 creates a false sense of certainty and wastes time that would be better spent shipping and learning. Label distant slices as "future" without committing to a sequence.
Common Mistakes
Treating slicing as flat backlog prioritization instead of horizontal journey slicing
Correction
This happens when teams rank stories by individual value and draw the line after a certain number, ignoring which columns the stories fall in. The result is a first release that deeply builds two or three activities but completely ignores others, leaving users stranded mid-journey. The signal is a first slice that looks uneven, with many stories in some columns and zero in others. Fix this by always checking that every backbone activity has at least one story above the first release line.
If a column is empty, either add a minimal story or explicitly decide that the activity is out of scope for the MVP with a documented rationale.
Making the first slice too large because the team cannot say no to stakeholders
Correction
This manifests as a first release line drawn so far down the map that it includes 60-80% of all stories. The team agrees to everything to avoid conflict, then misses the deadline. The root cause is usually a slicing session without explicit constraints (timeline, effort budget, or story count cap). Catch this early by counting the stories in each slice and comparing to team velocity.
If the first slice contains more than 2-3 sprints of work, it is too large.
Slicing without narrating the user journey for each slice
Correction
Teams draw lines and move on without walking through the slice as a user would experience it. This leads to slices with logical gaps, such as a checkout flow without a confirmation step, or an onboarding flow that skips account verification. The symptom shows up later in sprint planning when developers discover that a slice is incoherent and needs emergency story additions. Prevent this by making the narration step mandatory: after drawing each line, one person walks the journey aloud while others listen for gaps.
Budget five minutes per slice for this narration.
Ignoring technical dependencies when drawing slice boundaries
Correction
Product-focused teams sometimes group stories by user value without consulting engineering about technical dependencies. A Release 2 story might require infrastructure that is not in Release 1, forcing either a mid-sprint infrastructure sprint or a delayed release. The warning sign is an engineering lead who looks uncomfortable but stays quiet during slicing. Explicitly ask engineers: 'For each story in slice 1, is there anything in slice 2 or 3 that must be built first?' Mark dependencies visibly on the map, and pull prerequisite stories into earlier slices even if their direct user value is lower.
Never re-slicing after the initial session
Correction
Some teams treat the initial slicing as a permanent plan. After shipping Release 1, they mechanically build Release 2 exactly as sliced months earlier, ignoring user feedback and changed priorities. The story map becomes a historical artifact rather than a living plan. The fix is simple: schedule a 30-minute re-slicing session after each release, using real user data and feedback to adjust the next slice.
Stories that users never mention can move down, and stories that users are loudly requesting can move up. The map should visibly change after each release.
Creating too many slices, turning the map into a detailed multi-quarter roadmap
Correction
Teams sometimes draw five, six, or seven release lines, creating a false sense of certainty about distant future work. This over-planning wastes time and creates stakeholder expectations that will not be met. The further out a slice is, the less accurate its contents. Limit slicing to three or four releases.
Everything beyond the third release belongs in a loosely defined 'future' bucket.
Other Skills in This Method
Refining and Evolving Story Maps Across Sprints
How to keep a story map as a living artifact by updating it during backlog refinement, sprint planning, and as new discoveries emerge.
Identifying User Activities and Building the Story Backbone
How to define the top-level user activities and arrange them chronologically to form the horizontal backbone of a story map.
Mapping User Personas to Journey Narratives
How to anchor the story map around specific user personas and their end-to-end journey narratives to ensure the map reflects real user goals.
Facilitating Collaborative Story Mapping Workshops
How to plan and run an effective story mapping session with cross-functional stakeholders, including timeboxing, materials, and facilitation techniques.
Creating and Using Story Mapping Templates
How to set up reusable story map templates in physical or digital formats using tools like Miro, Mural, or spreadsheets.
Decomposing Activities into User Tasks and Stories
How to break down high-level user activities into specific tasks and user stories that populate the vertical body of the map.
Frequently Asked Questions
How many stories should be in the first release slice?
There is no universal number, but a practical guideline is to aim for 2-3 sprints of work for the first slice. For a team of four developers doing two-week sprints, that is roughly 10-20 stories depending on size. The more important test is coherence: does the slice deliver a complete, walkable user journey? If you can demo the slice to a user and they can accomplish the primary task without you explaining what is missing, the size is right. Err on the side of fewer stories.
Should I prioritize and slice releases before or after decomposing activities into user tasks?
Always decompose first. Slicing requires the full map to be populated so you can see all the stories in each column and make informed trade-offs. If you try to slice at the activity or task level without decomposed stories, your slices will be too coarse. You will commit to entire activities without understanding the effort involved in the stories underneath. Complete the [decomposition step](/skills/decomposing-activities-into-user-tasks) before starting a slicing session.
How do I handle stories that multiple slices depend on?
Shared dependencies, such as authentication, API infrastructure, or design system setup, should be pulled into the earliest slice that needs them, even if their direct user value is low. Mark them explicitly as 'enabler' stories on the map using a distinct color or tag. During slicing, ask the engineering lead to call out any story that is a prerequisite for stories in later slices. Place these enablers in the first slice and account for them in your effort estimate. Do not hide them or assume they will 'just get done' as part of another story.
What if stakeholders disagree about which stories belong in the first slice?
Anchor the disagreement in the user journey narrative. Ask each stakeholder to walk through the first slice from the user's perspective and identify where the experience breaks without their preferred story. If the journey genuinely breaks, the story should be in the first slice. If the journey is functional but less polished, the story belongs in a later slice. When two stories compete for the same slice and both are valid, use effort as the tiebreaker: the story that is smaller and faster to ship wins because it reduces risk and accelerates learning.
How often should I re-slice the story map?
Re-slice after every major release, or at minimum quarterly. The purpose of re-slicing is to incorporate what you learned from shipping the previous slice. User feedback, usage data, and changed business conditions all invalidate earlier slicing decisions. A 30-minute re-slicing session after each release retrospective is usually sufficient. Bring the updated map, review which stories in the next slice are still relevant, and adjust the line. See [refining and evolving story maps across sprints](/skills/refining-story-maps-across-sprints) for the full iterative process.
Can I use story mapping agile slicing for non-software products?
Yes. The technique works for any initiative that has a sequential user journey and can be delivered in increments. Service design teams use it to phase the rollout of new customer service processes. Marketing teams use it to sequence campaign launches. The key requirement is that you can define a 'walking skeleton,' a minimal end-to-end version of the experience that is testable and deliverable. If your initiative does not have a sequential user journey, a different prioritization framework may be more appropriate.
Why does my first release slice keep growing during sprint planning?
Scope growth after slicing usually happens because the slicing session did not surface all dependencies, or because stories were not decomposed finely enough. When developers start working on a story and discover it requires additional stories that were not on the map, the slice grows. Prevent this by doing a dependency check during the slicing session (Step 7) and by ensuring stories are small enough that hidden work is unlikely. If growth persists, your stories are too large. Break them down further before the next slicing session.