上一讲介绍了需求优先级的确定，但是在这个需求，主要指的是Epic/Backbone和Feature层面的，细化到User Story层面，并不适合那两个规则，这一讲我们介绍下用户故事（User Story）的优先级怎么确定。
一般在迭代计划会前，PO会使用MoSCoW规则（莫斯科规则）对Sprint Backlog进行排序，根据莫斯科规则的规定，Sprint Backlog中的用户故事分为四级（其实只有前3级）：
- Must：必须做的；
- Shoud：应该做的；
- Could：可以做的；
- Would not：不要做的。
按照莫斯科规则的顺序，研发团队要保证PO所需的Must、Should级别的用户故事完成，并力争Could能完成；在发生重要变更的时候，牺牲Could乃至Should保证变更。
还是用电商网站作为例子做个说明：
上一讲介绍了账号系统-个人详细资料的几个具体的用户故事：
- 完善基本资料
- 修改基本资料
- 绑定邮箱/手机号
- 设置密保问题
- ……
这几个用户故事中，如果按照Must、Should、Could三个等级来划分的话，应该是这样：
| 用户故事 | Must | Should | Could |
|---|---|---|---|
| 完善基本资料 | ✅ | ||
| 修改基本资料 | ✅ | ||
| 绑定邮箱/手机号 | ✅ | ||
| 设置密保问题 | ✅ |
也就是说密保问题和绑定邮箱/手机号是PO最想要的功能，基本资料的完善和修改可以完成，也可以完不成。