作者：陈勇
出处：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的排序方法，更多关于敏捷中的“优先级排序”问题，请阅读：从优先级排序看敏捷开发的自相似性。
点击下载免费的敏捷开发教材：《火星人敏捷开发手册》
再分享一下我老师大神的人工智能教程吧。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到我们人工智能的队伍中来！https://blog.csdn.net/jiangjunshow
