迭代燃尽图的设计，核心是先定“剩余量”口径，再定理想线与更新节奏。以迭代规划确认的Sprint Backlog为基线，把工作折算成同一单位，画出从总量降到零的理想线，每天固定时点记录实际剩余量；范围调整单独记录并重算理想线。本文按口径、步骤、角色、示例和检查顺序展开，ONES可作为承载工作项剩余量与迭代状态记录的工具之一。
要点总览（TL;DR）
- 燃尽图先定口径：一个迭代只用一种剩余量单位（故事点、工时或任务数），基线取迭代规划确认后的Sprint Backlog总量。
- 理想线从基线总量按工作日线性降到迭代结束日归零；范围调整在变更日记录原因与调整量，从当日起重算理想线，历史实际点不改写。
- 每日在固定时点汇总剩余量打一个实际点，并记录完成、阻塞、返工等变化原因，保证曲线可比、可追溯。
- Scrum Master或迭代负责人维护图表与更新节奏，团队成员更新任务剩余量，产品负责人决定范围调整，团队在迭代结束时逐项重新评估未完成工作。
- 用单位一致、基线可追溯、打点连续、变更留痕、范围同步、未完成项有评估结论、图与Sprint Backlog一致这七项检查图是否可用于决策。
先定口径：燃尽图到底在数什么
燃尽图是一条随时间下降的曲线，纵轴是“还剩多少工作”，横轴是迭代日期。设计第一版图，只需要回答四个问题：数什么单位、从哪一刻开始数、理想线怎么画、范围变了怎么办。这四项写清楚，图才有解释力；否则同样一条上升曲线，有人读成进度落后，有人读成统计口径变了。
剩余量单位：故事点、工时还是任务数
三种单位都能用，差别在于它们衡量的东西不同。故事点反映相对规模，适合需求粒度较稳定、团队已形成估算共识的迭代；工时反映投入量，适合任务拆分较细、需要观察人力消耗的迭代；任务数最直观，适合任务大小接近、以流程推进为主的迭代。选择的关键是一致性：一个迭代内只用一种单位，不要把需求按故事点、任务按工时混在一张图上，否则总量无法相加，下降速度也失去意义。
如果团队估算习惯尚不稳定，可以先用任务数起步，等估算共识形成后再切换到故事点。切换应发生在迭代边界，不在迭代中途换单位，避免历史点与新点不可比。
基线时点：以规划确认后的Sprint Backlog为准
基线是燃尽图的起点总量，取迭代规划会议结束、团队确认承诺范围之后的Sprint Backlog。这个时点之后，总量才作为“应完成工作”的参照。规划前的草稿估算、会上的临时讨论都不进入基线，否则起点会随讨论反复变动，图从一开始就不可追溯。
基线要留下可查的记录：迭代名称、确认日期、包含的工作项清单和总量数值。后续任何总量变化都与这份基线对照，而不是覆盖它。
理想线：从总量线性降到迭代结束日归零
理想线是一条直线：起点为基线总量，终点为迭代最后一个工作日的零。按工作日均分总量即可得到每日应剩余量。例如总量60点、迭代10个工作日，理想线每天下降6点，第5个工作日结束应剩30点。理想线的作用是提供参照，它假设工作量均匀消耗，现实中很少完全吻合，因此实际线偏离理想线属于正常现象，需要关注的是偏离的幅度和持续天数。
范围调整：重算理想线，保留历史点
迭代中途新增或移除工作，总量会变。处理规则是：在变更发生日记录调整原因和调整量，从该日起按新的总量重算剩余理想线，已经画出的历史实际点保持原样。这样图上会看到理想线在变更日出现折点，实际线的历史段不被改写，读者能区分“进度变化”和“范围变化”。把历史点悄悄改掉，等于抹掉了范围波动的证据，图也就无法用于复盘。
把以上四项写成一段口径说明，放在迭代看板或团队文档里，就是第一版燃尽图的设计交付物。
操作步骤：从规划到每日打点
口径确定后，搭建与维护燃尽图是一串固定动作。每一步都有输入、动作、输出和完成标志，按顺序执行即可。
第一步：迭代规划，冻结基线
输入是产品待办列表中已排好优先级的需求。动作是团队在规划会上拆分任务、逐项估算、确认本迭代承诺范围，并汇总出总量。输出是Sprint Backlog和基线总量记录。完成标志是团队对范围和总量达成一致，基线数值写入图表配置。产品负责人按优先级把需求规划进迭代、与团队共同评审，这一步的产出质量直接决定基线是否可信。
第二步：建立图表，设置起止与单位
输入是基线总量、迭代起止日期和选定的单位。动作是在所用工具中创建燃尽图，设定迭代周期、纵轴单位和理想线规则。输出是一张起点正确、理想线完整的空图。完成标志是图上理想线从基线总量准确落到结束日零，且单位标注与口径说明一致。
第三步：每日跟进，固定时点打点
输入是当日各工作项的剩余量。动作是在每天固定时点（例如每日站会前）汇总剩余量，在图上打一个实际点，并简要记录变化原因，包括完成、阻塞、返工等。输出是连续的实际线和一个原因记录。完成标志是当天有且只有一个实际点，且与工作项状态一致。时点固定很重要，上午打点和下班前打点会得到不同的曲线，混用会让趋势失真。
第四步：范围调整，同步总量与理想线
输入是范围变更请求及其估算。动作是由产品负责人判断是否纳入本迭代，确认后在变更日更新总量、记录原因，并从当日起重算理想线。输出是带折点的理想线和一条变更记录。完成标志是总量、理想线与Sprint Backlog三者一致，历史实际点未被修改。
第五步：迭代结束，核对实际线与未完成项
输入是迭代最后一天的实际剩余量和Sprint Backlog状态。动作是核对实际线终点与未完成工作项清单，逐项确认状态。输出是一份未完成项清单和迭代燃尽图终版。完成标志是图上剩余量与工作项实际状态吻合，未完成项已进入重新评估流程，而非直接带入下一迭代。
在工具层面，ONES Project 提供看板、燃尽图等工具用于实时掌控当前进度，团队成员可通过敏捷看板管理任务状态。每日打点前先核对工作项剩余量，再读图，能让图与实际任务状态保持同步。
角色分工与各自交付物
燃尽图失效的常见原因，是维护、解读和决策压在一个人身上。把职责拆开，图才有人持续更新，也才有人对偏差做出反应。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| Scrum Master或迭代负责人 | 建立图表、设定更新节奏、每日汇总打点、在站会上呈现趋势 | 燃尽图、每日更新记录、偏差提示 |
| 团队成员 | 每日更新自己任务的剩余量，说明完成情况与阻塞 | 准确的任务剩余量、阻塞说明 |
| 产品负责人 | 判断范围调整是否纳入迭代，确认优先级取舍 | 范围变更决定与原因记录 |
| 团队集体（迭代结束时） | 逐项重新评估未完成工作，决定去向 | 未完成项重新评估结论 |
维护人负责让数据连续，团队负责让数据真实，产品负责人负责让范围变化有据可查。三者缺一，图要么断点，要么失真，要么在范围频繁变动后失去参照。迭代结束时的未完成项重新评估，由团队集体完成，评估内容包括剩余工作量、阻塞原因和是否纳入下一迭代，结论要落到具体工作项上。
示例：一个两周迭代的燃尽图怎么走
以下为演示情景，数值用于说明口径与步骤，非真实项目数据。某团队进行两周迭代，共10个工作日，规划会确认Sprint Backlog总量为60故事点，基线日期为迭代第1天。
正常燃尽与理想线
理想线每天下降6点：第1天结束应剩54点，第5天结束应剩30点，第10天结束归零。假设前4天实际剩余依次为56、50、44、38，实际线略高于理想线但趋势接近，属于正常波动，站会上只需确认任务按计划推进。
中途新增需求时的调整记录
第5天，产品负责人确认新增一个8点的需求纳入本迭代。当日记录：变更日期第5天，新增8点，原因“客户紧急反馈”。总量由60点调整为68点，剩余理想线从第5天起按新总量重算，剩余5个工作日每天应下降约(68−当日实际剩余)/5。图上理想线在第5天出现折点，前4天的实际点保持不变。若不重算理想线，后续每天仍按6点下降，图会显示团队“超额完成”，掩盖范围增加的事实。
实际线高于理想线时的跟进动作
假设第7天实际剩余为40点，而按调整后理想线应剩约32点，连续两天高于理想线。跟进动作是：站会上逐项检查剩余量较大的任务，确认是否存在阻塞、需求理解偏差或估算偏低；由团队决定是否拆分任务、调整优先级或向产品负责人提出范围取舍。图本身不解决问题，它提供的是讨论的起点和偏差的证据。
迭代结束的未完成项处理
第10天结束，实际剩余12点，对应3个工作项未完成。团队逐项重新评估：一项因外部依赖阻塞，剩余8点，建议下迭代优先处理；一项需求范围需重新澄清，暂不纳入；一项剩余4点，可拆入下迭代。三项均记录评估结论，而非默认整体结转到下一迭代。迭代回顾会上，可结合燃尽图、工时日志等数据复盘进度偏差，讨论改进建议。
完成检查：这张图能不能用来做决策
燃尽图设计是否可用，可以用下面这份清单逐项核对。每项都有明确的通过标准，全部通过，图才具备支撑每日跟进和迭代决策的可信度。
| 检查项 | 通过标准 |
|---|---|
| 单位一致性 | 整个迭代只用一种剩余量单位，图与口径说明一致 |
| 基线可追溯 | 基线总量有确认日期和工作项清单，后续变化可对照原始基线 |
| 每日打点连续 | 每个工作日有且只有一个实际点，无缺漏、无重复时点 |
| 变更原因有记录 | 每次总量变化都有日期、调整量和原因 |
| 范围调整同步 | 总量与理想线在变更日同步更新，历史实际点未被改写 |
| 未完成项重新评估 | 迭代结束的未完成工作逐项有评估结论，未默认结转 |
| 图与Backlog一致 | 图上剩余量与Sprint Backlog中工作项的实际状态吻合 |
核对时优先看两项：基线是否可追溯、范围调整是否同步。这两项决定图的历史是否可信；每日打点连续性和未完成项评估决定图能否支撑当天的决策。若图与工作项状态不一致，先修正数据来源，再讨论趋势，避免在错误数据上做判断。
常见问题
迭代中途临时插入紧急需求，燃尽图应该怎么处理才不影响复盘？
在变更发生当天记录三件事：变更日期、调整量（新增或移除多少单位）、原因。然后从当日起按新的总量重算剩余理想线，已经画出的历史实际点保持原样。这样图上理想线会在变更日出现折点，复盘时能清楚区分“进度变化”和“范围变化”。如果直接改掉历史点，范围波动的证据就丢失了，图也无法支撑回顾讨论。
团队估算习惯还不稳定，燃尽图用故事点还是任务数起步更合适？
估算共识尚未形成时，可以先用任务数起步，前提是任务拆分粒度接近，否则任务数下降速度会失真。等团队对相对规模形成稳定判断后，再在迭代边界切换到故事点，不在迭代中途换单位。无论选哪种，一个迭代内只用一种单位，避免需求按故事点、任务按工时混算导致总量无法相加。
实际线连续几天高于理想线，站会上应该讨论什么？
先确认数据本身是否准确：工作项剩余量是否及时更新、当天打点是否在固定时点完成。数据无误后，逐项检查剩余量较大的任务，判断是否存在阻塞、需求理解偏差或估算偏低。团队据此决定拆分任务、调整优先级，或由产品负责人做范围取舍。燃尽图提供的是偏差证据和讨论起点，解决动作要落到具体工作项上。
迭代结束时未完成的工作项，可以直接结转到下一迭代吗？
不建议默认整体结转。团队应逐项重新评估：剩余工作量多少、阻塞原因是什么、需求是否仍需澄清，再决定是纳入下一迭代、拆分处理还是暂缓。评估结论要记录到具体工作项上，并在迭代回顾中结合燃尽图等数据讨论改进。默认结转会让下一迭代的基线从一开始就混入未经确认的工作，燃尽图也随之失真。
用ONES这类工具承载燃尽图时，需要额外注意什么？
ONES Project 提供看板、燃尽图等工具用于实时掌控当前进度，团队成员可通过敏捷看板管理任务状态。工具能画出曲线，但口径仍要团队自己定：单位、基线时点、打点节奏、范围变更规则都应写进口径说明，并与工具中的工作项状态保持同步。每日打点前先核对工作项剩余量，再读图，避免图与Sprint Backlog脱节。
