What needs to be finished first
A fixed delivery date or release window exists so the MoSCoW negotiation is driven by constraints rather than wishes.
A list of items, stories, or features exists at comparable granularity (ideally INVEST-ready stories).
What needs to be ready before start
Backlog tool (Linear, Jira, Notion) with status or label field for MoSCoW; whiteboard or digital board with four columns (Must, Should, Could, Won't this time); timer.
A product owner with final prioritization mandate; a facilitator (often Scrum Master or delivery lead); 2-5 stakeholders for item understanding and business context; team representative from engineering.
Backlog with item descriptions; effort estimate per item (t-shirt or story points); known dependencies and risks; constraints (compliance, contracts, external milestones); definition of Must for this release.
30-90 min
Use four columns on the board. Explain categories up front: Must means release cannot proceed without it; Should is important but optional for release; Could is if time allows; Won't this time is intentionally not included now. Set timer at 60 min.
The one question this method answers
Which items must be included in the release, which are negotiable, and how much scope remains for stakeholder negotiation?
Marker: Sektion
| Step | Duration | Action | Hint |
|---|---|---|---|
1Section 1: Define must | 10 min | Define Must explicitly for this release ("without this item launch is impossible or non-compliant"). Use examples from previous releases. | If Must is discussed as "important to me," the method collapses. Strong definition restores workshop quality. |
2Section 2: PO solo ranking | 10-15 min | PO reviews the list once and assigns an initial category per item without discussion. Others note divergences. | PO ranking as the starting point avoids endless group debate. Others contribute corrections visibly, not in a side conversation. |
3Section 3: Discussion and convergence | 20-40 min | Review items with disagreement. Per item: case for elevation, case for lowering, and PO decision. Capacity check: Musts must fit within less than 60% of team capacity. | When musts exceed 60% of capacity, release risk rises. Rigorously test what can move to Should without breaking the release. |
4Section 4: Clarify won’t this time | 10 min | Move explicit out-items into Won't column and document rationale. Make clear: Won't is not never, only not now. | Explicit won’t this time reduces stakeholder frustration. If an item does not appear, stakeholders assume it was forgotten. |
5Section 5: Capacity reality check | 10 min | Aggregate estimated effort of Musts and Shoulds against available capacity. If Musts alone exceed 100%, the release is at risk and scope negotiation is required. | A common trap is stacking Musts without effort checks. The method then looks structured, but release collapses on capacity. |
What comes out at the end
Prioritized backlog in Linear, Jira, Notion or spreadsheet with MoSCoW category per item, plus release-scope document with must items and total effort, shoulds as stretch, could as optional, and won’t-this-time with rationale.
Create a separate version per release cycle with date and release name. Document category movements during sprint (for example "Item X moved from Should to Must on 12.06., reason: compliance update").
Compact working template for MoSCoW with context, input, output artifacts, and next step.
Prioritizes scope into Must, Should, Could, and Won't.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Short notes along the runsheet.
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Team capacity: 4 developers × 6 weeks = ~96 net person-days.
Status: Musts at 54% capacity with buffer for should items and unplanned work. Apple Pay is likely the first stretch candidate.
Recognize symptoms and steer against them
70-90% of items are Must while Should and Could are almost empty.
Apply Must definition strictly: release fails without this item. If someone says "important," treat as Should. PO decides to Should in ambiguous cases.
Items are prioritized without size, and no capacity calculation is possible.
Use t-shirt sizing or story points per item at least roughly. Without size, prioritization is useless for capacity decisions.
Items are dropped without clear explanation, so stakeholders cannot tell if they were excluded permanently.
Name Won’t this time explicitly and clearly: not this time, possibly included in a later release. Otherwise trust erodes.
Session ends with a provisional list, and stakeholders continue ad hoc negotiation outside the workshop.
PO signs off on final list. Changes require explicit change requests. Otherwise the method degrades within one week.
Epics and detailed stories appear in the same prioritization list.
Normalize item granularity before MoSCoW workshop. Split epics into stories or aggregate stories into epics. Otherwise ratings are unusable.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.