Team members collaborating in a brick loft workspace

Workshop Guide

MoSCoW Prioritization

Give every backlog item a clear category so the team and stakeholders agree, before the sprint starts, what is non-negotiable and what can wait.

Categories
Must Have→
Should Have→
Could Have→
Won’t Have

01 / Summary

What Is MoSCoW Prioritization?

MoSCoW is a prioritization technique that sorts requirements, features, or backlog items into four categories: Must Have, Should Have, Could Have, and Won’t Have. The name is an acronym formed from the first letters of each category, with Os added to make it pronounceable. A team or leadership group that has worked through MoSCoW on a defined scope leaves with an explicit, shared understanding of what is non-negotiable, what adds value if time permits, and what is off the table for this iteration.

The technique is used in agile and project contexts when a group needs to move from a long, undifferentiated backlog to a prioritized delivery plan without spending weeks in committee. It works because it forces binary-style decisions, each item lands in exactly one bucket, while preserving nuance through four distinct priority levels rather than a single cut.

1
Forces Trade-Off Conversations
Stakeholders cannot all label everything critical. MoSCoW creates a shared forum where trade-offs get named and resolved out loud.
2
Protects the Non-Negotiables
A clear Must-Have list gives the team a firm commitment to defend against scope creep during delivery.
3
Speeds Up Decision-Making
Four categories and a clear rule set let a group move faster than a ranking exercise or a point-voting scheme.

02 / Application

When to Use MoSCoW Prioritization.

Use this workshop any time a group of stakeholders needs to convert a list of items, features, requirements, tasks, or backlog items, into a priority-ordered delivery plan within a fixed capacity or timebox.

Sprint and PI Planning Preparation

The backlog is long, capacity is limited, and the team and stakeholders need to agree on what gets done before committing to an increment.

MVP Definition

A product team is defining minimum viable scope for a first release and needs stakeholder alignment on what is truly non-negotiable versus what can ship later.

Scope Management Under Constraint

A project is at risk of running over time or budget, and the team needs stakeholder agreement on what can be deferred or dropped from the current commitment.

Requirement Prioritization

A business is reviewing a large set of requested features and needs to agree on what gets funded and built in the next cycle before the planning window closes.

Prerequisites

A Defined Scope List

A complete, reasonably sized list of items to be prioritized is available and clearly described; MoSCoW does not work on a vague or ungroomed backlog.

Stakeholders with Decision Authority

The people in the room can make real commitments; substitutes who need to escalate every decision for approval will stall the session.

Roles and Responsibilities

Facilitator
Runs the session, explains the categories, keeps debate productive, and prevents the Must-Have bucket from becoming a catch-all for everything the group is reluctant to defer.
Product Owner or Product Manager
Brings the backlog and carries final authority on priority decisions when the group cannot reach agreement on a specific item.
Business Stakeholders
Represent the business’s needs and constraints; their input determines what lands in Must Have versus Should Have.
Development Team or Delivery Lead
Provides capacity and feasibility context so the group doesn’t place more in Must Have than can actually be delivered in the available time.

Include the delivery team in the session. Stakeholders who prioritize without hearing feasibility constraints routinely overfill the Must-Have bucket.

Scheduling and Timing

  • Plan for two to three hours for a list of up to 30 items; larger backlogs benefit from a facilitator-led pre-sort before the group session.
  • Best run during PI Planning preparation, sprint planning, or at the start of a scoping cycle, before commitments are locked in.
  • Don’t run it as a solo Product Owner exercise; MoSCoW’s value is in the shared conversation, not in the output of a single decision-maker.
  • Send the scope list to participants at least two business days ahead so they arrive with initial opinions already formed, not a blank slate.

03 / Preparation

Preparing for the Workshop

The session works only if the group is working from the same list. A facilitator who shows up with a vague scope or a sprawling, ungroomed backlog will spend most of the session clarifying what each item means rather than prioritizing it.

  • Confirm the scope list is complete, clearly described, and small enough to process in the available time; 20 to 30 items is the practical upper limit for a two-to-three-hour session.
  • Identify the stakeholders with actual decision authority and confirm they are attending; substitutes who cannot commit will stall the session.
  • Reserve a room or virtual whiteboard with space for four visible columns: Must Have, Should Have, Could Have, and Won’t Have.
  • Download and prepare the Facilitator Presentation and the MoSCoW Prioritization Excel Template.
  • Send scheduling communication with agenda and pre-read materials

    Email Template

    Subject: [Program/Product Name] MoSCoW Prioritization Workshop – Agenda and Pre-Read

    Hi team,

    We’re holding a MoSCoW Prioritization Workshop on [date] to align as a group on what’s in scope for the upcoming [sprint / increment / release].

    Before the session, review the attached scope list and come with an initial sense of which items you think are non-negotiable and which ones you’d consider deferrable. We’ll work through the four categories together in the room.

    Location/Link: [link]
    Duration: [two to three hours]

    Calendar Invite Copy

    Subject: MoSCoW Prioritization Workshop

    Agenda: Category definitions, item-by-item prioritization, Must-Have size check against capacity, finalize and confirm.

    Room/Virtual: [link]

    Come ready to make real decisions, not just weigh in on someone else’s list.

