什么是故事点？

故事点是一种相对大小的单位。团队不以小时或天数来估算一项工作，而是把它与已经做过的工作相比较：“这个大约是那个的两倍大。”这个数字同时体现了工作量、复杂度和不确定性。

为什么用相对值而不是小时

人们不擅长预测一项任务要花多长时间，却相当擅长判断一项任务是否比另一项大。故事点利用的正是后一种能力。

• 点数与由谁来做无关。 无论是资深还是初级工程师接手，一个故事都是 3 点；差别体现在团队完成点数的速度上，而不在估算里。
• 估算保持快速。 把一个故事与已知的故事相比较只需几秒钟。把它拆成小时要花长得多的时间，而且很少因此更准确。
• 点数通过测量转化为日期。 一旦团队知道自己每个迭代能完成多少点——也就是它的速率——就能预测一组故事何时完成。

估算是一场定大小的对话，而非一项承诺。如果团队对某个数字意见不一，讨论往往会暴露出对故事的误解，而这才是更有价值的收获。

尺度

团队会选一套简短的尺度，让估算保持粗粒度。常见的有：

• Fibonacci——0, 1, 2, 3, 5, 8, 13。间隔随大小增长，因为大故事的不确定性更高。
• 线性——0, 1, 2, 3。一套小尺度，适合把工作拆得很细的团队。
• T 恤尺码——S, M, L（有时还有 XS 和 XL）。

一个故事大到超出尺度上限，就是该把它拆成更小故事的信号。

以团队方式估算

一种常见技巧是规划扑克：每个人私下选一个估算值，所有人同时亮出，给出最高和最低估算的人说明理由，然后团队再确定一个数字。同时亮出能避免第一个发言的人影响其他人的判断。

在故事开始之前、团队理解了它的“完成”意味着什么——也就是验收标准——之后再进行估算。见用户故事与迭代规划。

East Agile Tracker 的做法

• 默认由功能取点数。 除非项目开启了 Points for bugs and chores，否则缺陷和杂务不做估算。见估算功能。
• 随附三套尺度： Fibonacci（0, 1, 2, 3, 5, 8, 13）、East Agile（0, 1, 2, 3）和 3-Point（1, 2, 3，对应小 / 中 / 大）。尺度按项目选择；之后更换尺度不会重新映射已有的估算。见 Points。
• 点数驱动速率。 故事一旦到达项目的完成状态，其点数就计入速率，而速率决定接下来各迭代的大小。见速率。
• 未估算的故事可以搜索。 is:unestimated 筛选器会列出仍需要一个数字的功能。见搜索与筛选。

延伸阅读

• 什么是速率？——点数如何变成预测。
• Scrum 与看板对比——估算在每种方法中的位置。
• eXtreme Programming——故事点的来源方法。