我们公司在敏捷转型的过程中，一直被一个问题困扰：如何排定一个迭代（Sprint）中所有用户故事（User Story，以下简称US）的优先级？

经过一段时间的实践，目前摸索出来了一点门路，发出来跟大家分享下，也欢迎大家发表自己的看法。

1. 什么是MoSCoW法则

---

1.1. MoSCoW中的四个大写字母

MoSCoW的四个大写字母，M、S、C、W分别对应以下四个词汇的首字母：

• Must have：必须有。
  如果不包含，则产品不可行。Must Have的功能，通常就是最小可行产品（MVP）的功能，比如一个电商APP的注册、登录功能。

• Should have：应该有。
  这些功能很重要，但不是必需的。虽然“应该有”的要求与“必须有”一样重要，但它们通常可以用另一种方式来代替，去满足客户要求。

• Could have：可以有。
  这些要求是客户期望的，但不是必需的。可以提高用户体验，或提高客户满意度。如果时间充足，资源允许，通常会包括这些功能。但如果交货时间紧张，通常现阶段不会做，会挪到下一阶段做。

• Won’t have：可能不会有。
  最不重要，最低回报项目，或在当下是不适合的要求。不会被计划到当前交货计划中。 “不会有”会被要求删除，或重新考虑。

1.2. MoSCoW中的两个小写字母

MoSCoW法则中，除了上述四个词汇的首字母外，还有两个“o”，这两个“o”是做什么的？

其实莫斯科法则的全称是：

Must or Should, Could or Won't.

为什么Must和Should中间加一个or，Could和Won't中间也有一个or，而Should和Could中间却没有？是不是老外为了读起来有朗朗上口的感觉，特地这么设计的？

其实不是的，真实原因是因为要区分一个US是Should have还是Could have的时候是很容易的，而要区分一个US是Must have还是Should have，或者是Could have还是Won't have的时候，不同的人会有不同的看法，即使是同一个人，不同时间、不同环境下看同一个US，也可能会得出不一样的结论，是不是看得很晕，没关系，举个例子你应该就明白了：

假设一个电商APP有以下2和US：

1. 作为一个APP用户，我想重置我的登录密码，以便在我忘记密码时依然可以使用APP。（以下简称重置密码）
2. 作为一个APP用户，我想编辑我的个人资料，以便可以个性化我的个人信息。（以下简称编辑资料）

如果从Should have还是Could have的角度来划分以上2个US，你们会得出怎样的判断？

我在公司组织过一个10人的小组投票，结果如下：

	Should have	Could have
重置密码	9	1
编辑资料	0	10

投票结果几乎是一边倒，重置密码是应该做的（Should have），编辑资料是可以做的（Could have）。

然后我又问了以下两个问题：

重置密码是必须做的（Must have），还是应该做的（Should have）？
编辑资料是可以做的（Could have），还是可能不做的（Won't have）？

然后大家就吵起来了🤣

比如关于重置密码的争论如下：
如果从用户第一次安装使用的角度来看，重置密码不是必须的，但是如果用户换了手机或者重新安装了APP，要重新登录的时候但是忘了密码，那这个US就是必须的了，所以有的人就说这个US是Must have的，有的就说是Should have的。

同样，编辑资料这个US也是各有各的理解，但是谁也不能说服对方。

各位看官看到这，应该就明白了MoSCoW法则中的那两个o的作用了吧，四个字概括就是：

求同存异

一个US，只要确定它是Must or Should还是Could or Won't，而不用细化到Must、Should、Could还是Won't。

这里插个题外话，之前一个敏捷教练给我们培训的时候，谈起敏捷宣言诞生的时候，他说了这么一个小故事（不知道真假，大家看看就好）：
当年那17位敏捷大师在犹他州的雪山上聚会的时候，他们一开始是想定一个大家都认可的具体实践方案的（比如类似Scrum、Kanban、XP等），但是分歧实在太大了，每个人都认为自己的实践方案是最优的，后来大家实在谈不下去了，于是就退而求其次，大家发现每种实践方案的指导思想基本都是一致的，所以就抽象出了一份《敏捷宣言》。

