什么是故事点数？实用指南

故事点数是团队为一项工作所分配的相对工作量单位，它综合了工作的复杂程度、不确定性，以及工作量的大小，而不是会花费多少小时。团队会把每个条目与其他条目进行比较（"这个大约是那个工作量的两倍"），而不是预测具体的时钟时间。点数通常是在计划扑克会议中，使用类似斐波那契数列这样的刻度来选定的。下面将介绍：它们究竟衡量的是什么、证据怎么说，以及如何在不过度承诺的情况下用好它们。

什么是故事点数？

故事点数回答的是一个比较性的问题，而不是绝对性的问题。团队不会问"这需要多少小时"，而是问"与我们已经了解的工作相比，这件事有多大"。大家都认为很小的一个故事可能是 2 分，分量更重一些的可能是 5 分，庞大且模糊的则可能是 13 分。这个数字并没有固定对应的时间。它是一个团队共享的、相对的大小。

使用抽象单位的意义在于，把估算与任何单个人的工作速度分离开来，也与承诺截止日期所带来的压力分离开来。初级开发者和高级开发者完成同一件工作所花费的时间可能不同，但他们往往能够就"一个条目大约是另一个条目两倍工作量"这件事达成一致。

故事点数由什么构成

三个因素会被整合进一个数字里：

• 复杂度： 工作有多精细复杂、涉及多少个活动部件、触及多少个系统。
• 不确定性： 团队目前还有多少未知因素。未知因素和风险会把数字推高。
• 工作量： 即使每个部分都很简单，重复性工作有多少。

这就是为什么两个耗时相近的条目可能会得到不同的点数。一个分布在四十个文件中的简单改动，和一个集中在单个文件中的棘手算法，二者都算"大"，但原因各不相同。

为什么团队用点数而不是小时来估算

相对估算之所以流行，原因大多与人有关，而不是与数学有关：

• 它把估算与个人解耦。 小时数取决于由谁来完成这项工作，而相对大小则被设计为在不同人之间更加稳定。
• 比较比预测更快。 判断一个条目比另一个更大，要比预测一个精确的时长更快，因此会议进展也更快。
• 它能抵御虚假的精确性。 "13 分"诚实地传达了不确定性。而"16.5 小时"则假装拥有一种没有人真正具备的精确度。
• 它推动了对话的产生。 共同估算真正的产出并不是那个数字，而是那场能揭示隐藏工作的讨论，就像在计划扑克会议中一样。

这些都是真实的好处。但也有必要诚实地谈谈大多数指南都会跳过的那一部分。

研究实际上是怎么说的

一个常见的说法是故事点数比基于小时的估算更准确，但这一说法并没有得到对照研究的充分支持。

在一组对照实验中，专业开发者用两种方式对相同的任务进行估算：一些人给出故事点数，另一些人给出工作小时数。结果故事点数的估算反而比小时数的估算更不准确，而且耗费的时间也更长，即便是对经验丰富的开发者也是如此。同一项研究还发现，一项任务的点数"大小"会因估算者的不同而出现很大波动，这与点数本应具备的、与开发者无关的特性恰恰相反。

这种模式在大规模数据中依然成立。在一项针对 37 个开源项目、共计 37,440 个真实用户故事的 2022 年分析中，研究者将各团队的故事点数与工作实际耗费的时间进行了比较。结果显示，只有大约 7% 的项目中，点数与真实工作量高度吻合。在其余项目中，二者的关系为中等或较弱，并且大约每四个故事中就有三个的原始人工估算出现了偏差，要么偏高，要么偏低。对敏捷估算的更广泛综述也得出了类似但更温和的结论：故事点数是团队衡量工作量最常见的方式，但并没有确凿证据表明它们能够准确预测工作量。（完整参考文献见下方"参考文献"部分。）

诚实的结论是：故事点数并不是预测单个条目将花费多长时间的可靠方式。如果你采用它们是为了获得每个条目的精确预测，你会感到失望，而研究已经解释了其中的原因。

那么故事点数到底有什么用？

只要用在正确的地方，它们其实用处相当大。

• 建立共同理解。 当投票出现分歧时，讨论会揭示出各种假设、遗漏的任务以及风险。这种共识才是真正的成果，也是这项技巧值得花时间的原因。
• 对大量条目进行粗略预测。 单个估算会有噪声，但在整个待办列表中，误差会部分相互抵消。跟踪一个团队每个冲刺完成多少点数（即其速度）可以得到一个可用的粗略预测，这远胜于把猜测的小时数加总起来。
• 标记出令人担忧的条目。 13 分或 21 分是一种信号：这个条目太大，或者未知因素太多。在它造成麻烦之前先把它拆分。
• 让估算过程更人性化。 相对估算避免了小时数估算所带来的截止日期压力和对个人的指责。

