原创：【Scrum实战】四、用户故事优先级确定

上一讲介绍了需求优先级的确定，但是在这个需求，主要指的是Epic/Backbone和Feature层面的，细化到User Story层面，并不适合那两个规则，这一讲我们介绍下用户故事（User Story）的优先级怎么确定。

一般在迭代计划会前，PO会使用MoSCoW规则（莫斯科规则）对Sprint Backlog进行排序，根据莫斯科规则的规定，Sprint Backlog中的用户故事分为四级（其实只有前3级）：

1. Must：必须做的；
2. Shoud：应该做的；
3. Could：可以做的；
4. Would not：不要做的。

按照莫斯科规则的顺序，研发团队要保证PO所需的Must、Should级别的用户故事完成，并力争Could能完成；在发生重要变更的时候，牺牲Could乃至Should保证变更。

还是用电商网站作为例子做个说明：
上一讲介绍了账号系统-个人详细资料的几个具体的用户故事：

• 完善基本资料
• 修改基本资料
• 绑定邮箱/手机号
• 设置密保问题
• ……

这几个用户故事中，如果按照Must、Should、Could三个等级来划分的话，应该是这样：

也就是说密保问题和绑定邮箱/手机号是PO最想要的功能，基本资料的完善和修改可以完成，也可以完不成。