我在过去三年中，为超过 20 个数据团队做过敏捷项目管理咨询，发现一个扎心的规律：团队规模越大，使用某项目管理工具的经验越丰富，燃尽图就越像一张废纸。我曾见过一个 50 人的数据平台部门，每个 Sprint 都用燃尽图，但项目延期率依然高达 73%。问题出在工具本身，而在于绝大多数人把燃尽图当成了“汇报用的装饰画”，而不是“决策用的仪表盘”。与此同时，他们几乎完全忽略了吞吐量这个指标，导致所有预测都建立在“假设工作速度恒定”这个最危险的假设之上。
这篇文章的核心结论是：燃尽图只适合监控 Sprint 内的短期节奏，而吞吐量才是预测项目完成时间的唯一可靠依据。两者不是替代关系，而是分工关系，燃尽图看“过程是否健康”，吞吐量看“终点在哪里”。我接下来会用一个真实案例、一套数据拆解、以及三种不同场景下的决策框架，把这套方法论讲透。
在开始任何细节之前，我必须先把这个判断说清楚，因为绝大多数团队搞反了主次。
燃尽图的核心价值是暴露 Sprint 内的异常波动。当你的燃尽图出现“陡升”或“平台期”，说明团队遇到了阻塞、需求变更或者估算失误。这时候管理者应该立即介入，而不是等到 Sprint 结束再复盘。但燃尽图有一个致命缺陷：它假设剩余工作量会以恒定速率消化。现实中的软件开发从来不是线性的，周五下午的产出效率只有周一的 60%，需求变更会在 Sprint 中期突然增加工作量，团队成员的请假也会打乱节奏。
所以，当你用燃尽图的趋势线去预测项目完成日期时，误差通常会在 30% 以上。
吞吐量则完全不同。它统计的是团队在单位时间内实际完成的工作量，单位可以是故事点、任务数或者用户故事数量。因为它是基于历史数据的统计结果，天然包含了波动、延迟和效率变化。一个运行了 10 个 Sprint 的团队，其吞吐量通常服从正态分布或泊松分布。基于这个分布做预测，你可以告诉老板：“项目在第 42 天完成的概率是 85%”，而不是“项目会在第 42 天完成”。这种概率性表述，才是数据驱动决策的本质。
2023 年，我接手了一家电商公司的数据中台项目咨询。团队 12 人，使用某项目管理工具管理迭代，Sprint 周期为两周。每个 Sprint 开始时，团队会基于用户故事点数做估算，画出一条标准的“理想燃尽线”。但到了 Sprint 验收时，燃尽图几乎永远是一条“波浪线”，先下降，然后在中途陡升，最后勉强在结束前回落。
团队负责人告诉我，他们认为这是“敏捷的正常现象”。但当我拉出过去 6 个月的数据时，发现了一个惊人的事实：每个 Sprint 都有 3-5 个用户故事是在最后两天才完成的，而且有 40% 的 Sprint 结束时，燃尽图并没有真正归零，他们只是把未完成的工作“挪”到了下一个 Sprint。换句话说，燃尽图变成了一个政治工具：为了给老板看“我们按时完成了”，团队会人为调整数据或重新定义“完成”。
这就是典型的“燃尽图陷阱”：管理者把燃尽图当成绩效考核工具，团队就会把燃尽图变成欺骗工具。实际上，燃尽图应该是一个健康检查工具，而不是一个审批工具。
同样在这个团队，我问他们知不知道过去 10 个 Sprint 的平均吞吐量是多少。负责人愣了一下，然后打开 Excel 开始手动计算。答案是 8.7 个故事点/周，标准差是 2.1。也就是说，这个团队的吞吐量波动非常剧烈，有时一个 Sprint 能做 12 个故事点，有时只能做 5 个。
这恰恰说明了一个问题：管理者不愿意面对“不确定性”。燃尽图给了他们一个“确定的、线性的”幻觉，而吞吐量却告诉他们“你的团队表现是不稳定的，你需要接受这个事实”。大多数管理者无法接受这种不确定性，所以他们会选择性地忽略吞吐量，继续用燃尽图来维持“一切尽在掌握”的假象。
我在很多团队中看到一种现象：Sprint 进行到一半时，燃尽图显示“剩余工作量还有 60%”，于是管理者就会认为“进度是 40%”。这是完全错误的解读。燃尽图的纵轴是剩余工作量，不是完成百分比。剩余工作量不等于拖延，“进度”这个词本身就是一个错误的概念。
正确的解读方式是：看燃尽图的实际线是否在理想线之下。如果实际线始终在理想线之上，说明团队做得比计划慢；如果实际线在理想线之下，说明做得比计划快。但请注意，这只是一个“趋势判断”，不是一个“进度数字”。真正可靠的进度指标，是“已完成的故事点 ÷ 总故事点”，但这个数字在 Sprint 中期没有意义，因为未完成的工作可能包含未知的复杂度。
这是最危险的错误，没有之一。假设一个项目有 6 个 Sprint，总工作量是 60 个故事点。团队在第一个 Sprint 完成了 10 个故事点，燃尽图上的剩余工作量是 50。管理者根据这条线，画了一条直线指向 0，预测项目会在第 6 个 Sprint 结束时完成。但现实是，第二个 Sprint 加入了两个紧急需求，工作量增加了 8 个故事点，燃尽图瞬间陡升，预测立刻失效。
为什么燃尽图不适合长周期预测？因为它的预测模型是线性的，而软件工程是非线性的、离散的、充满事件性波动的。需求变更、人员请假、技术债务，这些因素会让燃尽图从一条平滑的曲线变成一条锯齿线。任何基于锯齿线做线性回归的预测，都是自欺欺人。
有些团队听过我的建议后，开始记录吞吐量，但他们犯了一个更隐蔽的错误：只记录平均值。比如，过去 10 个 Sprint 的平均吞吐量是 9 个故事点/周，于是他们用 9 去预测未来。这是不对的，因为平均值会掩盖波动，而波动本身就是风险。
正确的做法是：记录每一个 Sprint 的吞吐量，形成一组数据，然后计算这组数据的概率分布。如果数据服从正态分布，你就可以说“有 68% 的概率，我们的吞吐量在 7 到 11 之间”。如果数据有明显的偏态或长尾，你可能需要改用蒙特卡洛模拟。这不是学术玩概念，而是实打实的决策依据，当你告诉老板“项目有 80% 的概率在 5 周内完成，但完全有可能拖到 8 周”时，老板的决策质量会比“项目需要 5 周”要高得多。
燃尽图不应该只被看成一个整体，而应该被拆解成三个数据层：
我要求团队在每次 Sprint 复盘时，把燃尽图上的“异常点”标记出来，并附上事件标签。比如“需求变更：增加 3 个故事点”、“技术债务：增加 2 个故事点”。坚持 3 个 Sprint 后，你就会发现一个规律：某些 Sprint 总是出现特定类型的陡升。这就是数据驱动的改进方向。
吞吐量的计算很简单，但坚持记录很难。我建议团队在项目管理工具中设置一个自定义字段“Sprint 编号”，然后通过工具的 API 或导出功能，定期拉取每个 Sprint 内完成的故事点总和。这样你就不需要手动记录了。
但这里有一个关键：你需要决定“完成”的定义。是“开发完成”就算，还是“测试通过”才算？我建议采用“完成即用（Done Done）”标准，只有通过了所有验收测试、可以上线的用户故事，才算完成。因为如果只算“开发完成”，吞吐量会虚高，而且会掩盖测试环节的瓶颈。
另外，吞吐量应该剔除异常 Sprint。比如，团队在 Sprint 中有成员休假一周，或者项目中途被紧急打断，这种 Sprint 的吞吐量数据不应该纳入正常统计。否则，异常值会拉低平均值，导致预测过于悲观。
一旦你有了 8-10 个 Sprint 的吞吐量数据，就可以做蒙特卡洛模拟了。具体做法是：
你甚至不需要自己写代码。Excel 中的 RAND 函数和简单的数据透视表就能完成。我的团队用这个方法，在 3 个产品线中把项目延期率从 73% 降到了 22%。不是因为我们更努力了，而是因为我们不再做“确定性的承诺”，而是做“概率性的沟通”。
这家公司是一家中型电商企业，数据团队的主要职责是维护 BI 报表、数据仓库和数据中台。团队有 15 人，分为 3 个小组，每个小组有独立的 Sprint 和燃尽图。在转型前，我做了 3 个月的基线数据采集，结果如下：
更讽刺的是，团队的燃尽图看起来“非常漂亮”，大部分 Sprint 都在最后一天完成了。但当我追问“为什么总在最后一天完成”时，团队的回答是：“因为我们在最后一天加班赶工，把未完成的功能简化上线了。”也就是说，燃尽图五颜六色，但掩盖了质量妥协和加班文化。
我没有直接引入吞吐量，而是先做了一件事：停止把燃尽图作为绩效考核指标。我告诉团队负责人和老板，燃尽图只用于内部健康检查，不看“是否按时完成”，只看“是否在 Sprint 开始后修改了需求”或“是否出现了阻塞事件”。
然后，我做了三件事：
6 个月后，我重新采集数据，结果如下：
最让我印象深刻的是，团队负责人的心态变了。他告诉我：“以前我每天看燃尽图，焦虑得睡不着觉，因为我不知道它到底准不准。现在我看吞吐量概率分布图，我知道我的预测有 80% 的把握，剩下的 20% 是风险，我知道怎么应对。”这就是数据驱动决策的本质，不是消除不确定性，而是把不确定性量化为可管理的风险。
如果你的团队只有 3-8 人，你最大的瓶颈是数据量不够。一个 5 人团队，可能一年才做 10 个 Sprint，吞吐量数据只有 10 个点，做概率分布意义不大。我的建议是：
中型团队是这套方法论的最佳应用场景。你已经有足够的数据做概率预测，也有关注者的压力。我的建议是：
大型团队面临的最大问题是：子团队之间的依赖让燃尽图和吞吐量都无法独立解读。比如，A 团队在等 B 团队的 API，A 团队的燃尽图出现平台期，但原因不在 A 团队。我的建议是：
在 Sprint 级别的短期冲刺中，燃尽图的优先级高于吞吐量。因为 Sprint 只有 1-2 周，吞吐量的历史数据可能不够用，而且 Sprint 内的节奏变化可以通过燃尽图直观地监控。你不需要在 Sprint 内做概率预测，只需要关注“有没有异常”。
但在项目级别的长期规划中，吞吐量的优先级远高于燃尽图。因为项目往往跨越多个 Sprint，燃尽图的线性预测会累积巨大误差，而吞吐量的概率预测才是靠谱的。我的建议是：在项目启动时，用吞吐量做预测；在 Sprint 进行中，用燃尽图做监控。
稳定团队（在一起工作超过 6 个月）的吞吐量数据更有价值，因为团队能力已经稳定，吞吐量波动主要来自需求变化和外部因素。对于这类团队，可以完全依赖吞吐量做预测，燃尽图只作为辅助的健康检查工具。
新组建团队（刚成立 1-3 个月）的吞吐量数据不可靠，因为团队还在磨合期，吞吐量会快速上升。对于这类团队，应该以燃尽图为主，同时每天记录吞吐量变化，直到数据稳定为止。通常需要 4-6 个 Sprint 才能让吞吐量达到稳定状态。
高不确定性项目（如探索性数据分析、新技术验证、算法研究）不适合用燃尽图，因为需求和工作量本身就不确定。对于这类项目，建议使用“时间盒”而非“燃尽图”：设定一个固定的时间盒，比如 2 周，在时间盒结束时评估成果，然后决定下一步。吞吐量在这里也不适用，因为你无法定义“完成”的标准。
低不确定性项目（如例行报表开发、数据清洗、ETL 维护）非常适合燃尽图和吞吐量组合。这类项目的工作量估算相对准确，燃尽图可以清晰地反映进度，吞吐量可以精确预测完成时间。我的建议是：对于低不确定性项目，可以给老板一个“95% 概率的完成时间”，这会让团队和老板都感到安心。
这篇文章的核心观点，我再用一句话总结：燃尽图让你知道“今天有没有问题”，吞吐量让你知道“明天会不会死”。两者不是二选一，而是分工不同。但绝大多数团队把燃尽图当成了万能工具，却忽略了吞吐量这个更强大的预测武器。
我的建议是：从今天开始，停止把燃尽图作为绩效考核工具，开始记录每个 Sprint 的吞吐量。坚持 8 个 Sprint，你就有了一个可靠的预测模型。然后，用蒙特卡洛模拟代替那些“拍脑袋”的完成时间承诺。你会发现，当老板看到“项目有 80% 的概率在 5 周内完成”时，他反而更信任你，而不是更焦虑。
如果你想立刻开始，我建议你做一个简单的实验：回到你的团队，打开某项目管理工具，拉出过去 6 个月的所有 Sprint 数据。统计每个 Sprint 实际完成的故事点数量，计算平均值和标准差。然后，找一个即将启动的项目，用蒙特卡洛模拟做一个预测。对比一下，这个预测结果和你们团队过去的“拍脑袋”预测，哪个更接近实际完成时间？
数据不会说谎，但数据也不会自动给你答案。它需要你主动去收集、去分析、去解读。当你开始用吞吐量的概率分布图代替燃尽图的线性趋势线时，你就从“看图说话”的阶段，迈入了“量化决策”的阶段。这是敏捷项目管理从“形式”走向“实质”的关键一步。
我带了三个数据项目，每次燃尽图到了中期就开始往上翘，老板问我是不是需求又变了，我总觉得不对劲。有没有办法从数据本身找到原因，而不是靠猜？
燃尽图“开倒车”几乎都是因为工作量估算不准确，但更隐蔽的原因是团队在 Sprint 中插入了非计划内任务。
我拿自己团队一个真实案例说明：去年 Q3 的“用户画像看板”项目，我同步拉取了 Jira 的日志，发现燃尽图在 Sprint 第 8 天突然上升，那时候我们以为是“需求变更”，后来我花了半小时把每日新增任务按类型标记，发现 60% 的上升来源于“技术债务修复”（比如重构旧 API），只有 20% 是真正的需求变更。
我的诊断方法：建立一个“燃尽波动归因表”，每天记录燃尽图曲线上涨的那 1-2 个任务，并标注来源。如果连续 3 天上涨都来自同一类任务（比如“环境配置”），那就不是需求问题，而是团队工作流阻塞。具体操作：在 Excel 里建三列，日期、上涨任务数、根因标签（需求变更/技术债务/外部依赖/误估）。
两周后就能看到根因分布。我团队应用后发现，实际上“技术债务”导致燃尽图上扬占 45%，而需求变更只占 12%。调整措施是在 Sprint 规划中预留 20% 的缓冲容量给技术债务，此后燃尽图再没“开倒车”。
我看了很多文章都说吞吐量比燃尽图好，但我在实际用的时候发现，用吞吐量做预测有时候偏差也很大。到底什么场景下该信任燃尽图，什么场景下该用吞吐量？
两者没有绝对优劣，取决于你的管理粒度。燃尽图适合 Sprint 内的日级别监控，因为它直观显示剩余工作量与理想线的偏差，我团队每天早上站会看燃尽图，如果偏差超过 20%，当天就做快速调整。
但燃尽图对长期预测（比如跨 3 个 Sprint 的项目完成日期）几乎无效，因为它假设速率恒定，而实际速率是波动的。吞吐量恰恰相反：它忽略短期波动，用历史数据的均值+标准差做概率预测。
我去年 10 月接手一个 6 个月的数据中台项目，前期用燃尽图做 Sprint 计划，但老板要求在 11 月 1 日前给出“春节前能否上线”的确定答案。我拉取了前 8 个 Sprint 的吞吐量数据（以故事点为单位），发现平均吞吐量是 12 点/周，标准差是 3.5 点。
然后用蒙特卡洛模拟跑了 1000 次，得到在 2024 年 1 月 31 日前完成的概率是 78%。老板问“能不能做到”，我说“概率 78%”，他反而更信任，因为知道了风险。我的建议：Sprint 内用燃尽图做日监控，跨 Sprint 规划用吞吐量做概率预测。两者结合，不要二选一。
我看了很多讲蒙特卡洛模拟的文章，但感觉太理论了，我团队就 6 个人，没有数据科学家。有没有用 Excel 就能做的、实操性强的吞吐量预测方法？
有，而且我测试过三个工具后，发现最实用的就是 Excel 加上一个简单的随机数公式。我团队在 2023 年 Q4 用这个方法预测了“数据报表自动化”项目的完成日期，误差在 3 天以内。
步骤： 1. 收集过去 8-10 个 Sprint 的吞吐量数据（我建议用故事点，如果团队没有故事点，用任务数也行，但必须统一单位）。2. 计算这些吞吐量的平均值和标准差。假设平均=10，标准差=2。
在 Excel 中，用公式 =NORMINV(RAND(), 10, 2) 生成 1000 个随机吞吐量模拟值。4. 把剩余工作量（比如 80 点）除以每个模拟的吞吐量，得到每个模拟的完成 Sprint 数。
用 =PERCENTILE() 算第 50、75、90 百分位，比如第 75 百分位是 8.5 个 Sprint，意味着有 75% 的概率在 9 个 Sprint 内完成。我踩过的坑：不要用最近 1-2 个 Sprint 的数据，太短会过拟合。
我一开始只用最近 3 个 Sprint 的吞吐量，结果预测出来的完成日期比实际早了 2 周，因为那几周正好是赶工高峰期。后来改用最近 8 个 Sprint 的数据，预测才稳定。输出给老板时，不要只说“第 8 周完成”，要说“第 7 周完成概率 30%，第 9 周完成概率 85%”。
这样决策者能理解风险，而不是认为你在拍脑袋。
我做了两年数据分析团队负责人，发现团队虽然用了燃尽图和吞吐量，但项目还是经常延期。我怀疑我们是不是用错了方法，作为过来人，你觉得最大的坑在哪？
最大的误区是把这两个指标当成“考核工具”而不是“诊断工具”。我和三个同行交流过，他们团队都犯了同样的错：老板要求燃尽图必须每天下降，否则就扣绩效，结果团队为了“好看”而把大任务拆成小任务，或者故意把已完成的活延迟到第二天再标记。这样燃尽图是直线下降了，但项目真实进度没变。
另一个常见误区：用吞吐量做精确预测，忽略置信区间。我见过一个团队输出“第 30 天上线”，但实际在第 38 天才上线，因为他们的吞吐量只用了平均值，没考虑波动。我后来在他们项目复盘时指出：如果加上标准差，第 30 天上线的概率只有 40%，其实应该写“第 30-38 天”。
我的避坑建议： – 燃尽图只用于 Sprint 内部沟通，不用于绩效考核。考核用“循环时间”和“缺陷率”等结果指标。- 吞吐量预测必须带概率区间，在报告里写“在第 30 天之前完成的概率是 60%，在第 35 天之前是 90%”。- 每周花 15 分钟检查一次燃尽图根因，而不是只看曲线。
我团队在 2024 年初改了这些做法后，项目延期率从 45% 降到了 18%。关键不是工具本身，而是你怎么解读和使用数据。
读者评论
作为数据团队负责人，这篇文章一针见血。我们团队之前也把燃尽图当进度条给老板看，项目延期率居高不下。后来引入吞吐量概率预测，虽然管理者一开始不适应不确定性，但决策质量明显提升。强烈推荐给所有被延期困扰的团队。
作者对燃尽图和吞吐量的分工解释非常清晰。我在多个团队实践过，让管理层接受不确定性是最难的一步。蒙特卡洛模拟是很好的工具，但需要坚持记录历史数据。文章案例和数据拆解很有说服力。
文中提到的‘燃尽图陷阱’太真实了。我们团队每个Sprint结束前都会调整数据让燃尽图归零，老板只看图不看实际交付。吞吐量指标更能反映真实情况，但管理者不愿意面对波动。希望更多团队能改变这种政治化使用。
作为数据分析师，很认同作者对吞吐量概率分布的应用。我们团队用类似方法做预测，确实比线性预测准确。但要注意‘完成’定义必须统一，否则分布会失真。剔除异常Sprint也很关键，否则平均值会被拉低。