Scrum 中的故事点：是什么以及如何估算

什么是故事点？

故事点 是敏捷和 Scrum 团队使用的相对估算单位，用于表示一个产品待办事项列表条目与其他条目相比有多大。故事点估算综合了所涉及的工作量、复杂度以及风险或不确定性，因此一个 5 点的条目大约是 2 点条目的两倍半。

关键词是 相对。人们不擅长说出某件事需要多少小时，却相当擅长说出“这个大约是那个的两倍”。故事点正是利用了这一优势。这些数字本身没有意义；只有与同一团队估算过的其他条目相比时才有意义。

故事点估算通常反映三个方面：

• 工作量。 需要做多少事情：界面、记录、测试、文档、页面。
• 复杂度。 工作在思考上的难度：棘手的逻辑、大量集成、不熟悉的技术。
• 不确定性和风险。 团队还有多少不了解的地方：需求不清、依赖他人、未经验证的假设。

故事点 不 衡量业务价值（那是产品负责人在对待办事项列表排序时的工作），也不是变相的时间单位。可以把它想象成为搬家货车估算家具大小：您不需要知道确切尺寸，就能知道一个衣柜大约是一把椅子的三倍大。

这个名称来自 用户故事，即许多团队用于待办事项列表条目的“作为……，我希望……，以便……”简短格式；但您可以为任何产品待办事项列表条目估算点数，无论它是否写成故事的形式。

故事点是 Scrum 的一部分吗？

不是。《Scrum 指南》（2020 版，仍是当前的官方版本）规定，由将要开展工作的开发人员负责估算产品待办事项列表条目的规模，产品负责人可以帮助他们理解其中的权衡。它并未规定如何估算规模。故事点与用户故事一样，是许多 Scrum 团队选择添加的补充实践。

故事点起源于 20 世纪 90 年代末和 21 世纪初的极限编程（XP）。XP 创始人之一 Ron Jeffries 曾解释说，团队最初以“理想天数”（一对开发人员在没有任何干扰的情况下需要多长时间）进行估算，然后乘以一个负荷系数得出日历时间。由于相关方觉得理想天数令人困惑，团队便开始称之为“点数”。Jeffries 在 2019 年的一篇文章中写道，这个名称可能是他提议的，并对点数经常被误用一事表示“现在很抱歉”，同时也表示，觉得它们有价值的团队应该继续使用。

这段历史解释了故事点的优势和所受的批评，我们将在下文介绍。关于 Scrum 如何作为一个整体运作，请参阅 什么是 Scrum.

为什么 Scrum 团队使用故事点

如果使用得当，故事点能在多个方面帮助团队：

• 更快的估算。 比较条目比为几个月后的工作逐小时编制任务清单更快。
• 共同的理解。 不同的估算会暴露出不同的假设。随后的讨论往往比数字本身更有价值。
• 内置了不确定性。 风险较高的条目得到较大的数字，表明它在就绪之前需要拆分或进行探针（Spike）。
• 与技能水平无关。 资深开发人员和初级开发人员所需的时间可能大不相同，但他们可以一致认为一个条目大约是另一个的两倍大。
• 更好的预测。 每个冲刺完成的点数构成速度，使冲刺计划会和发布预测更加切合实际。
• 更早的待办事项列表决策。 粗略的规模帮助产品负责人在对以下内容排序时权衡成本与价值： 产品待办事项列表.

故事点最适合团队稳定、处理的条目类型相似并以冲刺进行规划的团队。对于已经将工作拆分为小而相似的条目、可以直接计数的团队，故事点的价值就较小。

故事点与小时对比

可以将点数换算为小时吗？不能可靠地换算。Mountain Goat Software 的 Mike Cohn 撰写了大量关于敏捷估算的文章，他认为每个点数值对应的是一个小时数的 区间 而不是固定数字，而且这一区间因人而异。一个 3 点的条目，资深开发人员可能只需半天，新人可能需要两天；两人仍然可以一致认为它是 3 点。规定“1 点 = 4 小时”只会让点数多绕一步又变回小时。

但这并不意味着时间毫无用处。许多团队用点数估算待办事项列表条目的规模，然后在冲刺计划会上将选定的条目分解为几小时的任务来规划工作。如果您的组织在预算方面需要工作量数据，我们关于 工作量估算 的指南介绍了基于小时的估算技术。

