Management & Thinking
ProMoSCoW Method
MoSCoW 優先序 · Source: Dai Clegg / DSDM
When the requirements list is too long and the team disagrees on "what's essential," force prioritization into four ranked tiers
Core Concept
Clegg, in DSDM agile methodology (1994): bucket every requirement into four tiers — Must (without it, you fail), Should (important but can wait), Could (nice-to-have, not critical), Won't (explicitly out of scope this round). The biggest value is Won't — explicit exclusion is more honest than pretending to do everything, and frees the team from being pulled back by excluded items. Classic rule: Must should never exceed 60% of total effort.
✓ When to use this
When the requirement list spirals, team disagrees on "what's essential," or stakeholders mark everything "important." MoSCoW's value is forced ranking — especially forcing the Won't column.
✗ When not to use this
Skip when there's a single project with few requirements — just rank directly. Also unsuitable for strategic decisions, which need value judgment not classification.
Questions you will be asked
Using this framework, you will work through —
- 1.List all candidate requirements / features / tasks (don't prioritize yet).
- 2.Must Have: which are "without them, total failure"? Be strict.
- 3.Should Have: important but can be deferred?
- …and 3 more
Worked example
Expand to see what a filled-in run looks like
›
Worked example
Expand to see what a filled-in run looks like
Situation
產品下個 sprint 要交付。團隊收集了 28 個需求，每個都被標為「重要」。3 週內不可能全做，要做 MoSCoW 排序。
1. List all candidate requirements / features / tasks (don't prioritize yet).
28 個需求列表（功能 + 修 bug + 改進 UI + 重構）。
2. Must Have: which are "without them, total failure"? Be strict.
Must Have（沒有就 fail）：付款流程修復（已有客戶反應）、登入問題（影響所有人）、合規所需的隱私頁（法規期限）。共 3 條。
3. Should Have: important but can be deferred?
Should Have：搜尋速度優化、新會員引導頁、3 個 P1 bug。共 6 條。
4. Could Have: nice-to-have, fine without?
Could Have：新版主題色、會員徽章系統、社交分享功能、5 個 P2 bug。共 9 條。
5. Won't Have (explicitly out): what's excluded, and why?
Won't Have（這次明確不做）：新語言版本、AI 推薦功能、儀表板大改版、所有 P3 bug、商業模式變更實驗。共 10 條。明確排除避免後期偷渡。
6. Does Must exceed 60% of total effort? If so, which can drop to Should?
Must 是 3 條 + 工時估 40%——OK，沒超過 60%。執行：先 Must、再 Should、Could 看時間 buffer 才碰、Won't 不討論。
Use it inside ChatGPT / Claude
Paste the prompt below and the AI will walk you through this framework, one question at a time.
你現在是引導使用者跑 MoSCoW 排序的專案教練（Dai Clegg）。 依序問： 1) 列出所有候選需求/功能/任務。 2) Must Have：哪些沒有就完全失敗？嚴格篩——「重要」不算，「沒有它整個 release 失敗」才算。 3) Should Have：重要但延後也能撐？ 4) Could Have：有更好沒有也行？ 5) Won't Have（這次明確不做）：哪些被排除？為什麼？這欄最重要——明確排除避免後期偷渡。 6) Must 工時是否超過 60%？如果是，哪些可降到 Should？ 特別提醒：當使用者把 80% 都標 Must——他沒在排序。逼他用「沒有它，這次成功定義會崩潰嗎？」當門檻。 互動規則： 1. 一次只問一題，等使用者回答後再進入下一題。 2. 使用者答完所有題目前，不要做總結或下結論。 3. 若答案太抽象、太籠統，請追問一次具體例子或數字後再繼續。 4. 全部答完後，輸出三段：(a) 摘要使用者的關鍵判斷；(b) 你看到的盲點或張力；(c) 一個具體下一步行動建議。 5. 不要替使用者做決定，只把判斷攤開讓他自己決定。
Related Frameworks
Management & Thinking
Eisenhower Matrix
Clarifying which decisions deserve your attention vs. those you can delegate, drop, or defer
Management & Thinking
Kano Model
Understanding how product features actually affect customer satisfaction — not every feature is "more is better"
Investment & Finance
Opportunity Cost Framework
Resource allocation decisions — how to deploy time, money, attention; especially when you're treating "do nothing" as a free option
FAQ
How is MoSCoW different from RICE?
MoSCoW is qualitative four-level sorting (Must/Should/Could/Won't) — fast and consensus-driven; RICE is quantitative scoring (R×I×C÷E) — finer and able to rank close candidates. Use MoSCoW when there are many requirements and you need fast agreement on what's in or out; use RICE when candidates are close and need granular ordering. You can chain them: MoSCoW to filter Must/Should, then RICE to order within.
Where does MoSCoW's biggest value lie?
In the Won't — explicitly writing down "not this time" is far more honest than pretending everything fits, and it stops the team from re-litigating already-excluded requirements. Many teams use only the first three levels (Must/Should/Could), wasting half of MoSCoW's power. The real discipline of the method is the willingness to put things in Won't.
How do I keep everything from being labeled Must?
Set a capacity cap: Must takes at most ~60% of total effort, leaving a buffer for surprises. If Must exceeds that, force the team to answer for each item "without this, does the delivery actually fail?" Must means "the delivery fails without it," not "I really want it." Make that discipline explicit and most fake-Musts demote themselves.
Related studies