燃尽图出现异常形态，说明迭代执行中可能有情况需要核查，但曲线本身只是信号，不能直接当作结论。判断时先确认剩余工作量的统计口径和观察窗口，再对照工作项变更、状态流转与阻塞记录，最后用站会和评审证据交叉验证。本文按曲线上升、长时间平台、提前触底三类形态，给出原因假设、排查顺序与处置动作。
要点总览（TL;DR）
- 燃尽图异常只是信号，判断前先确认剩余工作量按任务数、工时还是故事点统计，口径未明不宜下结论。
- 曲线上升先查范围新增、估算上调、缺陷回流与任务重新打开，用工作项变更历史验证，不直接归因团队执行。
- 长时间平台要区分“没进展”和“没记录”：抽查状态更新时间与站会汇报是否一致，再查阻塞与任务粒度。
- 提前触底重点核对关闭项是否满足完成定义，排查口径切换、任务移出迭代和剩余量漏记。
- 处置后以曲线重新贴合实际剩余量、状态更新及时、未完成项有明确去向作为恢复标准，并在复盘中把形态作为讨论输入。
先分清哪些异常形态值得排查
燃尽图的日常波动很常见。一天没有更新状态、某位成员请假、任务在两人之间转手，都可能让曲线短暂走平或小幅反弹。需要进入诊断的，是形态持续偏离预期并且无法用当天的工作安排解释的情况。判断“持续”要结合迭代长度：两周迭代中连续三个工作日平台不动，比一天的小幅上升更值得追查；一个月迭代则可以放宽到四到五个工作日。
典型的需要排查的形态有三类。第一类是曲线上升，即剩余工作量在迭代中途明显增加，且增量超过日常波动幅度。第二类是长时间平台，曲线在若干工作日内几乎水平，剩余量不降。第三类是提前触底，迭代尚未结束，剩余量已接近或降到零，但交付物是否真正可用存疑。三类形态指向的原因方向不同，排查时不要混在一起看。
在解读形态之前，必须先确认剩余工作量的统计口径。按任务数统计时，关闭一个任务剩余量就减一，任务拆分粒度会直接影响曲线陡峭程度；按工时统计时，曲线反映的是剩余预估工时，填报不及时会让曲线失真；按故事点统计时，剩余量只在需求整体完成时下降，过程中曲线会长时间平台，这属于口径特性而非执行停滞。同一张图在不同口径下含义可能完全不同，口径未确认前不宜下判断。
观察窗口同样要交代清楚。单个迭代内的形态用于判断本次执行是否偏离计划；跨迭代对比用于识别反复出现的模式，例如每个迭代末期都出现陡降，可能说明关闭动作集中在收尾阶段。跨迭代对比需要各迭代口径一致，否则比较意义有限。以下清单可作为进入诊断前的核对项：
- 确认当前燃尽图按任务数、工时还是故事点统计，以及迭代内是否发生过口径切换；
- 确认迭代起止日期、工作日历与统计截止时间，排除节假日和跨时区造成的误读；
- 确认异常形态持续的时长，是否超过该迭代长度对应的合理波动区间；
- 确认是否存在同期已知的范围变更、人员变动或环境中断事件；
- 确认对比基线是计划曲线还是历史迭代实际曲线。
三类异常形态对应的原因假设与排除证据
排查的基本顺序是先口径、再记录、后访谈。先排除统计方式造成的假象，再查工作项的变更历史和状态流转，最后才通过站会沟通和个别访谈了解背景。这个顺序能避免把数据问题误判为团队执行问题，也能让访谈更有针对性。下表按形态列出常见原因假设与对应的验证证据，表中内容是需要验证的假设，不是已确认的结论。
| 异常形态 | 原因假设 | 验证证据 | 排除条件 |
|---|---|---|---|
| 曲线上升 | 迭代范围新增需求 | 迭代范围变更记录、需求加入迭代的时间点 | 新增项在计划评审中已确认并同步调整了计划曲线 |
| 曲线上升 | 估算上调 | 工作项估算字段的修改历史与修改人 | 上调发生在计划阶段且已纳入基线 |
| 曲线上升 | 缺陷回流或任务重新打开 | 缺陷关联记录、任务状态从已完成回退的流转记录 | 回流项属于原计划内的验收返工且已预留缓冲 |
| 长时间平台 | 任务状态未及时更新 | 状态最后更新时间与站会记录的时间差 | 更新延迟在团队约定的容忍范围内 |
| 长时间平台 | 工作被阻塞 | 阻塞标记、依赖项状态、外部等待记录 | 阻塞已在站会暴露并有明确解除计划 |
| 长时间平台 | 任务拆分过粗 | 任务粒度分布、单个任务持续天数 | 粗粒度任务有明确的中间检查点 |
| 长时间平台 | 人员投入变化 | 成员可用工时、请假与借调记录 | 投入变化已在迭代内重新分配并调整计划 |
| 提前触底 | 提前关闭未完成项 | 关闭项对照完成定义与验收标准的核对结果 | 关闭项均有验收记录且测试通过 |
| 提前触底 | 统计口径切换 | 图表配置变更记录、口径切换时间点 | 切换经过团队确认并重算了历史数据 |
| 提前触底 | 任务被移出迭代 | 移出操作记录、移出原因与审批 | 移出项已转入明确的后续安排并有记录 |
| 提前触底 | 剩余量漏记 | 未关闭但无剩余量的工作项清单 | 漏记项已补录且曲线重新贴合 |
曲线上升时，先看增量来自新增还是重估。新增需求要看它进入迭代的时间与审批路径，重估要看修改历史中是谁在什么背景下调整了估算。缺陷回流和任务重新打开容易被忽略，它们会让已完成的工作重新计入剩余量，形态上表现为上升，实质是质量或验收标准问题。验证时以工作项变更历史为主，访谈用于补充背景，不用来替代记录。
长时间平台通常说明剩余量的减少没有发生，或者发生了但没有被记录。这两者的处置方向完全不同：前者要解决阻塞和拆分问题，后者要解决更新习惯问题。区分方法是抽查若干进行中的任务，核对状态最后更新时间与站会上口头汇报的进度是否一致。如果口头进度明显领先于系统记录，问题在更新机制；如果两者一致且都不动，问题在阻塞或任务过大。
提前触底要重点区分真实完成与统计假象。真实完成的标志是关闭项满足完成定义、通过验收、相关测试记录齐全。统计假象的常见来源包括：为赶进度提前关闭未完成项、中途切换了统计口径、把任务移出迭代而未说明去向、剩余量字段被清零但任务仍处于进行中。核对时逐项抽查关闭记录，比整体看曲线更能发现问题。
按异常形态执行的处置步骤
处置动作要按形态分别设计，并明确责任角色。迭代负责人负责组织排查和推动更新，开发人员负责如实反馈进度与阻塞，测试人员负责核对完成质量，产品负责人负责范围变更的取舍决策。以下步骤适用于确认异常形态成立之后，尚未确认前不要提前动手调整数据。
曲线上升的处置。第一步，汇总本迭代内所有新增和重估的工作项，形成变更清单。第二步，由产品负责人主持范围变更评审，逐项判断是保留、延后还是移出迭代，判断依据是需求优先级和对迭代目标的影响。第三步，对保留项重新估算，并同步调整计划曲线，让基线反映真实范围。第四步，对缺陷回流项追查根因，判断是验收标准不清还是开发质量问题，分别安排返工或补充测试。适用条件是变更项已经明确且团队对优先级有共识；如果优先级争议未解决，应先升级到产品负责人决策，不自行移出。
长时间平台的处置。第一步，抽查进行中任务的状态更新时间，识别更新滞后的任务并推动当日更新。第二步，在站会上逐项确认阻塞，把阻塞标记补录到对应工作项上，明确解除责任人和期望时间。第三步，对持续超过三到五天没有进展的粗粒度任务进行拆分，拆成可在一天到两天内完成并验证的子任务。第四步，核对人员投入变化，若有人长期被其他事务占用，由迭代负责人与相关方协调投入。适用条件是团队已建立每日更新习惯；若更新滞后是普遍现象，应先解决机制问题再谈单点阻塞。
提前触底的处置。第一步，抽取已关闭工作项，对照完成定义和验收标准逐项复核，标记出关闭但未真正完成的项。第二步，对复核不通过的项重新打开，恢复其剩余量，并记录重新打开的原因。第三步，核对统计口径是否在迭代内发生过切换，若有，确认切换是否经过团队同意并重算历史数据。第四步，核查是否有任务被移出迭代，确认移出原因、审批和后续安排。第五步，检查剩余量字段是否存在漏记，补录后观察曲线是否重新贴合实际。
涉及批量关闭、批量移出迭代或整体重算剩余量这类有破坏风险的操作，需要设定前置条件和停止点。前置条件包括：完成定义已书面明确、操作清单已逐项核对、操作人和复核人已分离、操作前的数据已留存。停止点包括：复核中发现超过约定比例的关闭项不满足完成定义时暂停操作，先回到质量核查；范围变更未获产品负责人确认时不得移出；口径切换影响历史对比时先与团队沟通再执行。操作完成后保留变更记录，便于复盘追溯。
在工具层面，这些动作依赖工作项状态、剩余量与阻塞信息的持续维护。ONES Project 提供看板、燃尽图等工具用于实时掌控当前进度，并支持任务工时统计以估算任务持续时间；团队在每日站会中借助看板对齐进度与风险、排除问题，能让状态更新和阻塞暴露成为日常动作，而不是等到曲线异常才补记录。具体图表口径与配置以实际产品为准。
验证恢复与避免同类异常复发
处置完成后，先验证燃尽图是否恢复可信。核心标准是曲线重新贴合实际剩余量：每天的实际剩余量与团队掌握的真实进度一致，曲线斜率与剩余工作节奏匹配。辅助检查包括状态更新及时性，即进行中任务的状态最后更新时间不超过一个工作日；阻塞项均有标记和解除计划；关闭项均有验收记录。验证周期建议覆盖处置后的三到五个工作日，单日恢复不足以说明问题已解决。
迭代结束时，未完成工作需要重新评估，而不是默认自动结转到下一迭代。重新评估的内容包括：剩余工作量是否重新估算、优先级是否仍然成立、是否拆分后带入下个迭代、是否有项应当退回待办列表。每项都要有明确去向和记录，避免未完成项在结转中悄悄消失，造成下个迭代起点数据失真。
减少同类异常复发，靠的是日常机制而非事后补救。可落地的动作包括：每日站会前完成剩余量更新，站会上只讨论偏差和阻塞；阻塞在发现当日就标记并指定解除责任人；范围变更一律走评审并同步调整计划曲线；迭代回顾会上把燃尽图形态作为讨论输入，结合工时日志等数据复盘进度、质量和成本偏差，由团队判断原因，而不是把图形现象直接写成结论。复盘产出的改进项要有责任人和验证时间，下个迭代检查落实情况。
恢复验证清单可归纳为：曲线与实际剩余量一致、状态更新及时、阻塞有标记有责任人、关闭项有验收记录、未完成项有明确去向、复盘改进项有跟踪。六项都满足，可以认为本次异常已处置完毕；仍有缺项时，继续按对应形态的排查路径处理，不急于关闭问题。
常见问题
迭代中途新增需求导致燃尽图上升，应该调整计划曲线还是压缩范围？
两种做法都成立，取决于新增需求的优先级和对迭代目标的影响。若新增项优先级高于原计划中的某些项，由产品负责人主持评审，把低优先级项延后或移出，同时重新估算保留项并同步调整计划曲线，让基线反映真实范围。若新增项只是补充性质，可安排到下个迭代，本次迭代维持原计划。关键是变更走评审并留下记录，避免曲线上升后无人解释。
团队每天都开站会，燃尽图还是长时间平台，问题可能出在哪？
站会开了但曲线不动，常见原因是站会只汇报进度、不更新系统记录，或者任务拆分过粗，单个任务持续多天没有可验证的中间状态。可以先抽查几个进行中任务，核对状态最后更新时间与站会上口头汇报的进度是否一致：口头明显领先说明更新机制有问题，两者一致且都不动则更可能是阻塞或任务过大。前者推动当日更新，后者拆分任务并补录阻塞标记。
燃尽图提前触底，但迭代结束时仍有工作没做完，怎么排查？
先逐项复核已关闭工作项，对照完成定义和验收标准，标记出关闭但未真正完成的项，重新打开并恢复剩余量。再核对三件事：迭代内是否切换过统计口径、是否有任务被移出迭代而未说明去向、剩余量字段是否被清零但任务仍在进行中。三类情况都会让曲线提前触底而实际工作未完成。复核时以关闭记录和验收记录为准，不凭印象判断。
处置异常时批量关闭或移出迭代，需要满足什么条件？
这类操作影响历史数据，建议先满足几个前置条件：完成定义已书面明确、操作清单逐项核对、操作人与复核人分离、操作前数据已留存。同时设定停止点，例如复核中发现超过约定比例的关闭项不满足完成定义时暂停操作，先回到质量核查；范围变更未获产品负责人确认时不移出；口径切换影响历史对比时先与团队沟通。操作完成后保留变更记录，便于复盘追溯。
一个迭代的燃尽图恢复正常，就能说明执行问题解决了吗？
单日恢复不足以说明问题解决。建议观察处置后三到五个工作日，确认曲线持续贴合实际剩余量、进行中任务状态更新时间不超过一个工作日、阻塞项均有标记和责任人、关闭项均有验收记录。迭代结束时还要检查未完成项是否逐项重新评估并明确去向，而不是默认结转到下个迭代。这些条件都满足，再结合复盘确认改进项有责任人和验证时间，才算处置闭环。
