Sprint 产品待办列表的优先级要怎么排？

在梳理产品待办事项列表的过程中，产品负责人需要先做优先级排列，保证我们 在一定的时间盒内能够交付需要优先级最高、最具价值的用户故事。

那这个用户故事的优先级要怎么排列，我们怎样选择用户故事的实现顺序？

有一个实践可以推荐给大家：MoSCoW 排序法。MoSCoW 排序法是一种用于管理、业务分析、项目管理和软件开发的优先级排序技术，用于与利益相关者就需求的重要性达成共识。

MoSCoW 这个词本身是一个首字母缩略词，来源于四个优先类别的第一个字母：

• M-Must have：必须有的产品功能；

• S-Should have：虽然不是必须有的功能，但这些功能很重要，应该有；

• C-Could have：如果有时间来完成这些功能的话，完成这些功能会提高用户体验，但如果时间来不及，就可以先不做；

• W-W on't have this time：这次不会有的功能。

需要注意的是，“W”代表的是这次不会有的功能，而不是完全不会有的功能。举个例子，我们要从 0 到 1 开发一款卖书的 APP，在这一阶段中，“用户名改名”这一功能在第一个迭代中是“这次不会有”的功能，但当这一 APP 的基本功能都已经完善，并且拥有了几万的用户之后，我们就需要考虑是否要做“用户名改名”的功能了。

Sprint待办事项列表

总之， MoSCoW 排序法能够帮助产品负责人在做优先级排序的时候有一个具体可参考的维度。但即使用了 MoSCoW 排序法，我们也会发现不同的人排列出来的顺序也不一样。我们经常会看到产品经理和程序员各种争论，其实仔细一想，这类问题出现的原因是他们思维方式的不同：作为产品经理，他们考虑的角度是这个需求是不是用户最需要的，这个需求的客户价值有多大，这个需求对产品来说有多少价值等等；而作为研发人员，他们考虑的是这个需求的实现方式，这个需求的开发时间，这个需求与整体的系统架构的关系等等。所以一个比较合适的解决方案是确定待办事项列表的时候，需要产品负责人和研发团队、Scrum Master 一起进行沟通、确认。在这个过程中，Scrum Master 则是促成双方达成一致的关键人物。

另外一点我们在排列待办事项列表的时候需要注意的是， 团队成员的学习与培养也可以放进 Sprint 中。我们需要建立跨职能团队、培养跨职能人才，营造积极学习的氛围，鼓励团队成员学习新知识、掌握新技术。

这个学习的过程需要多久呢？其实没有一个明确的答案。 我们可以提前做好规划，将这个以学习型用户故事的方式排入 Sprint 迭代中并进行日常跟踪，例如：作为测试人员，我想看完《白话统计》这本书，以便掌握统计的相关知识。现在在我们的团队中，就已经将学习型用户故事放入每个迭代中，大家可以用其他的时间来完成这个用户故事。

基于以上几点，我们可以进行合理的优先级排序，在每个阶段中，都交付对客户或用户来说最具价值的产品增量。