要排列用户故事优先级，要先需要搞清楚，用户故事是什么？
用户故事描述了对用户、系统、或者软件购买者有价值的功能。用户故事由以下三方面组成。
- 一份书面的故事描述，用来做计划和作为提示；
- 有关故事的对话,用于具体化故事细节；
- 测试，用于表达和编档故事细节且可用于确定故事何时完成；
3C原则:卡片（Card）、对话（Conversation）、确认（Confirmation）
其次，必须明确一个问题：希望在发布中包含哪些功能？
为了计划一个发布，客户必须排列故事的优先级，把故事划分为诸如高优先级、中等优先级和低优先级这三种类型。但是这会导致长时间低效率的讨论，比如会针对某个故事是高优先级还是中等优先级而争论不休（主要是高与中，中与低之间还是会存在模糊地带的）。这个时候，我们可以借用莫斯科（MoSCoW）原则来排列。
MoSCoW是以下短语的缩写
- 必须有（Must have）
- 应该有（Should have）
- 可以有（Could have）
- 这次不会有（Won't have this time）
“必须有的功能”是指系统的基本功能。“应该有的功能”是指很重要但是短期内有替代解决方法的功能。如果项目没有时间约束，通常认为应该有的功能是强制性的。“可以有的功能”是指如果没时间就可以在发布中不予考虑的功能。列为“不会有的功能”是客户期望拥有但是同时承认需要在后期发布中实现的功能
排列故事优先级的技术要素有哪些？
如果是开发团队的话，可以用来排列故事优先级的要素有这些：
- 故事不能如期完成的风险
- 推迟实现一个故事时对其他故事的影响
如果是客户和用户对用户故事进行排序时，可以参考如下要素：
- 故事对于广泛用户或客户的重要性。
- 故事对于少部分重要用户或客户的重要性
- 故事与其他故事的内聚性（例如“缩小”可能并不是高优先级的，但是可以当作高优先级的，因为它与高优先级故事“放大”对应）
总的来说，开发人员实现故事时会有一个顺序，当客户和开发人员对这个顺序有不同意见的时候，最后应该是客户说了算。
但是，客户如果缺乏哪些信息，比如客户不知道每个用户故事大约多久才能完成的话，就很难确定用户故事的优先级，所以开发团队应该帮助用户估算用户故事。此时，客户不会把用户故事的估算加起来，而是会利用这些估算，结合自己对每个故事价值的评估，来进行一个综合性的优先级排序，从而使得交付给公司的价值最大化。结果往往是，一个特别的故事对于公司来说可能有很大的价值，但需要一个月的时间来开发，一个不同的故事可能只有它一半的价值，但可能需要一天的时间就搞定了，这种情况还是非常普遍的。
快速排列用户故事优先级的方法就介绍到这里，你学会了么？
-参考材料
Mike Cohn 《用户故事与敏捷方法》
图片发自简书App