MoSCoW法则其实有点类似《敏捷宣言》的诞生过程，既然细节无法达成统一，那我们就再向上抽象一层吧。

2. Sprint Backlog优先级的确定

---

2.1. PO使用MoSCoW法则对Sprint Backlog排定优先级

Sprint Backlog在计划会上被确定后，PO要再对这份Backlog做一次排序的确认，排序的原则就是MoSCoW法则，但是PO在实际使用的时候，不需要刻板的拿Must or Should还是Could or Won't这个概念往上套，而是问自己这么一个问题：

这个US如果这个Sprint做不完，我（以及我所代表的所有stackholder）可以接受吗？

如果可以接受，那就把这个US放到Could or Won't，否则就放到Must or Should。

假设Sprint Backlog总共有20个US，经过PO的排序后，其中10个被划分到了Must or Should级别（意味着必须做完），10个被划分到了Could or Won't级别（意味着可以做不完），PO排序完的Backlog类似这样：

	用户故事
Must or Should	1、2、3……10等10个必须做完的用户故事
Could or Won't	11、12、13……20等10个可以不做完的用户故事

表一 PO排序后的用户故事列表

至此，PO对优先级排序的主要工作就结束了，但是，这样就算完成了吗？

2.2. 开发团队对Sprint Backlog排定优先级

PO已经已经使用MoSCoW法则对Sprint Backlog做了优先级的排序，但是PO从“必须做完”和“可以做不完”这个角度给的这个顺序（准确的说，只能算是个分类），大部分情况下，研发团队并不能严格按照这个顺序来开发，举个常见的例子：

我们研发的大部分的功能模块，可能都会涉及“增删改查”的功能，做过开发的同学都知道，这几个功能的顺序，一般都是遵从增→查→删/改的顺序来进行的，不做增，是没法查的；不做查，是没法删/改的。
因为大部分PO不懂技术，所以他可能会把增或查放到Could or Won't级别，或者把删/改的优先级放到增/查前面，这就导致如果按照这个优先级的排序来开发，会进行不下去的。

这里再插一句题外话：

程序员跟产品经理经常互怼，本质上是因为这两个群体的思维方式完全不一样：

在拿到一个需求之后，技术思维想的是：这个好实现么? 实现起来需要多长时间？这样操作可> 能会有性能问题，以前的代码支持这个功能可能需要重构，那我们赶紧团结起来，把这个需求怼回去。

而产品经理的思维是这样的：这个需求是用户需要的么？解决了什么样的痛点？能带给用户什么样的价值？有没有竞品？能带来什么样的商业价值？你们一帮程序员，赶紧给我做出客户需要/市场需要的产品出来，不要跟我哔哔什么技术细节。

总之一句话，技术思维多是以自我为中心的，而产品思维是用户驱动的。这一点导致在Backlog优先级的划分上，两边也会存在分歧。而迭代计划会，正是解决这个分歧的最佳时机，促成解决这个分歧的人，就是SM。

所以在PO按照MoSCoW法则排定好他的优先级后（更深层次一点说，应该是按照商业价值来排定的），SM要引导开发团队对这个排序做一次评审，一般我们是按照以下几个点来检查的：

• 实现依赖
  比如上面提到的增删改查的技术依赖，被依赖的功能要排在高优先级。
• 团队依赖
  如果还有其他团队对我们即将要做的US有依赖，一般这种需求要放在最高优先级。
• 技能依赖
  这点在成熟的敏捷团队可能影响会比较小，但是如果团队里大部分成员还达不到一专多能的要求，大家还都是只会一门技术，比如J2EE、Android、iOS、Web等，那在排定优先级的时候，也要考虑一下技能的依赖，比如一个团队有2个Web研发，1组APP研发（Android+iOS）（注意，Scrum中的研发团队是没有职位的区分的，我这里说的是早期的敏捷团队，他们刚从传统的筒仓式部门转成跨职能部门，很多人早期都只会一门技术），那在排定Backlog优先级的时候，最好是按照2个Web故事→1个APP故事→2个Web故事→1个APP故事……这样的顺序来排定。
