MoSCoW：強迫自己定義 Won't Have

Dai Clegg 1994 年在 DSDM 敏捷方法論中提出 MoSCoW（捕音 Must / Should / Could / Won't），用來解決一個敏捷團隊的核心痛點：

客戶/老闆/PM 把每個需求都標為「重要」——但週五要交付，做不完所有的東西。

MoSCoW 的本質是強迫排序。它的四個分類不是「重要程度的描述」，是承諾的階梯。

四個層級

• Must Have：沒有它，整個 release 失敗。客戶會拒收、合約會違約、產品根本不能用。
• Should Have：重要但延後也撐得住。理想狀態下要做，沒做不會讓 release 失敗。
• Could Have：有更好、沒有也行。錦上添花，時間有剩才碰。
• Won't Have（這次不做）：明確排除。這欄是 MoSCoW 最被低估、也最重要的部分。

Won't 為什麼最重要

多數團隊跑優先序排序時跳過 Won't——「就不寫了，反正大家知道時間有限」。

這是錯的。沒寫下 Won't 的清單，會在 sprint 中段被偷渡進來。客戶問「能不能順便做這個」、團隊成員想「這個應該也快」、PM 覺得「不做會被質疑」——於是時程崩潰、Must 也做不完。

寫下 Won't 的力量在於：當有人提這個項目時，可以指著清單說「這是這次明確不做的」。爭論從「要不要做」變成「要不要從 Won't 改成 Should」——那需要更高的舉證責任。

60% 規則

MoSCoW 的隱形規則：Must 工時不能超過總工時的 60%。

如果你發現所有需求都被標 Must，工時 110%——你沒在排序。逼自己用嚴格的標準篩 Must：「沒有它，這次成功定義會崩潰嗎？」這個門檻會把多數需求踢到 Should。

它的限制

MoSCoW 是任務分類，不是策略決定。它幫你決定「這個 sprint 做什麼」，不幫你決定「這個產品該往哪走」。後者要用 Kano、JTBD 或 BCG 矩陣。

也別把它當成永久標籤——下個 sprint 的優先序會重排。Won't 不是「永遠不做」，是「這次不做」。

完整的引導問題在 Apexhone 的 MoSCoW 頁裡。