MoSCoW Workshop: How to Run It in 4 Weeks, Kit Included

6 min read ยท 2026-10-10

To run a MoSCoW workshop that works, spend one week preparing a clean list, then run one 90-minute session with a fixed agenda. After that, take one week to check the plan against capacity and get sign-off, and one week to use the categories during delivery. This guide gives you that 4-week plan and the kit to run it: a list template, a definitions card to print, a script for the facilitator and an agenda planned minute by minute.

If you need a refresher on the method first, read our guide MoSCoW prioritization explained. This guide assumes you know the four categories and focuses on running the session with a real team.

The roadmap at a glance

Goal: A scope for one release that the team and key stakeholders have signed off, with a reason written next to every Must. Duration: 4 weeks

  1. Prepare the List and the Room (Week 1)

    Arrive at the workshop with a clean list, the right people and clear rules.

    • Write the release goal in one sentence, for example "Clients can book and pay for a class on their phone."
    • Fix the timebox: release date, team size and the effort the team can really give.
    • Invite a small group: the product owner, the tech lead, one or two people who will build the work and one or two key stakeholders.
    • Agree on the decision rule for deadlocks, for example "the product owner decides after hearing everyone."
    • Collect items from the backlog, support tickets, sales notes and stakeholder requests. Merge duplicates and split items too big to size.
    • Size every item with the tech lead: small, medium or large.
    • Send the list and the definitions card one day before the session.

    Milestone: A list in the kit's template, with an effort size on every line, in everyone's inbox before the workshop.

  2. Run the 90-Minute Workshop (Week 2)

    Give every item exactly one category, with a written reason for each Must.

    • Follow the agenda and the script from the workshop kit.
    • Use a visible timer for each item.
    • Park any item that takes too long, and settle it at the end with the decision rule.
    • Close by reading the Must list out loud and asking: "Can we ship with only this?"

    Milestone: The filled template, with no empty category column and no Must without a reason.

  3. Check the Balance and Lock the Plan (Week 3)

    Make sure the plan survives a bad week, then stop the categories from moving.

    • Add up the effort of all Musts and compare it with the team's capacity.
    • The DSDM guidance published by the Agile Business Consortium in What is MoSCoW Prioritization? recommends "typically no more than 60% Must Have effort", and a pool of Could Haves of "typically around 20%" as contingency. Note that this is measured in effort, not in number of items.
    • If Musts are too heavy, cut their scope or move items down. Do not stretch the deadline by default.
    • Check dependencies: no Must should depend on a Could.
    • Present the four lists on one page, with the Won't list as visible as the Must list.
    • Record the agreed version with the date, and agree on the change rule: a new Must means an existing item moves down.

    Milestone: A dated, signed version, with Musts inside the safety margin.

  4. Use the Categories in Delivery (Week 4)

    Make the labels guide real decisions, not sit in a document.

    • Add the four categories to your board or roadmap as labels or colors.
    • Build Musts first, then Shoulds, then Coulds.
    • In each weekly check-in, flag any Must at risk and drop Coulds first to protect it.
    • Give every new request a category, using the same Must test.
    • Move Won't items to the backlog with a note on who asked for them.

    Milestone: The first check-in run with the labels, and a short note on anything that moved and why.

The List Template

One row per item: the item written as an outcome, who asked for it, effort, category and reason. Fill in every column except Category and Reason before the session. The example rows come from a small team building a booking app for a fitness studio.

The Asked by column matters. When an item lands in Won't, you know exactly who to tell, and that it goes into the next round.

  • Client books a spot in a class: asked by the product owner, effort M, Must, core goal of the release.
  • Client pays by card: asked by the studio owner, effort M, Must, no payment, no booking.
  • Client cancels from the app: asked by support, effort S, Should, workaround is to call the studio.
  • Reminder before class: asked by marketing, effort S, Could, nice but not needed to book.
  • Class packs and memberships: asked by the studio owner, effort L, Won't, next release, listed first.

The Definitions Card

Print one per person. Keep it to the tests people apply in the room.

  • Must: if we ship without it, is the release useless, illegal or unsafe? If a workaround exists, it is not a Must.
  • Should: painful to leave out, but there is a workaround.
  • Could: we add it if time allows, and drop it first if a Must is at risk.
  • Won't (this time): out of this release, kept for a later round.

The Facilitator Script

Six lines cover every moment of the session, from the opening to the final check.

  • Opening: "We are deciding what this release cannot ship without, and what goes first if time runs short. Every item gets one category today."
  • For each item: "What happens if we ship without this?"
  • When someone pushes for Must: "What is the workaround if it's missing? If there is one, it's a Should."
  • When the group is stuck: "We'll park this one and settle it at the end with our decision rule."
  • When everything drifts up: "Let's check the total effort of our Musts against the margin we agreed."
  • Closing: "Here is the Must list. Can we ship with only this?"

The Agenda, Minute by Minute

If your list is longer than the item-by-item slot allows, pre-sort the obvious items in week 1. Then use the session for the borderline ones.

  • 0:00 to 0:05, Open: goal, deadline, decision rule, read the opening line.
  • 0:05 to 0:15, Align: read the definitions card, test it on one practice item.
  • 0:15 to 0:25, Quick Won'ts: agree on the items everyone already sees as out of scope.
  • 0:25 to 1:05, Item by item: timer per item, Must test, reason written, park disputes.
  • 1:05 to 1:10, Break: facilitator totals Must effort.
  • 1:10 to 1:20, Effort check: compare Must effort with capacity, move items down if needed.
  • 1:20 to 1:30, Close: settle parked items with the decision rule, read the Must list.

Running It Remotely

The same agenda works on a video call. Share one board or sheet, for example a Notion board or an Excel file, with one column per category. Ask people to keep cameras on during the item-by-item step, and let only the facilitator move items, so the board stays readable.

Where MoSCoW Fits in Your Planning

MoSCoW sets the scope of one release. To rank a long backlog inside a category, use a scoring method like RICE prioritization. To place each release on a timeline, follow how to make a roadmap or start from one of these roadmap templates. After launch, revisit the plan on a steady rhythm: how often you should update your roadmap.

Common mistakes to avoid

  • Inviting too many people. Keep the group to decision makers and builders, and update the others after sign-off.
  • Sizing items in the room. Do it in week 1, or every debate turns into an estimation session.
  • Skipping the quick Won'ts. Starting with easy agreement sets a calm tone for the hard items.
  • Ending with parked items open. Apply the decision rule before people leave.
  • No date on the agreed version. Without it, categories quietly drift during delivery.

Frequently asked questions

How long should a MoSCoW workshop take?

Plan one 90-minute session for one release. Do the preparation in the week before: list, merge, size. That keeps the session for decisions only. If the list is very long, pre-sort the obvious items and use the session for the borderline ones.

Who should attend a MoSCoW workshop?

The product owner or project lead, the tech lead, one or two people who will build the work and one or two key stakeholders. Keep it small. Everyone else gets the signed version afterward.

What do you do when a stakeholder says everything is a Must?

Ask what happens if the release ships without each item, and whether a workaround exists. Then show the total Must effort against the team's capacity. DSDM guidance recommends typically no more than 60% Must Have effort, which makes the trade-off visible.

Can you run a MoSCoW workshop remotely?

Yes. Use one shared board or sheet with a column per category, and keep the same agenda. Let only the facilitator move items, and use a visible timer for each one.

Generate this roadmap with AI