故事点换成工时:用团队速度做敏捷估算

每次排期会,总有人在白板前问同一句话:「这个 13 点的故事,到底是几天?」然后房间里就开始各执一词。有人按「1 点 4 小时」硬算,有人凭感觉拍,最后排出来的计划往往离实际差得离谱。问题不在于谁算得准,而在于把故事点当成了一把固定刻度的尺子。它从来不是。

故事点为什么不等于固定小时

故事点被发明出来,恰恰是因为人对小时的估算不可靠。一个开发看到一张工单说「这个两小时搞定」,真做起来撞上一个没料到的依赖,变成两天,这种事天天发生。故事点改成相对估算:不问「这要几小时」,而问「这比那个我们已经做过的 3 点故事难多少」。它衡量的是规模、复杂度和不确定性的综合体感,不是钟表上的时间。

正因为这样,任何写死「1 点 = 4 小时」的对照表都是错的。同样是 5 点,A 团队可能要 30 小时,B 团队可能要 50 小时,因为两队的人手、专注时间、协作开销都不一样。换算系数不是宇宙常数,它是你们团队自己跑出来的数。

按团队历史速度换算,不是按固定换算率

真正靠谱的换算只有一种来源:你们团队的速度(velocity)。把最近 3 到 5 个 sprint 里真正做完(到 done)的故事点加起来取平均,这就是速度。注意只算做完的,把跨 sprint 拖着的半成品也算进去,速度会虚高,后面每次换算都偏乐观。

有了速度,再加上一个 sprint 几个工作日、团队几个人、每人每天真正能专注几个小时,就能用「sprint 总容量 ÷ 速度」推导出你们自己的「每点工时」。这个数才是你们的换算系数,而且每隔几个 sprint 随速度变化要重新推一次。我自己带组时踩过的坑就是图省事用了半年前的旧系数,结果新人多了、会议也多了,旧系数早就不准了,排出来的计划全线乐观。

顺便提一句,每天专注小时数默认 6 而不是 8 是有道理的。站会、评审、回顾、帮同事看代码、群消息,每天稳定吃掉 2 到 3 小时。按 8 算容量会虚高约三成,答应出去的排期全偏激进。

一个真实换算例子

假设你的团队 5 个人,两周一个 sprint(10 个工作日),每人每天有效专注 6 小时,历史速度平均每个 sprint 完成 20 点。先算容量:5 人 × 10 天 × 6 小时 = 300 人时。每点工时 = 300 ÷ 20 = 15 人时。

现在来看那个「5 个点大约对应多少天」的问题。5 点 × 15 = 75 人时。全队 5 个人一起上,75 ÷ 5 = 15 人时每人,折合每人约 2.5 个工作日;如果只算它占整个 sprint 容量的比例,75 ÷ 300 = 0.25,也就是四分之一个 sprint,约 2.5 个团队工作日。一句话:这个 5 点的活,大概是团队两三天的事。把它丢进 故事点工时换算器 里,填好你们自己的速度档案,这些数一秒就出来,还能双向算,反过来给你一个时间预算也能算出大概能装下多少点。

Sprint 规划里怎么用

换算最大的用处是排期会上的体检。比方说团队试探性拉进了 24 点,但历史速度只有 20。把 24 填进档案,工具显示这相当于 1.2 个 sprint 的容量,超载 20% 一目了然,不需要任何人先站出来唱反调。要么砍掉 4 个点,要么大家清醒地接受会有遗留,而不是会后才发现做不完。

它也是和老板、客户沟通的翻译器。路线图评审上人家问的都是「几周能上」,不是「几点」。一个 40 点的 epic,按上面的档案换算约 2 个 sprint,你就能拿着完整数字链说「下下个 sprint 初能上」,而不是含糊其辞。开会这件事本身也有成本,排期前不妨用 会议成本计算器 估一下一屋子人开两小时到底烧掉多少钱,会逼着大家把估算会开得更利落。

谨慎使用:它是翻译器不是承诺

最后必须强调一句。换算结果绝对不能当成单张工单的承诺。每点工时是团队平均值,一个 5 点的故事实际花掉换算时间的一半或两倍都正常,这种方差正是团队用点数而不用小时估算的原因。

换算只在聚合层面才可靠。放到一个 sprint、一个季度的尺度上,超的和省的会互相抵消,这也是为什么基于速度的预测能撑住路线图,而按单张工单承诺小时数总会翻车。所以这套数字用在排期讨论和容量核对上,单张工单继续用点。把「这是个 13」翻译成「大概要全队一周」,让老板听懂,但别把那一周钉死成 deadline。守住这条边界,故事点换算才是帮手而不是新的坑。

---

Made by Toolora · Updated 2026-06-13