• 其他
  有时也需要考虑一下特殊情况，比如有人会请假、某个故事难度比较大（也就是估点较多）等。

但是研发团队的排序前提，是在PO给定的2个大的优先级范围内进行的，原则上只能将低优先级的故事向上提（从Could or Won't提升到Must or Should），如果要将一个Must or Should的故事降低到Could or Won't，需要征得PO的同意。

经过研发团队和PO共同排序后，US的顺序可能会大变样，而且Must or Should和Could or Won't的US数量也会有所变化，类似这样（注意和表一对比）：

	用户故事
Must or Should	18、1、15……2等15个必须做完的用户故事
Could or Won't	11、13、16、19、20等5个可以不做完的用户故事

表二 PO和研发团队共同排定的优先级顺序

至此，Sprint Backlog的优先级排序工作全部完成。

3. 一些特殊情况的补充说明

每个敏捷团队的人员组成都是不一样的，技能也是不一样的，做的事情也是不一样的，所以上面的方法可能也不是适用于每个团队，但是有些特殊情况，还是有些应对方式的。

3.1. 项目要求和研发技能不匹配

这是我们经常遇到的一个问题，就是我们要做的事情，可能以我们团队目前的人员配置，并不是最合适的，比如我们团队有2个很厉害的APP研发，但是我们要做的项目并没有APP的任务，那怎么办呢？

我的做法是鼓励大家学习新的一门知识，在一个良好沟通氛围的团队，团队成员是不排斥、也不惧怕学习新知识的。

那一个研发人员，需要学习多长时间才能上手一门新技术呢？

这个问题没有明确的答案，小程序可能一周就上手，Android转Java可能也就2、3周，但是这个也要看这个研发同学之前的经验如何，如果是个大神，可能上手更快，如果是个菜鸟，那可能时间要翻倍，甚至更多。但是不管怎样，有一点SM一定要注意：

所有的学习任务，要当做学习型US，加到Backlog中，并且设置明确的验收标准（AC），比如：

作为研发人员，我想看完《XXX从入门到放弃》，以便掌握XXX的基础知识。
作为研发人员，我想模仿XXX做一个XXX demo，以便促进我更好的掌握XXX的知识。

学习型US，也一样贴到任务看板，每天站立会跟踪进度，以我个人的经验，即使是学习一项全新的知识，2个迭代（4周）也就能上手了。

3.2. 每个迭代开始前，都要重新评估PBL中所有US优先级

我在文章开始的时候举了个例子：

作为一个APP用户，我想编辑我的个人资料，以便可以个性化我的个人信息。（以下简称编辑资料）

这个US大部分人都选了Could or Won't的优先级，但是我们可以看下淘宝、京东等主流的电商APP，他们都是有编辑资料的功能的，他们为什么会做这个功能呢？

我们都知道，敏捷开发强调的是交付当前最有价值的功能，编辑资料这个US到底有多大价值呢？

假设有1%的人想要用这个功能，那在我们的项目早期，可能日活（DAU）也就几十、上百人，即使发展到成千上万人，可能也不影响多少用户。但是如果我们的项目，DAU达到十万、数十万甚至百万级别了，那影响到的用户可能就要达到几千甚至上万人了，到了这个时候，编辑资料这个US的商业价值就大大提升了，PO就要在合适的时间点，将这个US挪到Must or Should级别了。

关于种子用户、主流用户的需求区别，建议大家看下《精益创业》这本书，可能会对PO的决策有所帮助。

3.3. 其他

工作中其实还遇到其他一些特殊情况，但是一时想不起来那么多了，大家如果有问题，可以留言一起讨论下。