MoSCoW Prioritisation Template

What Is MoSCoW Prioritisation?

MoSCoW is a prioritisation technique used in project management and software development to help teams decide what to build now, what to build later, and what to leave out entirely. The name is an acronym: Must Have, Should Have, Could Have, and Won't Have. The lowercase "o" letters are added purely to make the word pronounceable - they carry no meaning of their own.

The framework was originally developed by Dai Clegg in 1994 for use with the Dynamic Systems Development Method (DSDM), but it has since become one of the most widely adopted prioritisation approaches in agile software teams. Its strength is simplicity: rather than scoring items on multiple weighted dimensions, you place each requirement into one of four clear categories. This forces teams to make explicit trade-offs about scope - something that is easy to avoid when everything sits in a single ordered backlog. For a deeper look at the underlying framework, see the MoSCoW prioritisation framework guide.

The Template

Use the four categories below to sort your backlog items, user stories, or feature requests. Copy this structure into your project management tool, whiteboard, or planning document and populate each section with your team.

The Four Categories Explained

Must Have

Must Haves are the non-negotiable requirements without which the delivery has no value. A useful test is the "or else" rule: if the consequence of not including this item is that the product is unusable, the release violates a regulation, or a contractual deadline is missed, it is a Must Have. Teams should aim for Must Haves to represent no more than 60% of the total planned effort. If the proportion creeps higher, either the scope is too ambitious for the timebox, or the team is not being rigorous enough about what truly qualifies.

Should Have

Should Haves are important but not essential. They are features that real users will miss if they are absent, but the product still functions without them. The key distinction from Must Have is that a workaround exists, even if it is painful. Should Haves typically represent around 20% of total effort and are the primary candidates for deferral when timelines slip. They should be the first items reconsidered for the next release.

Could Have

Could Haves are desirable enhancements that have a smaller impact than Should Haves. They improve the user experience, polish the product, or address edge cases, but their absence does not meaningfully reduce the value of the release. Allocate roughly 20% of effort here. Could Haves are useful as a buffer - if the team finishes ahead of schedule, these items are ready to pick up. If time runs short, they are dropped without ceremony.

Won't Have (This Time)

Won't Haves are explicitly out of scope for the current delivery cycle. This is not a rejection - it is a deferral. Recording items here is just as important as categorising the items you plan to build, because it sets expectations with stakeholders and prevents scope creep mid-sprint. Won't Haves also serve as a backlog seed for future planning. Revisit them at the start of each new cycle to decide whether they have moved up in priority.

How to Use This Template

Follow these steps to run a MoSCoW prioritisation session with your team. The process works best in a time-boxed workshop of 60 to 90 minutes with all relevant stakeholders present.

1. Gather your backlog. Collect all candidate items - user stories, features, bugs, tech debt - into a single list. Each item should be clearly described and ideally have a rough size estimate. Remove duplicates and merge overlapping items before the session.
2. Define the timebox. MoSCoW only works when there is a fixed constraint - a sprint, a release date, or a capacity limit. State the constraint explicitly at the start of the session so everyone shares the same planning horizon.
3. Categorise individually first. Give each participant five minutes to silently assign every item to a category. This prevents anchoring bias and ensures quieter voices have equal input.
4. Discuss and converge. Walk through the list as a group. Focus discussion on items where people disagree - these are the items that need the most deliberation. Use the "or else" test for Must Haves and the "workaround exists" test to distinguish Should Haves from Must Haves.
5. Validate the distribution. Check the effort split across categories. If Must Haves exceed 60% of total capacity, either reduce scope or extend the timebox. An unbalanced distribution signals that the team has not been rigorous enough in its categorisation.
6. Document and communicate. Record the final categorisation in a shared location - your project management tool, a wiki page, or a shared document. Send a summary to all stakeholders so that expectations are aligned and the Won't Have list is visible to everyone.

MoSCoW Examples for Engineering Teams

Here is a concrete example. Imagine an engineering team preparing to launch a new notifications service. The team has a two-week sprint to deliver the first version.

Notice how the Won't Have list is not a rejection - it is a record of deliberate decisions. The team may revisit SMS notifications in the next sprint once vendor contracts are finalised. Making these decisions visible prevents stakeholders from assuming items were simply forgotten.

Common MoSCoW Mistakes

• Making everything a Must Have. If 80% of your backlog is labelled Must Have, the categorisation has failed. Apply the "or else" test rigorously: if nothing truly bad happens without this item, it is not a Must Have.
• Skipping the Won't Have category. An empty Won't Have column means the team has not made real trade-offs. Every prioritisation session should produce items that are explicitly out of scope - if it does not, the exercise is performative.
• Not involving stakeholders. MoSCoW works best as a cross-functional exercise. If only engineers categorise items, the business perspective is missing. If only product managers categorise, technical constraints are ignored. Include both sides.
• Treating Won't Have as "Never." Won't Have means "not this time," not "never." Stakeholders sometimes resist putting items in this category because they fear the item will be permanently abandoned. Clarify that Won't Haves are revisited every planning cycle.
• Forgetting to validate the effort distribution. Categorisation without sizing is incomplete. You need to check whether your Must Haves actually fit within the timebox. A perfectly categorised list that requires 200% of available capacity is not a plan - it is a wish list.