我們來看看源自於 DSDM 的 MoSCow 手法，可以如何應用在自己的案子：
敏捷專案的倒三角特性，在時程與成本是fixed的前提下，習慣瀑布式專案管理的朋友們可以來想想：從 Risk 角度來看的話，時程與成本都不能動，那我們的應變回應 Contingency 應該放在哪裡？
Agile to the Rescue!!!
Contingency 從 Time 與 Costs 轉換成了 Features(Scope)。
因為你可以在 Scope 上有所取捨，Features 的名單 Product Backlog 即變成一個你管理應變的一項重要機制。
MoSCoW 的應用法則是這樣的：
Must：包括 Minimum Viable Product, Minimum Usable Subset 大約是 60% of the total development effort
Should：約 20% of the total development effort
Could：約 20% of the total development effort
Won't：0%
既然 Won't 不用做，那為何要specify呢？
因為你要在範疇外圍畫下明顯的界線，利害關係人的 Expectation 才能被好好的管理。
Should 跟 Could 對於決策人來說怎麼分？
把 Features 拿出來看，若是沒有了的痛苦指數是什麼？痛苦指數高的那一半應該就是 Should ，低的可以放在 Could。
60% of total development effort
任何時候想要把 Must 裡面要研發的 Features 移到後段時，建議這樣考量：
沒有這個 Feature 的話，會讓原來 Business Case 的目的消失，專案失去意義。
沒有這個 Feature 的話，整個專案會不合法。
沒有這個 Feature 的話，安全性會消失。
在不違反上述任一原則為前提的情況下，再以60%、80%、100%來看，就是團隊奮鬥的目標。
worst case 要完成 must have
average case 就是要 M+S
best case 就是 M+S+C
要知道敏捷裡面沒有 Perfection ，所以任何在60%到100%之間，而且產品是 Fit for Purpose 的（東西客戶用了有他預想的價值產生的），就可以算是一個成功的敏捷專案喔！
文章同步刊登於：台灣敏捷部落臉書社群