敏捷开发Scrum工具估算方法：故事点与计划扑克怎么落地

迭代计划会上，同一个需求有人估3天，有人估5天，讨论半小时仍无结论。问题往往不在工具本身，而在估算单位不统一、会议机制不清晰。故事点提供统一尺度，计划扑克促成共识，敏捷开发Scrum工具承接留痕与复用。 三者衔接起来，估算才不至于凭感觉决定。

一、故事点：让估算回到相对规模

1. 故事点不是工时换算表

故事点是一种相对估算单位，用来表示需求在复杂度、工作量、不确定性和风险上的综合规模。 它没有统一的绝对含义。团队可以先选一个熟悉的小需求作为基准，定为2点，再把明显更大的需求定为5点；其他条目与基准比较，不要求按倍数精确换算。点数的价值在相对关系，而不是每个点对应多少小时。Scrum.org.cn也把故事点列为相对估算方法；团队同样可以选择基于时间的绝对估算。《Scrum指南2020》没有规定必须使用故事点，计划扑克也不在Scrum规定的五个正式事件之列。

需要精确排期、成本核算或对外承诺时，工时仍是主要依据；固定总价合同、需要精确审计或对外报价的交付，通常更依赖工时。故事点更适合信息不完整时的内部相对比较。

2. 相对估算为什么更容易达成共识

绝对工时估算看似精确，实际受个人经验、熟悉度和状态影响。相对比较把讨论引向需求本身：它比基准故事大多少，难在哪里，风险在哪里。《Scrum指南2020》明确，实际执行工作的开发人员负责估算规模；产品负责人可以帮助理解取舍，但不能代替团队做最终估算。这既保护估算的专业性，也避免点数被当作任务分配工具。

读图时先看卡片大小，再看筹码数量；两者对应的是相对规模，不是工时。

二、计划扑克：把分歧说清楚，而不是留给会后

1. 会前准备很大程度上决定会议质量

计划扑克由James Grenning在2002年提出，后经Mike Cohn在《敏捷估算与规划》等著作中推广。它的目的不是投票，而是让每个人讲清自己对需求的理解和假设。

• 条目要具备估算条件：描述、验收标准、依赖和未知点提前写清，模糊条目先拆分。
• 准备2～3个熟悉的历史条目作基准，最好覆盖小、中、大三种规模。
• 实际做事的开发人员出牌，产品负责人讲背景，Scrum Master引导；管理者可以旁听，但不宜施压。
• 牌面可用1、2、3、5、8、13、20，另备问号和无穷大；问号表示信息不足，无穷大表示规模过大。

《Scrum指南2020》建议Scrum团队通常为10人或更少；这也可作为控制估算会规模的参考。 人数越多，解释成本通常越高，越容易拖成长时间讨论。

2. 四步流程：讲解、选牌、亮牌、复估

一场计划扑克可按四步推进。

1. 讲解：产品负责人说明目标、边界和验收条件，团队只澄清问题。
2. 独立选牌：每人私下选一张，不互相商量，避免先发言者影响他人判断。
3. 同时亮牌：所有人同时亮牌，让分歧一次性显现。
4. 解释与复估：点数最高和最低的人先说明假设、风险和遗漏，讨论后再投一轮。

两轮后仍明显分歧，不建议取平均值强行收敛。 更合理的动作是拆分条目、补充验收标准，或安排限定时间的技术验证。平均值容易让团队误以为估算很精确，拆分才能看清不确定性。

会议结束前要留下每个条目的处理结果：最终点数，或拆分、验证决定，以及影响点数的关键假设。 缺少这些记录，点数很难在迭代中复用。

读图看四步是否完整；真正影响质量的通常是亮牌后的解释，而不是牌面数字。

3. 远程团队怎么开

远程计划扑克不需要复杂工具。共享估算牌、同时翻牌、在文档里记录假设，就能保留核心机制。会前发需求说明，会上留几分钟静默阅读；跨时区团队可先异步预读，再在重叠时间亮牌。远程最易丢失的不是牌面，而是解释分歧的过程，关键假设要同步写进条目。

三、从点数到迭代计划：让估算进入工具流程

1. 先看历史完成速度，再谈本次范围

故事点要和完成情况结合，才能用于计划预测。团队可以统计每个迭代达到完成标准的条目点数，得到历史完成速度，再用最近几个迭代的平均值或区间预测本次可承载的范围。新团队没有历史数据时，可先选一组保守的候选条目，按任务拆分和人员可用时间核对可行性；同时从候选条目中选1～2个作为基准故事，建立点数基线，首轮结束后再用实际完成点数校准。不要把工时直接换算成点数。

历史完成速度只用于团队内部预测，不宜作为跨团队排名，也不建议直接用于个人绩效考核。

2. 在敏捷开发Scrum工具中记录估算流程

估算不能只停在一次会议。团队应把点数、关键假设和拆分结论回写到需求条目或迭代说明中，而不是只留在会议记录里。

禅道项目管理软件提供Scrum项目管理模型，支持迭代或冲刺管理，需求、任务、Bug、测试用例和燃尽图可以在同一项目中关联。团队可在禅道Scrum项目管理中组织迭代，也可参考Scrum项目使用说明配置Scrum项目与迭代。工具的作用是让估算依据、范围和结果可追溯，而不是替团队做估算。

读图看点数如何从需求池进入迭代计划，再进入评审与回顾。

3. 估算结果的使用边界

故事点更适合做范围预测，不宜直接承诺精确交付日期；更适合观察趋势，不宜用于比较个人。需求变更时，应重新评估受影响条目，而不是沿用旧点数掩盖范围变化。估算不必一次算准，而应随信息增加不断修正。

四、四个常见误区与校准办法

1. 高频误区

难点不在方法，而在团队是否愿意让实际做事的开发人员来估算。

2. 用回顾会校准，而不是用考核校准

每隔几个迭代，团队可以回看估算与实际完成的差异：是需求理解不足、依赖未识别，还是完成标准被放宽。校准的对象是估算依据和协作过程，不是某个人估得准不准。 点数一旦与绩效挂钩，成员容易倾向报大或报小，数据也会失真。

当这些动作稳定下来，敏捷开发Scrum工具里的估算记录才会真正可复用。

五、常见问题

1. 产品负责人可以参与计划扑克出牌吗？

产品负责人应讲清需求、验收标准和取舍，不代替开发人员出牌；如果本人也承担开发任务，可以作为开发人员参与估算。

2. Bug修复要不要估算故事点？

如果Bug被选入迭代，通常需要估算。可按修复、回归和验证的工作量估算；严重程度影响优先级，但不直接等于故事点。

3. 需求拆到多小才适合估算？

如果团队无法用几句话讲清验收标准，或一个条目难以在一个迭代内完成，就先拆分；拆到能在一轮讨论中判断规模为止。