迭代燃尽图出现长时间平台或提前触底，多数情况先指向剩余工作量的记录方式，其次才是范围变更或真实进度。排查时先确认纵轴统计的是工时、故事点还是任务数，再比对每日剩余量记录、工作项变更日志和迭代范围变更，逐项验证原因假设，避免直接把曲线异常归因于团队产出。
要点总览（TL;DR）
- 燃尽图长时间平台，优先核对剩余工作量是否每日更新、任务是否拆到可跟踪粒度，再确认阻塞期间剩余量是否同步调整。
- 提前触底先区分范围收缩与口径切换：调取迭代范围变更、工作项移出记录，核对提前关闭任务是否满足完成定义。
- 排查顺序建议从统计字段与更新频率入手，再比对工作项变更日志与曲线拐点，最后核查范围变更并与团队确认阻塞情况。
- 修正后连续观察三到五个工作日，确认曲线斜率回归合理区间；未完成工作逐条重新评估，不默认自动结转。
- 批量修改历史剩余量前先备份并导出变更记录，明确修改范围与停止点，保留后续复盘依据。
先看形态：平台、触底与上升分别对应什么信号
燃尽图的读图前提是确认纵轴口径。同一张曲线，按工时统计和按任务数统计会呈现完全不同的形态：工时口径下，一条任务从开始到完成可能持续消耗剩余量；任务数口径下，只有任务关闭时剩余量才下降，曲线天然呈阶梯状。读图前先确认三件事：纵轴统计字段是什么、理想线按什么速率计算、实际线取数时点在哪一天。
理想线通常由迭代总工作量除以迭代天数得到，是一条匀速下降的参考线。实际线与理想线的差异来源包括：工作日与自然日的计算差异、迭代中途范围增减、剩余量更新时点不统一。差异本身不构成异常，需要结合形态判断。
三种异常形态对应的问题方向可以先用下表建立初步判断，具体原因在后续章节展开。
| 形态 | 曲线表现 | 优先怀疑方向 | 次要怀疑方向 |
|---|---|---|---|
| 长时间平台 | 实际线连续多个工作日接近水平，剩余量几乎不变 | 剩余量字段未每日更新、任务粒度粗 | 工作被阻塞但状态未同步、按任务数统计 |
| 提前触底 | 迭代结束前剩余量已归零或接近零，曲线提前落到横轴 | 范围被压缩、工作项被移出迭代 | 任务提前关闭未验收、统计口径中途切换 |
| 上升 | 实际线中途抬升，剩余量增加 | 迭代中途新增工作项或追加范围 | 剩余量重新估算、拆分任务后补录工时 |
上升形态通常对应范围增加，属于范围管理问题；平台和触底则更需要区分“数据没记”与“工作真没动”。这个区分决定了后续是修正记录方式，还是调整迭代范围。
长时间平台：剩余量为什么几天不动
平台形态的核心问题是剩余量在一段时间内没有真实变化。可能的原因不止一种，需要按假设逐条验证，不能看到平台就认定团队停滞。
原因假设与验证证据
第一类假设是任务粒度粗。一条工作项跨多天完成，期间剩余量只在关闭时一次性扣减，曲线自然出现平台。验证方式是查看平台期内是否有工作项处于进行中且持续多日未拆分，以及这些工作项的预估工时是否明显偏大。
第二类假设是剩余工时字段未每日更新。团队只在任务关闭时回填剩余量，中间几天字段保持原值。验证方式是抽取平台期内几条进行中的工作项，比对每日剩余量记录与工作项变更日志，看字段值是否连续多日未变。
第三类假设是工作被阻塞但状态与剩余量未同步调整。任务实际停摆，剩余量却按原计划继续记录或干脆不动，两种情况都会让曲线失真。验证方式是结合站会记录和阻塞标记，确认平台期内是否存在外部依赖、等待评审等阻塞情况，以及阻塞期间剩余量是否做过调整。
第四类假设是统计口径问题。团队按任务数统计，任务未关闭前剩余量不变，曲线呈阶梯平台。验证方式是确认纵轴字段定义，并与团队核对是否在中途更换过统计方式。
排查顺序
- 确认纵轴统计字段与更新频率，排除口径因素。
- 抽取平台期内进行中的工作项，检查粒度与预估工时是否合理。
- 比对每日剩余量记录与工作项变更日志，定位字段未更新的时间点。
- 结合站会记录确认阻塞情况，判断剩余量是否应随阻塞调整。
每条假设都需要证据支撑。平台期内剩余量记录连续多日完全一致、变更日志也无对应修改，指向记录维护问题；剩余量有更新但数值变化很小，则更可能是任务拆分不足或工作确实受阻。
提前触底：剩余量为何在迭代结束前归零
提前触底的判断关键是区分“范围真的做完了”和“剩余量被提前清零”。前者是正常结果，后者才是需要排查的异常。常见原因集中在范围收缩和数据口径两类。
范围收缩类原因
范围被压缩是提前触底最常见的原因。迭代中途把部分工作项移出当前迭代、下调优先级或直接关闭，剩余量随之下降，曲线提前归零。验证方式是调取迭代范围变更记录和工作项移出记录，比对曲线拐点时间与变更时间是否吻合。
另一种情况是任务提前关闭但未完成验收。团队为让看板清爽，把“开发完成”的任务直接置为关闭，剩余量被清零，但测试和验收尚未进行。验证方式是抽取提前关闭的工作项，核对完成定义中的验收条件是否满足，检查关闭时间与验收记录是否匹配。
口径与记录类原因
统计口径中途从工时切换为任务数，会造成断崖式下降甚至直接触底。这类问题通常发生在迭代中途调整报表配置或更换统计字段时。验证方式是确认迭代期间是否修改过燃尽图配置，并比对切换前后的曲线斜率。
迭代中途新增工作未计入，也会让曲线整体偏低、提前触底。新增需求直接进入迭代但未同步更新总工作量，实际线相对理想线的基数就失真了。验证方式是核对迭代范围变更记录中是否有新增工作项，以及总工作量是否随之调整。
验证证据清单
- 范围变更记录：移出、关闭、降级的工作项清单及时间点。
- 工作项移出记录：被移出迭代的工作项去向，是否转入其他迭代或需求池。
- 关闭时的完成定义核对：提前关闭任务的验收状态与测试记录。
- 报表配置变更记录：统计字段、总工作量基数是否在迭代中调整过。
按顺序排查：从数据口径到范围变更
排查顺序影响结论可靠性。先查数据口径，再查范围与状态变更，最后与团队确认实际情况，可以避免把记录问题误判为产出问题。
第一步：核对统计字段与更新频率
确认燃尽图纵轴统计的是工时、故事点还是任务数，理想线的计算基数是什么，实际线取数时点是每日固定时间还是随字段变更实时更新。判断标准是：口径定义清晰、更新频率与站会节奏一致，则数据基础可信；口径模糊或中途变更过，先修正口径再读图。
第二步：比对变更日志与曲线拐点
把平台起点、触底时间点标在时间轴上，调取同期工作项变更日志，看拐点前后是否有集中修改。判断标准是：拐点与某类变更高度吻合，说明形态由该变更引起；拐点前后无任何记录变化，则更可能是字段未维护。
第三步：核查迭代范围变更与工作项移出
调取迭代范围变更记录，确认是否有工作项被移出、关闭或新增。判断标准是：移出量与触底幅度匹配，属于范围收缩；范围未变但剩余量归零，回到第二步检查关闭操作是否合规。
第四步：与团队确认阻塞与拆分情况
前几步排除数据和范围因素后，再与团队确认平台期内是否存在阻塞、任务是否拆得够细、剩余量是否有人负责更新。这一步是补充事实，不是追责。
操作风险边界
排查过程中如果需要批量修改历史剩余量或补录工时，先备份当前数据并导出变更记录，明确修改范围和停止点。历史数据一旦覆盖，变更日志的可追溯性会下降，后续复盘将失去依据。建议在迭代回顾前完成排查记录，修改操作留到回顾会确认后再执行。
在承载方式上，ONES Project 提供看板、燃尽图等工具用于跟踪当前进度，并提供任务工时统计辅助估算任务持续时间；迭代过程中的任务状态可通过敏捷看板管理，站会中借助看板对齐进度与风险。排查时可以把工作项变更记录、剩余量更新和范围调整放在同一套工作项数据里对照，减少跨表核对。具体统计口径与更新机制以团队实际配置为准。
修正后如何验证恢复并防止复发
修正数据口径或调整范围后，不能立即认定问题解决，需要连续观察曲线是否回归合理斜率，再从日常机制上减少同类异常。
验证观察项
- 连续观察三到五个工作日，实际线是否呈稳定下降趋势，斜率与理想线差距是否在可解释范围内。
- 平台是否消失：每日剩余量记录是否都有对应更新，变更日志与曲线拐点是否一致。
- 触底时间是否回到迭代末期：剩余量归零时间与迭代结束时间是否接近。
- 范围变更是否留痕：新增、移出、关闭的工作项是否都有记录可查。
观察期内如果曲线再次出现平台，回到排查第二步检查字段更新；如果再次提前触底，优先核对范围变更记录。
日常防复发机制
明确每日更新剩余量的责任人与时点。可以由任务负责人在站会前更新自己名下工作项的剩余工时，站会中对照看板确认，形成固定节奏。更新时点统一后，实际线的取数才有可比性。
迭代规划时检查工作项拆分与估算。单条任务预估工时不宜跨越多天，超过两天的工作项在规划阶段拆到可独立跟踪的粒度，减少平台形态的出现概率。
未完成工作的处理需要重新评估，不默认自动结转。迭代结束时对未完成工作项逐条确认剩余量、优先级和去向，再决定转入下一迭代还是退回需求池，避免结转操作掩盖真实进度。
迭代回顾时把燃尽图、工时日志等数据放在一起复盘进度偏差，把本次排查中发现的记录问题和范围问题转化为下一迭代的规划检查项。ONES 的迭代回顾场景支持通过燃尽图、工时日志等报表复盘进度、质量和成本偏差，可作为回顾会的对照材料。
常见问题
燃尽图纵轴按工时统计和按任务数统计，对判断平台形态有什么影响？
按任务数统计时，剩余量只在任务关闭时下降，曲线天然呈阶梯状，连续几天不动可能只是任务尚未关闭，属于口径特征而非异常。按工时统计时，进行中的任务每天应消耗部分剩余量，连续多日不变更值得怀疑记录维护问题。读图前先确认纵轴字段定义，再判断平台是否异常；如果团队中途更换过统计方式，需要把切换前后的曲线分段解读。
平台期内剩余量有更新但数值变化很小，应该往哪个方向查？
这种情况通常指向任务拆分不足或工作确实受阻。先抽取平台期内进行中的工作项，检查单条任务的预估工时是否跨越多天、是否缺少可独立跟踪的子任务；再结合站会记录确认是否存在外部依赖、等待评审等阻塞。剩余量每天只小幅下降，说明工作有推进但粒度太粗，规划阶段把超过两天的工作项拆细，可以减少这类形态。
迭代中途移出工作项后，燃尽图提前触底，这算正常还是异常？
移出工作项会让剩余量下降，曲线提前归零，这是范围收缩带来的正常结果，前提是移出操作有记录、去向明确。需要排查的是移出是否经过确认：工作项是转入下一迭代、退回需求池，还是被直接关闭。如果移出记录缺失或关闭时未核对完成定义，触底就掩盖了真实进度，应回到范围变更记录逐条核对。
修正剩余量记录后，观察多久可以判断燃尽图恢复正常？
建议连续观察三到五个工作日。判断标准包括：实际线是否呈稳定下降趋势、每日剩余量是否都有对应更新、变更日志与曲线拐点是否一致、剩余量归零时间是否接近迭代结束。观察期内再次出现平台，回到字段更新环节检查；再次提前触底，优先核对范围变更记录。观察周期覆盖一个完整站会节奏，结论更可靠。
迭代结束时未完成的工作项，应该怎么处理才不影响下一迭代的燃尽图？
逐条确认未完成工作项的剩余量、优先级和去向，再决定转入下一迭代还是退回需求池，不默认自动结转。结转前重新评估剩余工作量，避免把旧估算直接带入新迭代；转入下一迭代的工作项应计入新迭代总工作量，否则新曲线基数失真。处理结果留痕，便于回顾时对照。
