How to prioritize user stories by slicing first
New to story mapping? Start with our complete User Story Mapping Guide.
In 1994, Dai Clegg was working at Oracle and needed a quick way for a project team to agree on what mattered. He came up with four buckets, Must have, Should have, Could have, and Won’t have, and then added two lowercase o’s so you could say it out loud.
MoSCoW went on to become one of the most widely used prioritization methods in software. A third of its letters are there for pronunciation.
MoSCoW does its job fine. The job is sorting. Hand a team a backlog and MoSCoW, or RICE, or an impact-versus-effort grid, and you get back the same backlog in a better order.
What you don’t get is a first release that leaves anyone able to do anything. An ordered list and a working path through the product are different objects, and most prioritization quietly assumes the first one produces the second.
We made this mistake ourselves. From 2022 to 2025, every new story map in CardBoard opened on a finished 36-card example, and we’d prioritized it for completeness. The first slice a new user actually needed was a blank board and their own words. The full story, with the numbers, is in the feature bloat post.
Every framework ranks, and none of them slices
Each of the popular ways to prioritize user stories is a way to rank them.
| Framework | How it ranks | Where it helps | Where it slips |
|---|---|---|---|
| MoSCoW | Must, Should, Could, Won’t | Forces the “won’t” conversation | Everything drifts into Must |
| RICE | Reach × Impact × Confidence ÷ Effort | Compares unlike items with numbers | The numbers are guesses wearing a formula |
| Impact vs. effort (2×2) | Quadrants, quick wins to money pits | A fast first pass in a room | Effort is an estimate, with all that implies |
| Kano (Noriaki Kano, 1984) | Basic expectations vs. delighters | Spotting features people only notice when they’re missing | Needs real customer research to do properly |
| WSJF | Cost of delay ÷ job size | Work where delay costs real money | Cost of delay is hard to put a number on |
| Voting | What the room likes | Surfacing opinions | Popular and necessary aren’t the same thing |
All of them answer “which item next?” None of them asks who it’s next for, or what that person is trying to get done. That’s the missing question.
Rank progress, not features
Teams guess at priority, or rush to market while the core path still fails. Overbuilding is the same error from the other side, adding depth for people who already succeeded. (More on that in Feature bloat is the biggest mistake in building apps.)
A better target is what Kathy Sierra, on her Creating Passionate Users blog and later in her book Badass: Making Users Awesome, called the suck threshold. It’s the point where someone has invested enough to care and is still bad enough at the thing to quit. Your first release should get people over it, and anything that doesn’t help with that can wait.
How to prioritize user stories, in order
- Name the user and the job. One person, one goal. If you can’t, you’re prioritizing a portfolio, so split it and prioritize each part on its own.
- Find where they already invested and still fail. Look at support tickets, drop-offs, workarounds, and the question every new customer asks. On a map these become visible columns.
- Put the first slice through those columns. You want the shortest complete path to a first real success, and a working version of every step beats the best version of one.
- Then rank what’s left, inside the later slices, by value, effort, risk, or what you’d learn. This is where MoSCoW and RICE earn their keep.
Step 3 is the judgment call. It will feel wrong to ship a thin version of a step you know people care about. It should feel worse to ship a gorgeous step three that nobody reaches, because step two still needs a support call.
Business goals and budget still matter. They decide which problems you take on at all. They shouldn’t reorder a slice so that the step where people are stuck gets postponed for depth only your happiest users will notice.
Structure first, then rank inside the slices
The old advice to “prioritize last” is half right. Build the structure first, then prioritize inside it. A user story map gives you three directions to work in. The backbone runs left to right in the order the job happens. Under each step, stories stack from most essential at the top to nice-to-have at the bottom. And a horizontal slice across every step is what ships together, so the whole path still works.
In CardBoard, a story map’s release slices are dividers across the map. Drag a card above or below the line and you’ve changed what ships first. When one slice needs a sharper call, the Prioritization Matrix map type gives you the impact-versus-effort 2×2 on its own board. Reactions on cards show how the group feels without turning it into a vote.
Voting and estimation matrices are good at settling arguments inside a slice. They’re a poor substitute for asking whether a band of work moves someone past can’t.
The test
Look at your top ten stories. If they delay the step where people feel stupid, in favor of something only successful users would ever reach, the order is protecting the roadmap from the people it’s for.
Once the slice is set, someone will ask how long it’ll take. For that, see Hate estimating? Forecast from a user story map instead.
Ready to try CardBoard for yourself? Create a free account, three boards, no credit card.
Didn’t find what you need? Visit our Help Center to find answers or get in contact with our team.