先说结论：大多数团队不是估不准，是把估算当承诺了
2021 年我带过一个 5 人团队，后端 2、前端 2、测试 1，Sprint 固定 2 周，也就是 10 个工作日。 Jira 里故事点用斐波那契：1、2、3、5、8、13。 每周一 10:00 开计划会，原定 60 分钟，实际经常拖到 90 分钟。 Planning Poker 每人一副牌，遇到 8 点以上的卡就开始吵。 那个季度 14 个 Sprint，平均速度 31.6 点，标准差 6.4 点。 听起来挺稳定对吧？但老板问“这个需求下周三能不能上”，没人敢答。 因为速度是点，发布日期是日期，中间隔着发布审批、测试环境排队、代码评审返工。 我后来才反应过来：故事点本来是用来做相对大小对齐的，不是合同。 一旦你拿速度去承诺日期，团队就会开始“养点”——把 8 点拆成 5 张 2 点，总点数从 8 变 10，工作量没变，速度却涨了。 Jira 里改的是数字，改不了人心。 更麻烦的是跨团队比速度，A 团队 40 点，B 团队 25 点，老板觉得 A 更努力，其实 A 的 1 点可能只值 B 的 0.5 点。 这种比较一旦发生，敏捷就变成报表游戏。
我拿 3 种做法做了 8 个月对比，数据不好看但真实
我们没搞大咨询，就是自己试。 第一种是纯 Scrum + 故事点，14 个 Sprint，2 周一个，平均速度 31.6 点，标准差 6.4 点，但发布前置时间中位数 12.6 天。 注意，这个前置时间是从卡进“就绪”到生产可用。 第二种是 Scrumban，保留 2 周回顾，但计划会改成按周拉卡，开发列 WIP 限制 3，评审 2，测试 2。 8 周后，周期时间中位数从 5.4 天降到 4.1 天，可是周吞吐量从 3.2 张降到 2.7 张。 为什么？因为 WIP 限制太紧，测试卡在评审，大家不敢拉新卡。 第三种是纯看板，去掉 Sprint，按周补货，开发 WIP 3，测试 WIP 2，部署列 WIP 1。 10 周后，周期时间中位数 2.8 天，85 分位 6.8 天，周吞吐量 4.5 张。 代价是大需求被拆得很碎，业务方看不到“大里程碑”，有人抱怨像在送快递。 我的独立观点：如果你们团队超过 70% 的需求能在 3 天内完成，别用故事点，用周期时间分布 + 85 分位预测。 故事点只在一种情况下有用：跨职能团队需要快速对齐“相对大小”，而且绝不拿它算绩效、算排名。 其他时候，直接把卡切到 1 到 2 天以内。 切不动，说明需求理解不够，不是估算技术不行。
我们怎么从故事点切到周期时间：5 个具体步骤
第一步，别急着删 Jira 的故事点字段。 我们把它改成只读，新建两个日期字段：开始时间、完成时间。 Jira Automation 规则：状态转为“开发中”记开始时间；状态转为“完成”记完成时间。 完成定义 DoD 写清楚：代码合并、单测通过、部署预发、产品验收，少一条都不算完成。 否则周期时间会骗你。 第二步，画看板列：待办、就绪、开发、评审、测试、待发布、完成。 每列设 WIP：开发 3，评审 2，测试 2，待发布 1。 超过就拉群，不是骂人，是问卡在哪。 第三步，每周三下午 30 分钟看累积流量图，不看燃尽图。 燃尽图只告诉你剩余点数，累积流量图能看出哪一列在堆。 第四步，算 85 分位。 我们攒了 50 张卡，周期时间中位数 2.5 天，85 分位 6.8 天。 给客户承诺用 6.8 天，不用平均数 2.8 天。 第五步，预测用吞吐量，不用点数。 未来 2 周大概能做 9 张，积压 21 张，按 85 分位算，大约 4 到 5 周能清完。 这个答案比“30 点”有用得多。
结果和代价：会议短了，但有人失落
改完 3 个月，我们部署频率从每 2 周 1 次变成每周 4 次，变更失败率从 18% 降到 7%，恢复时间从 4 小时降到 40 分钟。 这些数不是炫耀，是因为发布变小了。 Sprint 计划会原来 90 分钟，后来变成每周补货会 25 分钟。 每日站会原来 18 分钟，后来 9 分钟，因为大家看板上的卡，不挨个汇报。 但我得说代价：有两个人一开始很失落，觉得 Planning Poker 没了，少了仪式感。 还有一个架构优化需求，拆成 11 张卡，每张 1.5 天，业务方看了说“怎么都是小活”。 我们后来加了一个“主题泳道”，不改变周期时间统计，但让业务能看到主线。 所以我不反对 Scrum，也不觉得看板万能。 敏捷不是快，是缩短反馈环。 如果你的组织要预算、要年度规划，故事点可以当沟通货币，但别拿它当合同。 如果你们现在站会超过 15 分钟，计划会超过 1 小时，先别换框架，先测 20 张卡的周期时间中位数和 85 分位。 你们团队站会多少分钟？周期时间中位数多少？可以留言，我拿真实数据回你。
