What is the Must Should Could Won't prioritization method?
Must Should Could Won't, better known as MoSCoW, sorts work into four groups: what you must do, what you should do, what you could do if there's time, and what you won't do this time. Run as a retrospective, it gets your team to agree on priorities for the next sprint or release out loud, with everyone in the room. Dai Clegg developed the method at Oracle in the 1990s, and it became a standard part of agile project management and business analysis, especially in DSDM. The categories are Must have (critical), Should have (important), Could have (desirable) and Won't have (not this time). It fits agile ways of working because it puts the highest-value work first. It also gives the product owner a structured way to see the backlog from the customer's side: if a customer would notice it missing at launch, it's probably a Must. The Won't column does more work than it looks. Writing down what you've agreed not to do keeps it from creeping back into the sprint, and it tells stakeholders plainly what won't be delivered.
Must Should Could Won't Format
Must
What must we deliver, no matter what?
These are non-negotiable requirements that are critical for success. When discussing 'Must' items, encourage participants to consider true blockers or essential elements without which the project would fail. Challenge the team to be strict about what qualifies as a 'Must' to avoid priority inflation.
Should
What's important but not critical?
These are important features or requirements that add significant value but aren't critical for launch. Guide the team to consider items that would be painful to leave out but wouldn't stop the project from functioning. Focus on high-value, lower-urgency items.
Could
What would be nice if time allows?
These are desirable features that would be nice to have if resources permit. Help the team find improvements that would make the solution better but aren't essential. These items often make good candidates for future iterations or releases.
Won't
What are we agreeing not to do this time?
These are items the team explicitly decides against for this iteration or project. Encourage honest discussion about features that might be worth doing but don't fit current goals or constraints. Naming them keeps the team focused and sets clear expectations.
When to use this retrospective
- When planning a new project or initiative and you need clear priorities
- During backlog refinement, to sort and prioritize feature requests
- When resources are tight and you have to make hard calls about scope
- In stakeholder meetings, to set expectations about what will be delivered and when
Suggested icebreaker questions
- What's the most difficult priority decision you've had to make in a project?
- If you could only deliver three features in your current project, what would they be and why?
Want a warm-up your team plays, not just answers out loud? Browse free icebreakers →
Ideas and tips for your retrospective meeting
- Keep Must items to no more than about 60% of the total effort, the DSDM guideline, so the plan has room for surprises
- Revisit the categories as business needs and constraints change
- Timebox the discussion of each item so one debate doesn't eat the meeting
- Write down why each item landed where it did, so the next debate doesn't start from scratch
- Involve the stakeholders who own the requirements, so the priorities stick
- Check dependencies before you place an item: a Could that a Must depends on is really a Must
Frequently asked questions
What is the MoSCoW method?
What do Must, Should, Could, and Won't mean?
How do you run a MoSCoW retrospective?
Why is it called MoSCoW?
How many items should be Musts?
Related templates
Reflect on what your team Liked, Learned, Lacked and Longed for
What? So What? Now What? Retrospective
Go from what happened to what you'll do next.
Agile Retrospective
Four questions to review your last sprint and plan changes.
Start Stop Retrospective
Two questions: what to start, and what to stop