What is the Must Should Could Won't Prioritization Method?
Our actions should express our priorities, and Must Should Could Won’t is a great sprint retrospective template to help teams identify those priorities to ensure they continue to deliver value where it is most needed. With that in mind, it’s an approach that aligns well with agile processes and frameworks given its focus on the delivery of valuable things first. It is also a great Scrum sprint retrospective idea as it offers the product owner a mechanism to step into the shoes of their customer and view the product from their perspective. Developed in the 1990s by Dai Clegg, the MSCW method gained prominence in agile project management and business analysis. It provides a structured way to organize tasks into four distinct categories: Must have (critical), Should have (important), Could have (desired), and Won't have (not priority). The strength of MSCW lies in its simplicity and effectiveness in facilitating group discussions about priorities. By categorizing items into these four buckets, teams can better align their efforts with strategic goals, manage resources efficiently, and maintain clear communication about what will and won't be delivered.
Must Should Could Won't Format
Must
Things we must definitely do.
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
Things we should do.
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
Things we could do.
These are desirable features that would be nice to have if resources permit. Help the team identify enhancements that would improve the solution but aren't essential. These items often make good candidates for future iterations or releases.
Won't
Things we won't do.
These are items explicitly decided against for this iteration or project. Encourage honest discussion about features that, while potentially valuable, don't align with current goals or constraints. This helps maintain focus and manage expectations.
When to use this retrospective
- When planning a new project or initiative and need to establish clear priorities
- During backlog refinement sessions to organize and prioritize feature requests
- When facing resource constraints and need to make tough decisions about scope
- In stakeholder meetings to align expectations about deliverables and timelines
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?
Ideas and tips for your retrospective meeting
- Limit 'Must' items to no more than 60% of total requirements to maintain realistic scope
- Review and revise categorizations periodically as business needs and constraints change
- Use timeboxing during discussions to ensure efficient decision-making
- Document the reasoning behind categorizations to maintain clarity and consistency
- Involve all key stakeholders in the prioritization process to ensure buy-in
- Consider dependencies between items when assigning categories
New to retrospectives? Read our guide on how to run a retrospective →
Related templates
A structured reflection using Liked, Learned, Lacked, and Longed for categories to analyze sprint performance
What? So What? Now What? Retrospective
A structured reflection framework for systematic problem analysis and action planning
Agile Retrospective
A structured way to reflect on the past sprint and identify improvements.
Start Stop Retrospective
Retrospective Idea - A focused retrospective for clear, actionable team improvements