迭代燃尽图由两条线构成：理想燃尽线按迭代总工作量和天数均匀下降，实际剩余线按每天真正完成的工作扣减。本文用一份虚构的两周迭代示例，完整走一遍从规划、逐日记录到评审解读的填写过程，说明每个点怎么记、范围调整怎么处理，以及曲线偏差该如何解释。
要点总览（TL;DR）
- 迭代燃尽图由理想燃尽线和实际剩余线构成：理想线按总工作量与迭代天数均匀下降，实际线按每天真正完成的工作扣减。
- 示例设定为6人团队、10个工作日、12个工作项共60点，理想线每天下降6点，逐日记录剩余值即可画出完整曲线。
- 迭代中途新增需求时，在变更日单独标注并重算剩余天数的理想线，历史实际值保持不变，保证曲线可追溯。
- 剩余量口径（故事点、工时或任务数）要在整个迭代内统一，理想线起点确定后只在范围变更时调整。
- 燃尽图只反映剩余量趋势，不反映质量与价值，范围频繁变动或跨团队比较时解读会失真，需配合工作项状态、阻塞记录和测试数据。
示例要展示什么：一张能读懂的燃尽图
本示例的目标是把一张迭代燃尽图从空白填到可解读：先确定迭代目标和团队容量，把Sprint Backlog拆成带估算的工作项，算出理想燃尽线，再逐日记录剩余工作量，最后在评审时用曲线说明进度和偏差来源。读者照着走一遍，就能在自己的迭代里复现同样的填写动作。
以下情景均为虚构演示，不对应任何真实团队或客户项目。设定为：一个6人开发团队，迭代长度两周共10个工作日，Sprint Backlog包含12个工作项，估算单位使用故事点，迭代总工作量为60点。这些数字只用于演示计算过程，不代表行业基准或推荐值。
示例围绕三个问题展开：两条线怎么画，每天的点怎么记，曲线偏离理想线时怎么解释。第一个问题涉及起点、终点和每日下降幅度；第二个问题涉及记录时点、记录人和剩余量口径；第三个问题涉及范围调整、阻塞和估算偏差的区分。三个问题对应填写流程的三个阶段，后文按顺序展开。
完整示例：两周迭代的燃尽图填写过程
迭代目标与容量假设
示例迭代的目标是完成“订单查询页改版”这一组功能，包含页面重构、筛选条件、结果列表和导出四个部分。团队按历史速度假设本迭代可承载60点，6名成员中2人参与前端、2人参与后端、1人负责测试、1人兼顾设计与协调。容量假设写进迭代计划，作为理想燃尽线起点的依据。
Sprint Backlog工作项与估算值
12个工作项及估算如下表。估算在计划会上由团队共同确认，单位统一为故事点。
| 编号 | 工作项 | 估算（点） |
|---|---|---|
| 1 | 页面框架重构 | 8 |
| 2 | 筛选条件组件 | 5 |
| 3 | 结果列表分页 | 5 |
| 4 | 导出接口 | 8 |
| 5 | 查询性能优化 | 5 |
| 6 | 空状态与错误提示 | 3 |
| 7 | 移动端适配 | 5 |
| 8 | 接口联调 | 5 |
| 9 | 测试用例编写 | 3 |
| 10 | 功能测试 | 5 |
| 11 | 回归测试 | 3 |
| 12 | 文档与演示准备 | 5 |
| 合计 | 60 | |
理想燃尽线的计算
理想线从第0个工作日的60点出发，到第10个工作日结束时降到0点，每天均匀下降6点。各日理想剩余值为：第0日60、第1日54、第2日48、第3日42、第4日36、第5日30、第6日24、第7日18、第8日12、第9日6、第10日0。这条线只由总工作量和迭代天数决定，迭代期间不因实际进度变化而调整，除非范围发生变更。
逐日剩余工作量记录表
每天站会后由Scrum Master更新剩余值，口径为“尚未完成工作项的估算之和”，已完成的工作项整项扣除。示例记录如下：
| 工作日 | 当日完成 | 实际剩余（点） | 理想剩余（点） |
|---|---|---|---|
| 第0日 | — | 60 | 60 |
| 第1日 | 工作项6（3点） | 57 | 54 |
| 第2日 | 工作项2（5点） | 52 | 48 |
| 第3日 | 工作项9（3点） | 49 | 42 |
| 第4日 | 工作项1（8点） | 41 | 36 |
| 第5日 | 工作项3（5点） | 36 | 30 |
| 第6日 | 工作项5（5点） | 31 | 24 |
| 第7日 | 工作项8（5点）、工作项11（3点） | 23 | 18 |
| 第8日 | 工作项4（8点） | 15 | 12 |
| 第9日 | 工作项7（5点） | 10 | 6 |
| 第10日 | 工作项10（5点）、工作项12（5点） | 0 | 0 |
范围调整的处理与理想线重算
示例中第6日出现一次范围调整：业务方要求增加“批量导出”需求，估算5点。处理方式是当天在图上单独标注这次新增，把迭代总工作量从60点改为65点，并从第6日起重算理想线：剩余4个工作日（第7至第10日）需从35点降到0点，每日约下降8.75点，第6日理想剩余调整为35、第7日26.25、第8日17.5、第9日8.75、第10日0。历史日期的实际剩余值保持不变，只在调整日加一条竖线或注释，说明曲线抬升来自范围变化而非进度倒退。
最终燃尽图形态与评审解读
按上述数据绘制，实际线在前5日略高于理想线，差距在3至7点之间，说明完成速度略慢于计划；第6日因新增需求出现一次向上跳变；第7、8日连续完成两个较大工作项，实际线快速下探并接近重算后的理想线；最后两日收尾至0点。评审时按三段解读：前期偏慢的原因是工作项1的重构比预估复杂，中期跳变来自范围新增，后期收敛说明团队在调整后恢复了节奏。这样的解读把曲线形态与具体事件对应起来，避免只报“进度正常”或“进度落后”的结论。
每日更新剩余值时，如果团队使用ONES，可以在迭代工作项中维护状态与剩余估算，站会后由负责人更新完成情况，燃尽数据随工作项状态变化同步反映，减少手工汇总表格的重复劳动。这一衔接只解决记录与汇总的动作，曲线如何解读仍取决于团队对偏差来源的判断。
逐项解释：每个字段和每个点为什么这样填
剩余工作量的口径需要在整个迭代内保持一致。故事点适合估算相对规模、团队已形成稳定速度的情况；工时适合需要对外承诺交付时间或跨团队协调的场景；任务数适合工作项粒度接近、估算成本低的团队。三种口径不能混用，否则实际线的下降幅度会失真。示例选择故事点，是因为工作项规模差异较大，用点数比用任务数更能反映真实工作量。
理想线的起点是迭代计划确认后的总工作量，终点固定为迭代最后一天的0点，中间按工作日均分。起点一旦确定，迭代期间只在范围变更时调整；如果每天都按最新剩余量重画理想线，理想线就失去了参照意义，曲线对比也无从谈起。
每日更新时点建议固定在站会之后，此时团队对昨日完成情况已达成一致。更新人通常是Scrum Master或迭代负责人，职责是汇总而非替成员判断完成与否；工作项是否完成由承担者确认。更新动作要记录剩余值本身，而不是只记录“完成了几个”，否则无法还原曲线。
实际线高于理想线，常见原因包括估算偏乐观、出现阻塞、成员被临时抽调、依赖方交付延迟；实际线低于理想线，可能是估算偏保守、工作项拆分过细导致提前完成，也可能是完成标准放宽。判断原因时要回到具体工作项，而不是从曲线形状反推结论。
范围调整单独标注而不直接改历史数据，是为了保留曲线的可追溯性。如果新增需求直接并入总量并重画全部历史点，读者会看到一条从未偏离过的曲线，既无法解释当时的进度压力，也无法在回顾时判断估算和容量假设是否合理。标注加重新计算理想线，既反映新范围，又保留变更发生的时间点。
可迁移规律：换一个迭代怎么复用这套填法
换迭代复用时，先固定估算单位再开始记录。如果新迭代改用工时，理想线的起点和每日下降都按工时计算，历史迭代的故事点数据不参与对比；同一团队连续多个迭代建议沿用同一单位，便于观察速度趋势。
迭代中途插入需求，按示例的做法处理：评估新增工作量、在图上标注变更日、重算剩余天数的理想线、历史实际值不动。若插入需求导致原定目标无法完成，应在迭代内与相关方确认取舍，把被移出的工作项明确记录，而不是让它们悄悄留在Backlog里影响剩余量口径。
迭代结束时未完成的工作项，重新评估后再决定是否进入下一个迭代，不默认按原点数结转。重新评估可以发现估算偏差，也避免把上一迭代的乐观估算带入新迭代，让新迭代的理想线起点失真。
燃尽图与日常节奏的衔接体现在两个动作：站会上对照实际线与理想线的差距，确认当天要推进的工作项；评审和回顾时用曲线分段解释偏差，把范围变更、阻塞和估算问题分别归因。以下清单可用于每个迭代的填写自查：
- 迭代开始时确认总工作量、迭代天数和估算单位，并写入计划记录。
- 理想线起点、终点和每日下降值在计划会上公开计算一次。
- 每日站会后更新剩余值，记录更新人和更新时间。
- 范围变更当天标注，并重算剩余天数的理想线。
- 迭代结束时对未完成工作项重新评估，记录处理结果。
- 评审时按时间段解释曲线偏差，对应到具体工作项或事件。
适用边界：燃尽图解释不了什么
燃尽图反映的是剩余工作量的变化趋势，不反映工作质量和交付价值。剩余量降到0，只说明计划内的工作项被标记完成，完成标准是否达标、功能是否满足用户需求，需要测试结果和评审反馈来判断。把曲线归零当作迭代成功的唯一证据，容易掩盖质量问题。
范围频繁变动时，曲线解读会明显失真。每次变更都重算理想线，图上会出现多条分段理想线和多次跳变，实际线的走势更多反映变更节奏而非团队产能。这种情况下，应同时记录变更清单，把曲线与变更记录对照阅读。
不同团队、不同工作项粒度之间的燃尽图不可直接比较。60点对A团队和B团队的含义可能不同，工作项拆得粗的团队曲线更陡、拆得细的团队曲线更平。跨团队比较应使用各自的速度趋势和交付结果，而不是并排看曲线形状。
燃尽图需要与其他跟进信息配合使用：工作项状态和阻塞记录说明剩余量为何变化，测试与缺陷数据说明完成质量，评审反馈说明交付价值。曲线是进度沟通的一个视图，把它当作唯一结论会遗漏这些信息。
常见问题
迭代燃尽图的理想燃尽线需要每天重画吗？
不需要。理想线在迭代计划确认总工作量后一次算出，起点是总工作量，终点是迭代最后一天的0点，中间按工作日均分。迭代期间只在范围发生变更时调整，并从变更日起重算剩余天数的理想线。如果每天都按最新剩余量重画理想线，理想线就失去了参照意义，实际线与它的对比也无从谈起。
迭代中途插入新需求，燃尽图上的历史数据要改吗？
历史日期的实际剩余值保持不变，只在变更当天做标注，说明曲线抬升来自范围新增。同时把迭代总工作量加上新增估算，从变更日起重算剩余天数的理想线。这样既反映新范围，又保留变更发生的时间点，回顾时能判断当时的进度压力和容量假设是否合理。如果新增需求导致原定目标无法完成，应在迭代内与相关方确认取舍，把被移出的工作项明确记录。
实际线一直高于理想线，是不是说明团队进度落后？
实际线高于理想线只说明剩余工作量比计划多，原因需要回到具体工作项判断。常见原因包括估算偏乐观、出现阻塞、成员被临时抽调、依赖方交付延迟，也可能是工作项拆分粒度与估算口径不一致。判断时应逐项核对未完成工作项的状态和阻塞记录，而不是从曲线形状直接下结论。示例中前5日实际线高出理想线3至7点，评审时归因于重构工作项比预估复杂，属于估算偏差而非产能问题。
迭代结束时未完成的工作项，可以直接按原点数结转到下一个迭代吗？
建议重新评估后再决定是否进入下一个迭代，不默认按原点数结转。重新评估可以发现上一迭代的估算偏差，避免把乐观估算带入新迭代，让新迭代理想线的起点失真。处理结果要明确记录：是重新估算后纳入、拆分后部分纳入，还是退回待办列表等待重新排期。
不同团队的燃尽图可以直接放在一起比较吗？
不建议直接比较曲线形状。故事点在不同团队之间的含义可能不同，工作项拆得粗的团队曲线更陡，拆得细的团队曲线更平，迭代长度和团队规模差异也会影响曲线形态。跨团队观察进度应使用各自的速度趋势和交付结果，燃尽图更适合作为单个团队内部的进度沟通视图。
