MoSCoW Prioritisation

Purpose

MoSCoW prioritisation provides a clear, shared language for scope decisions. By sorting every requirement into Must / Should / Could / Won't, the team and stakeholders reach explicit agreement on what is essential versus desirable versus out of scope. It is especially effective in time-boxed delivery where not everything can be built.

At a glance

How to run

1. Prepare the list (pre-work): Gather all requirements, features, or user stories on individual cards or sticky notes.
2. Explain the categories (3 min): Must — non-negotiable for this release. Should — important but not critical. Could — nice to have. Won’t — explicitly out of scope for now.
3. Sort collaboratively (20 min): Take each item and discuss which category it belongs to. Place on a four-column board. When disagreement arises, time-box the debate to 2 minutes per item.
4. Review and validate (5 min): Check that Musts are genuinely essential and Won’ts are truly deferrable. Adjust.
5. Commit (2 min): The team agrees on the final placement. Photograph or save the board.

Materials needed

• Prepared list of requirements on cards or sticky notes
• Four-column board (M / S / C / W)
• Markers
• Timer for time-boxed debates

Pitfalls & common mistakes

• Everything is a Must: If more than 60% of items land in Must, the category is meaningless. Challenge each Must.
• Won’t means never: Clarify that Won’t means "not this time", not "never".
• No stakeholder buy-in: If decision-makers are absent, the prioritisation may be overturned. Include them.
• Static result: MoSCoW should be revisited as context changes.

Inclusion & accessibility

• Pre-share the requirements list so all participants can prepare.
• Use colour-coded columns for visual clarity (green, yellow, orange, red).
• Allow written input for participants who are less comfortable debating verbally.

Variations

• Dot-vote MoSCoW: Each participant gets 5 dots to place on items they consider Must. Items with the most dots are confirmed Must.
• Weighted MoSCoW: Assign effort estimates alongside priority to create a value-effort view.
• Customer MoSCoW: Run with customers instead of internal stakeholders.

When NOT to use this

• When there is no constraint forcing prioritisation — without a fixed timebox or budget, everything remains Could.
• When the items are not comparable (mixing strategic goals with tactical tasks).
• When a single decision-maker has final authority and does not need group alignment.

Source & further reading

• Dai Clegg, DSDM Consortium (1994)
• DSDM Agile Project Framework
• Agile Alliance: MoSCoW