故事点刻度

大多数团队使用数字间隔逐渐增大的刻度。这些间隔反映了较大的条目具有更多不确定性，也能避免团队为 6 和 7 之间的差别争论不休。

计划扑克卡组通常会增加一些特殊卡片： 0 表示微不足道的工作， ? 表示“我还无法估算”，咖啡杯则表示“我们休息一下吧”。出现 ? 通常意味着该条目在任何人估算之前需要先梳理或进行探针（Spike）。

参照表示例

每个团队的刻度都是自己的，但写下这些数字对您意味着什么，有助于新成员上手并保持估算的一致性。以下是一个网页产品团队的示例：

如何逐步估算故事点

以下是向 Scrum 团队引入故事点的实用方法。步骤 1–3 是一次性设置；步骤 4–8 则成为例行工作。

1. 选择一个参照故事。 挑选一个最近完成、大家都记得、既不太小也不太大、进展基本符合预期的条目。给它一个数值，通常是 2 或 3。
2. 再增加一两个锚点。 一个明显较小的条目（1）和一个明显较大的条目（5 或 8）会让比较更容易。它们共同构成您的基准。
3. 商定刻度和规则。 选择类似斐波那契数列的刻度，确定一个冲刺可接受的最大规模，并商定如何处理缺陷和探针（Spike）。
4. 先梳理，再估算。 在 待办事项列表梳理，产品负责人解释每个条目，团队澄清验收标准。估算不清晰的条目是在浪费时间。
5. 共同估算。 每位开发人员将条目与参照故事进行比较形成自己的判断，然后所有人同时亮牌，例如使用计划扑克。
6. 讨论差异，而不是取平均值。 如果估算从 2 到 8 不等，由给出最高和最低估算的人解释理由。往往是某个人知道其他人不知道的事情。再次投票；一旦接近就迅速定下来。
7. 拆分任何过大的条目。 如果一个条目超出了商定的最大值，请在它进入冲刺之前将其拆分为更小但仍有价值的部分。我们关于 史诗、故事和任务 的指南介绍了具体方法。
8. 记录并复盘。 将估算值记录在条目上。每隔几个冲刺，在回顾会上回顾一下：您估为 5 点的条目感觉起来真的相似吗？调整参照示例，而不是修改过去的估算。

Scrum 中的计划扑克

计划扑克是商定故事点最常用的方法。它速度快，让每个人都有发言权，并能避免受第一个说出的数字的锚定影响。

1. 产品负责人读出条目并回答问题。
2. 每位开发人员从刻度中私下选择一张卡片。
3. 所有人同时亮牌。
4. 如果卡片数值接近，就取最常见的值或商定一个数字，然后继续。
5. 如果差异很大，由估算最高和最低的人解释他们的想法，然后团队再次投票。

在 Scrum 中，由 开发人员 投票。产品负责人解释条目，Scrum Master 负责引导，但除非他们也在做这项工作，否则两人都不出牌。远程团队可以使用简单的在线计划扑克工具或项目管理软件中的估算功能。

关于亲和估算、桶估算法和 T 恤尺码估算等其他技术，请参阅我们关于 敏捷估算和斐波那契刻度.

完整示例：估算待办事项列表

一个构建在线预约系统的团队使用 “客户可以通过确认邮件取消预约” = 3 点 作为参照故事。在梳理会上，团队对接下来的条目做出如下估算：

13 点的定金条目太大，无法在一个冲刺内稳妥完成，因此团队将其拆分为“用银行卡支付定金（正常路径）”、“取消时退还定金”以及针对支付服务提供商测试环境的一次简短探针（Spike）。短信条目被估为 8 点，主要是因为不确定性；一旦团队用过一次该短信服务，类似条目的估算很可能会缩小。

请注意，团队从未提及小时数。每个数字都是与 3 点参照故事的比较。

由谁以及何时估算故事点

大部分估算在以下活动中进行： 待办事项列表梳理，这样待办事项列表顶部附近的条目在 冲刺计划会 开始时就已估算好规模。如果团队的理解发生了重大变化，可以在计划会上重新估算。冲刺一旦开始，大多数团队就不再改动估算，而是在回顾会上从差异中吸取经验。

