Sprint 规划：故事点数 vs. 小时数

长久以来，对于 sprint 规划中应该使用故事点数还是小时数，一直有着不分胜负的争论。双方阵营似乎都有一系列理由，支持人们采纳自己的方式而不是对方的做法。Mike Cohn 坚决支持将用户故事拆散成任务，然后再用小时数估算。而 Jeff Sutherland 提出：有些跟他一起工作过的、非常出色的团队一直在使用故事点数，并用其绘制燃尽图。很多敏捷资深人士都表达了自己的观点，说明自己喜欢哪种方式及其原因。

在 Mike 看来，他不喜欢在 spring 规划中使用故事点数，因为故事点数更适合用作长期度量，对于短时间规划没有帮助。他觉得：

假设有一支棒球队已经进入赛季中段。他们在已经进行过的 41 场比赛中，场均得分 98 分。他们可以说：“我们在剩下的赛季里大概每场平均也能得到 98 分。”但是他们不会在某场比赛前这样说：“我们之前的平均得分是 98 分，所以今晚我们会得到 98 分。” 这就是为什么我说速度可以用作长期预测，而不适合进行短期规划。

Tara Lee Whitaker不同意故事点数可以用作短期度量。在她看来：

如果每个故事都足够小，并因此可以“准确”估算，而且可测试性足够好，人们可以据之创建用以确认验收的测试，那么把故事拆成更小的部分，或是重新以小时数估算之，这样做也就没多大好处了。

对于以小时数估算故事这样的方式，她非常担忧：

当我们开始讨论将故事拆分成小时任务时，我主要担心的是：我们无法从这样做得到的早期警告信号中获益，并且当我们发现完成一个故事所需时间超过预期时，那已经太晚了。

Jim Schiel 提出：也许有可能以故事点数和小时数两种方式来做 sprint 规划。然而，用小时估算的回报也许会让这种做法看起来不值得这么做。他认为：

现在咱们来看这样一个 Scrum 团队，他们承诺要完成 10 个 2 点的产品 Backlog 条目。如果他们能够全部完成，他们在这个 sprint 中的速度就会达到 20 个故事点数。下一个 sprint，他们大概会尝试再次完成 20 个故事点数。此后的 sprint 的速度多少都会受上个 sprint 的影响。这种关系会一个一个 sprint 传下去，团队会得到一个大概的速度，在 18 与 22 之间。 你能用小时数来达到同样的效果么？可以，但是要想做好就得付出非常多的成本。你到底想为什么买单？是完整的、可用的软件，还是非常准确的估算？

Jack Milunsky 进一步阐述了故事点数的意义，他提到了下列优势：

• 通用度量——故事点数是整个团队中通用的度量方式，不会因为经验、个人技术水平或团队某个人而受到影响。
• 稳定状态——等到第三个或第四个 sprint 过后，团队的产出就会达到稳定状态，产品负责人也更易于把稳定的故事点数填写到 backlog 列表中。不会多，也不会少。
• 鼓舞士气——一旦团队达到稳定状态，业务人员就能相信技术团队的能力，这能让团队士气高昂、充满自信。

Tomas Björkholm 提到选择故事点数方式的下列原因：

• 原因之一：估算是为了描述故事的大小，而不是要知道实现这个故事需要多久。
• 原因之二：理想化的人日作为度量标准，它会随时间推移根据团队的表现发生变化。故事点数相对稳定。
• 原因之三：已经证明，相对估算要比绝对而且理想化的人日正确性更高；同时，由于人日是时间度量单位，尽管可以用其做出相对估算，但还是很容易偏向绝对的使用方式。

Tomas 补充道：

Staffan Nöteberg 在关于 Pomodoro 技术的演讲中提到：大多数人对于按实际时间估算都感到不舒服。由此我想到：不舒服的人，工作效率都不高；因此，按照天估算就会导致工作效率不高。

Mike Cohn 提及：在故事点数和工作小时之间没有线性的对应关系。在他看来，每个故事的大小都会基于标准差有个分布范围。

一个点数等同于一个分布范围，等同于 _x_ 和某个标准差的结果。同样的，2 点的故事也可以依此类推……

因此，人们不能告诉项目干系人：按照以故事点数方式计算的速度，团队能在某个确定的时间完成任务。一定是个时间范围：

这个范围可是是日期范围，比如“我们可以完成你的产品 backlog 中所有的条目，但是完成时间大概在 5 月或者 6 月。”或者可以是功能范围，“我们可以在 5 月 20 号完成，你也是这么要求的，不过我们到时会完成 120 个到 140 个点数，也就是在这两个产品 backlog 条目之间。”

Mike Cohn 还提供另一种方式，它可能符合精益原则，名为“承诺驱动的sprint 规划 ”。使用这种方法，团队不会讨论故事点数或是速度。他们就是从backlog 中取出优先级高的条目，根据各自的能力，把任务分配下去，按小时估算，并实现自己的承诺。

因此，这两种用作sprint 规划的技巧各有优劣。到最后，可能还要看团队更习惯哪一种做法。您喜欢哪一种呢？原因何在？

查看英文原文： Sprint Planning: Story Points Versus Hours