出處：blog.csdn.net/cheny_com
有沒有遇到某個重要的條目每次都被漏下完不成的情況？
有沒有遇到衝刺結束的時候發現一大堆條目都已經開工了但都沒有完成的情況？
有沒有遇到product owner
想用乙個重要的變更來替代原來
sprint backlog
中的某些條目卻發現這些條目都已經「開發中」了？
有沒有遇到團隊爭議每次都應該完成所有條目（這真的很難）還是只需要完成最重要的一些？
有沒有遇到團隊爭議是否將sprint延期一天來完成最後乙個差點就完成的任務？
這些都和moscow優先順序排序方法有關。
一般在迭代計畫會上使用
moscow
方法進行這種排序，將要sprint backlog中的條目分為四級（其實只有前3級）：
must
：必須做的；
shoud
：應該做的；
could
：可以做的；
would not
：不要做的。
要按照這些順序來做，保證
product owner
所需要的
must
、should
完成，並力爭
could
能完成；在發生重要變更的時候，犧牲
could
乃至should
保證變更。
如果使用故事牆story wall進行管理，最好也按m、
s、c（
w其實不會出現）三個級別排放待開發的故事，優先拿
m，最後動
c。如果願意，可以用三種顏色的便簽紙來表示，防止m、s完成前就有人動c。
moscow只是對sprint backlog的排序方法，更多關於敏捷中的「優先順序排序」問題，請閱讀：從優先順序排序看敏捷開發的自相似性。
MoSCoW法則 使用者故事排優先順序
莫斯科法則，就是must or should，could or would not。在排使用者故事優先順序的時候，把使用者故事按以下4種類別排優先順序。must 這個迭代一定要做的。比如前面提到的 必需 的功能。should 應該做，但若沒時間就算了。比如前面提到的 不太需要的 功能。could 不...
執行緒中的優先順序
什麼才是執行緒的優先順序 對於執行緒的優先順序呢，我是這麼理解的，乙個學院裡面有好多學生嘛，而輔導員呢，就相當於超管，這麼多學生要選拔優秀畢業生，如果，是按照情面關係的話，優先順序就上場了，作為輔導員，我想讓誰讓第一就讓誰第一，對吧？不瞎扯了，步入乾貨。怎麼才可以將優先順序玩的稍微6一點呢 我還是通...
敏捷開發使用者故事系列之四 優先順序排序
這是敏捷開發使用者故事系列的第四篇。之一，之二，之三，之四，之五，之六，之七，之八，之九 優先順序排序聽起來是乙個很簡單的工作，乙個字段無外乎 重要 一般 調整一下然後按排序，就出來了。但其實裡邊有不少名堂 誰應該負責排序工作？誰最終拍板？研發因素要不要考慮？需求依賴關係導致的順序如何處理？持續交付...