到底什么是故事点（Story Point）？

故事点是一个度量单位，用于表示完成一个产品待办项或者其他任何某项工作所需的所有工作量的估算结果。

当采用故事点估算时，我们为每个待办项分配一个点数。待办项估算结果的原生数据并不重要，我们只关注最后得到的相对估算结果。一个估算值为2的用户故事应该是估算值为1的用户故事的2倍。而它也应该是另一个估算值为3的用户故事的三分之二。

团队不要采用100、200、300，或者1百万、2百万、3百万，而要使用1、2、3。估算结果是比值，而不是绝对值。

由于故事点数代表了开发用户发故事所需的全部工作量，所以团队的估算必须考虑到影响工作量的所有因素。这可能包括：

在用故事点估算时，必须要考虑以上每一个因素。让我们看看每个因素是如何影响故事点的。

如果要开展的工作越多，工作量的估算值当然就会越大。考虑两个网页开发的案例。第一个网页只有一个字段和一个要求输入姓名的标签。第二个网页有100个只需要输入一小段文本的字段。

第二个网页并不比第一个网友更复杂。字段之间是不存在交互的，每个字段只不过是一点文本而已。因此第二个网页并不存在额外的风险。这两网页之间的唯一区别就是第二页有更多的事情要做。

应该给予第二个网页更多的故事点数。但它即使有多了100倍的字段数，可能仍然得不到多100倍的点数。毕竟，由于规模经济效应，第二个网页的工作量可能只是第一个网页的工作量的2或3或10倍。

产品待办项的风险和不确定性会影响其故事点估算值。

如果产品待办项的干系人在询问需求事说得不清不楚，那么团队在估算时应当把不确定性也反映在估算结果中。

如果要实现一项功能时需要改动一段缺乏自动化测试的、结构脆弱的老代码，那么估算结果中也应该反映这个风险。

在进行故事点估算时，还应该考虑复杂度。回顾一下之前那个有100个琐碎文本字段且字段之间无交互的Web网页开发的例子。

现在考虑另一个也有100个字段的网页。但这些字段中，有些是采用日历控件弹出的日期字段；有些是格式化的文本字段，如电话号码或社会安全号码；另一些字段则需要做信用卡号码的校验和验证。

页面上的字段之间还需要相互交互。如果用户输入一个VISA卡，会显示三位CVV字段。但是如果用户输入美国运通卡，则需要显示四位CVV字段。

尽管这个页面上仍然只有100个字段，但这些字段更难实现。它们更复杂，需要花更多时间才能实现。开发人员出错的可能性更大，因此不得不采取一些预防和纠正措施。

这种额外的复杂度都应该反映在所提供的估算结果中。

把这三个因素合成一个数字并提供一个估算值，貌似是不可能的。然而其实是可能的，因为可以统一到工作量这个因素。

首先，估算人员要考虑的是：完成产品待办项所描述的那些工作，到底需要多少工作量。

然后，估算人员要考虑的是：在处理产品待办项的风险和不确定性方面需要付出多少工作量。通常可以通过考虑到问题发生的风险以及风险确实发生会造成的影响来做到。因此，例如，一个可能会发生并将消耗时间的风险将会增加估算值，而一个不太可能发生且无关紧要的风险则不会增加估算值。

此外，估算人员还要考虑要开展的工作的复杂度。复杂的工作需要花费更多的心思，可能需要进行更多的试错试验，可能需要与客户进行更多的反复，还可能需要花费更长的时间来验证和改正错误。

所有这三个因素必须都结合考虑。

故事点估算必须要覆盖直到实现产品待办项待真正完成的所有事项。如果团队的“完成的定义”中包括了创建自动化测试来验证这个故事（并且这是一个好主意）这个事项，那么创建这些测试的工作量也应该包含在故事点估算结果中。

故事点可能是个难以把握的概念。但是花时间去充分理解——故事点数代表着其工作的数量、复杂度及其风险和不确定性——将会是值得的。