只估算未来几个冲刺的条目。待办事项列表中靠后的条目很可能会变化，因此先给它们粗略的 T 恤尺码，等它们临近时再正式估算点数。

从故事点到冲刺计划会和预测

将故事点加总起来时，它们就变得有用了。一个冲刺中 完全完成 的条目的总点数就是团队的 速度。未完成的条目不计分，无论它们多么接近完成；这正是让速度保持真实的关键。

在冲刺计划会中使用速度

假设一个团队最近三个冲刺分别交付了 28、33 和 30 点。其平均速度约为 30 点。下一个冲刺，六名开发人员中有一人整整两周休假，因此团队预计产能约为平时的六分之五：大约 25 点。在冲刺计划会上，团队从待办事项列表顶部拉取条目，直到达到约 25 点、并能构成一个连贯的冲刺目标为止。

这是一个参考，而不是配额。开发人员仍然决定自己能承担多少工作，冲刺目标比达到某个总数更重要。我们关于 敏捷产能规划 的指南解释了如何考虑假期和其他事务。

预测发布

如果发布前还剩 150 点已估算的工作，而速度在 25 到 33 之间，那么这次发布很可能需要 5 到 6 个冲刺 （150 ÷ 33 ≈ 4.5，150 ÷ 25 = 6）。始终给出一个区间，并随着速度和待办事项列表的变化在每个冲刺更新。 速度图 让趋势一目了然。

缺陷、探针（Spike）和未完成的工作

各团队对此的处理方式不同。重要的是选定一条规则并始终如一地执行，这样速度在各冲刺之间才具有可比性。

• 在当前冲刺工作中发现的缺陷 是完成该条目的一部分。不要为它们单独估算点数；在修复之前，该条目就不算完成。
• 来自早期工作或生产环境的缺陷 是新的产品待办事项列表条目。许多团队像对待其他条目一样为它们估算点数，以便工作量体现在速度中；另一些团队则为其预留少量不计点数的余量。只要保持一致，两种做法都可以。
• 探针（Spike） （为降低不确定性而进行的限时研究）通常设定时间盒而不估算点数，或给予一个固定的小数值。其产出是让团队能够估算真正条目的知识。
• 技术债务 工作可以像功能一样估算点数，以便在待办事项列表中公平地争取位置。参见 Scrum 中的技术债.
• 未完成的条目 退回产品待办事项列表。不要在冲刺之间拆分点数；如果剩余工作发生了变化，就重新估算，并在完成时计入。

故事点的常见错误

速度是几项有用的衡量指标之一。

对故事点的批评及替代方案

故事点不乏批评者，其中甚至包括一些推广它的人。常见的担忧包括：团队花太多时间争论数字，管理者将速度当作生产力评分，以及点数给人一种虚假的精确感。这些主要是误用的问题，但确实存在。

如果故事点对您的团队没有帮助，可以考虑以下替代方案：

• 计算条目数。 如果团队将工作拆分为大小大致相似的小条目，那么只需统计每个冲刺完成的条目数，预测效果往往与点数一样好，而且无需召开估算会议。
• 吞吐量与概率预测。 使用历史 吞吐量 和 蒙特卡洛模拟 得出带有置信度的预测，例如“有 85% 的可能在 3 月 14 日前完成”。
• T 恤尺码估算。 粗略的 S/M/L 尺码足以支持路线图和史诗层级的决策。
• #NoEstimates。 一场对详细估算本身提出质疑的运动，主张将工作切分得足够小，并根据流动进行预测。参见 Kanban 计划 ，了解基于流动的团队如何规划。

无论使用哪种方法，《Scrum 指南》的要求都不变：开发人员以有助于规划冲刺、并帮助产品负责人做出决策的方式来估算工作规模。

故事点模板与工具

• 冲刺计划模板：冲刺目标、产能、带故事点的选定条目、负责人和任务。
• 用户故事模板：将故事、验收标准、史诗和估算集中在一处。
• 产品待办事项列表模板：带有价值和估算列的有序待办事项列表。

大多数 Scrum 工具都包含估算字段和速度报告。 Jira 在其 Scrum 看板和报告中内置了故事点估算功能，这也是它深受软件团队欢迎的原因。

本主题的免费模板

浏览所有模板

常见问题