04 / Facilitation

Facilitation Agenda

Facilitation keeps the group moving through the item list without letting any single item dominate the session. The most common failure mode is the Must-Have bucket growing unchecked because no one wants to admit something isn’t critical. The facilitator’s job is to challenge that pattern, not enable it.

Presenting the MoSCoW Prioritization Process

This agenda guides facilitators through a structured prioritization session. Time estimates reflect a two-hour format; adjust durations based on the size of the scope list and the group’s familiarity with MoSCoW. Keep the session decision-focused: the goal is a fully categorized list with shared commitment to each bucket, not an exhaustive debate on every item.

  1. Define the Four Categories
    • Walk the group through Must Have, Should Have, Could Have, and Won’t Have with a brief, concrete example; clarify that Won’t Have for this iteration is not “rejected forever.”
  2. Set the Capacity Constraint
    • State the team’s available capacity upfront so the group knows the hard ceiling Must-Have items must fit within before sorting begins.
  3. Sort Items as a Group
    • Work through the scope list item by item; each item gets one category; use brief discussion but time-box each item to keep the session on pace.
  4. Pressure-Test the Must-Have List
    • When sorting is done, tally the Must-Have bucket against available capacity; if it exceeds what the team can deliver, something must move to Should Have.
  5. Finalize Categories and Document
    • Confirm each item’s final category, capture any conditions or caveats agreed in the room, and read the full list back for confirmation.
  6. Confirm Commitment
    • Each stakeholder confirms they can support the priority decisions as documented before the session closes.

Common Anti-Patterns to Avoid

  • Everything lands in Must Have because no stakeholder wants to be the one who said their item isn’t critical; the facilitator must challenge this pattern directly.
  • Won’t Have is treated as a permanent rejection rather than a deferral for this iteration, causing political resistance to using the category honestly.
  • The delivery team is excluded from the session, so no one surfaces feasibility constraints before commitments are locked in.
  • Prioritization is done as a solo Product Owner exercise instead of a facilitated group conversation, so the output reflects one person’s view rather than shared alignment.

05 / Follow-Up

After the Workshop

What happens in the 24 hours after this session determines whether the MoSCoW matrix becomes a working reference or a forgotten document. The finalized matrix needs to land somewhere the team actually works, fast enough to be used in the planning that follows it.

Expected Outputs

Finalized MoSCoW Matrix
Must-Have Item List
Should-Have and Could-Have Backlog
Deferred Items Log
Stakeholder Sign-Off Record

Distribute the finalized MoSCoW matrix within 24 hours of the session to all attendees and any stakeholders who weren’t in the room. Post it somewhere the team actively works, a pinned Confluence page, a shared drive folder, or a Jira epic description, not in an email thread that gets buried before the next planning cycle.

Follow-Up Communication Template

Subject: [Program/Product Name] MoSCoW Prioritization – Session Summary and Agreed Priorities

Hi team,

Attached is the finalized MoSCoW matrix from our session on [date]. The Must-Have list represents our firm commitment for the current [sprint / increment / release]; everything in Should Have and Could Have will be revisited if capacity opens up.

If anything in the Must-Have column looks wrong to you, flag it to [name] before [date] so we can address it before the [sprint / PI] starts. After that date, changes to the Must-Have scope go through a formal change request.

We’ll revisit the Should-Have and Could-Have lists at [next planning cycle / date].

Ongoing Next Steps

  1. Product Owner posts the finalized MoSCoW matrix to [Confluence / Jira / shared drive] and pins it where the team works.
  2. Delivery lead confirms the Must-Have list fits within committed capacity and raises any conflicts within 24 hours of the session.
  3. Stakeholders bring any objections to the Must-Have list forward before [date]; after that date, scope changes go through formal change control.
  4. Facilitator or Scrum Master reviews the Should-Have list at the midpoint of the increment to identify any items to pull in if capacity opens.
  5. Revisit the full MoSCoW matrix at the next planning cycle or when a significant scope-change request comes in.

06 / References and Resources

References and Resources

Complimentary Workshops

WSJF Workshop

Sequence work to deliver maximum economic value first.

Read More

Lean Coffee Workshop

Let the group build the agenda and time-box the topics that matter most.

Read More

Ready to facilitate?

Download templates and tools to run your own MoSCoW Prioritization session.