注意，以上这些都不要求点数精确等同于工作量。它们要求的是一个能够持续沟通和比较的团队。

如何用故事点数进行估算

1. 选择一个刻度。 大多数团队使用斐波那契卡组（0、1、2、3、5、8、13、21）。逐渐拉大的间隔反映了逐渐增加的不确定性，这样你就不需要在大条目之间纠结细微的差别。
2. 选定一个参照故事。 就一个已经充分理解的条目达成一致，作为锚点（"这就是我们的 3 分"）。所有其他条目都通过与它比较来进行估算。
3. 一起估算，一起揭晓。 使用计划扑克，这样就没有人会被第一个说出口的数字锚定。完整的方法请参阅我们的分步指南。
4. 了解更多信息后重新估算。 点数只是当前理解的一个快照，而不是一份合同。当情况发生变化时，应该更新它们。

故事点数 vs. 小时数

两者都不是万能的。如果某位相关方确实需要一个具体日期，单靠点数是给不出来的。速度趋势再加上沟通，会比一堆猜测出来的小时数更接近真实情况。

常见错误和误用

• 把点数换算成小时数。 一张"1 分 = 4 小时"的对照表，会彻底抹杀使用点数的全部意义，并重新引入虚假的精确性。
• 在团队之间比较速度。 点数是按团队来校准的。A 团队的 8 分不等于 B 团队的 8 分。把速度当作生产力排名是一个众所周知的反模式。
• 把点数当作绩效指标。 一旦点数变成了一个目标，它就会被夸大，并失去任何实际意义（这正是古德哈特定律在实践中的体现）。
• 期望单个条目的精确度。 正如研究所示，单个条目的点数对其实际耗时的预测能力较弱。应该针对大量条目进行预测，而不是单个条目。
• 从不重新估算。 在还未充分理解工作之前设定的点数并非一成不变，应该随时更新。

常见问题

故事点数和小时数是一回事吗？

不是。小时数是与特定个人绑定的绝对时长。故事点数则是综合了复杂度、不确定性和工作量的相对大小，其设计初衷是与由谁来完成工作无关。

一个故事点数相当于多少小时？

没有固定的换算关系，而且建立这样一种换算会违背使用点数的初衷。有些团队会粗略地观察到，一个点数对他们来说往往对应某个时间范围，但那只是事后总结出的规律，而不是用来估算的规则。

故事点数应该用什么刻度？

斐波那契数列（0、1、2、3、5、8、13、21）是最常见的选择，因为逐渐拉大的间隔反映了条目越大、不确定性越高的特点。T 恤尺码则适合用于快速、粗略的估算。

故事点数真的准确吗？

对于预测单个条目的工作量而言，证据较为薄弱：对照研究并未显示出点数相比小时数有明显的准确性优势，而大规模分析也发现点数与真实工作量之间的相关性并不稳定。它们的价值在于建立共同理解，以及对大量条目进行粗略预测，而不是对单个条目进行精确预测。

可以在团队之间比较速度吗？

不可以。点数是在团队内部进行校准的，因此一个团队的速度无法与另一个团队的速度进行比较。用速度给团队排名会助长点数虚高，是一种常见的反模式。

谁来分配故事点数？

由将要完成这项工作的人共同决定，通常是在一次计划扑克会议中完成的。产品负责人负责澄清范围，但不负责设定具体数字，Scrum Master 则负责主持会议。

故事点数衡量的是工作量还是复杂度？

两者都衡量，再加上不确定性和工作量。它们把多个因素整合成一个相对的数字，这也是为什么两个原始工作量相近的条目可能会得到不同点数的原因。

参考文献

1. Usman, M., Mendes, E., Weidt, F. & Britto, R. (2014). Effort estimation in agile software development: a systematic literature review. PROMISE 2014.
2. Jørgensen, M. & Escott, E. Relative estimates of software development effort: are they more accurate or less time-consuming to produce than absolute estimates?（针对专业开发者的对照实验）。
3. Tawosi, V., Moussa, R. & Sarro, F. (2022). On the Relationship Between Story Points and Development Effort in Agile Open-Source Software. ESEM 2022（37,440 个用户故事，37 个项目）。
4. Pasuksmit, J., Thongtanunam, P. & Karunasekera, S. (2022). Story points changes in agile iterative development. Empirical Software Engineering.