故事点

故事点数是一种相对估算单位，用于表示一项工作相对于其他工作的大小，而不是以小时或天数来衡量所需时间。团队通过与已完成的参考项目进行比较来分配故事点数，每次迭代累计的故事点数为预测未来工作量提供了依据。

这种抽象之所以存在，是因为人们对相对大小的估计比对绝对持续时间的估计更为可靠。当被问及某件事需要多长时间时，估计者往往会基于乐观的假设，忽略中断和返工，从而得出始终偏低的估计值。而当被问及某件物品是否比另一件物品更大时，同样的人则能给出更为准确的估计。积分制正是利用了这种不对称性，通过捕捉比较信息，并利用观察到的吞吐量来将其转换为时间。

评分旨在反映工作量、复杂性和不确定性的综合因素，而不仅仅是工作量。对不熟悉且需求不明确的代码进行的小幅修改，其工作量可能比对已充分了解的代码进行大幅度修改更大。如果团队将评分简化为工时的近似值，就会忽略这一维度，并重蹈覆辙，再次出现该技术旨在避免的估算问题。

该指标本质上是局部性的，而这恰恰是实践中最常被违反的特性。分数是根据特定团队的参考项目进行校准的，反映了该团队的背景、代码库和组成。因此，比较不同团队的总分毫无意义，而且使用速度作为跨团队的生产力指标会持续导致估算值虚高，因为人们会倾向于给同样的工作更高的分数。

当速度成为团队目标时，同样的扭曲现象也会出现在团队内部。如果要求团队提高速度，他们可以通过更宽松的预估来立即实现目标，速度数值会提高，但实际情况却没有任何改变。由于速度指标很容易被操纵，而且其设计初衷是作为规划辅助工具而非绩效衡量标准，因此将其用于绩效报告会使其失去原本的效用。

估算确实会产生实际成本，值得仔细审视。细化和计划会议会耗费团队大量时间，而且对于规模分布相对稳定的工作而言，估算相比简单地统计数量带来的收益微乎其微。采用“不估算”方法的团队会统计已完成的物品数量，并根据历史吞吐量进行预测，这种方法通常同样准确，而且成本要低得多。估算是否值得投入成本，这是一个合理的问题，而非异端邪说。

当参考指标不再具有代表性时，就需要进行重新校准。这种情况会随着代码库的成熟、团队构成的变化或工作性质的转变而发生。如果团队多年来一直沿用原有的评估标准，他们会发现这些指标所描述的背景已经不复存在，导致预测结果出现偏差，而没有人能找出原因。

积分的价值在于能够揭示估算过程中的分歧。当团队成员对同一项目赋予截然不同的价值时，随后的讨论通常会揭示出他们对需求的理解存在差异，或者其中一人意识到了其他人所不了解的复杂情况。这种讨论的价值往往高于最终的估算结果，因此，我们应该继续讨论，并务实地进行计算。

由于该技术仅作为单个团队内部的规划辅助工具，其价值完全取决于外部组织如何利用其成果。在实践中，估算方法已在内部确定。 产品开发当多个团队共同开发一个产品时，通过依赖关系管理和跨流程衡量来协调工作会更加有效。 产品部门 而不是通过尝试使各团队之间的估算值标准化。