迭代燃尽图长时间平台或提前触底的原因排查

迭代燃尽图长时间走平或提前触底，通常先指向剩余工作量的统计口径和更新节奏，再指向执行现场的真实阻塞、范围变更或估算偏差。平台期意味着剩余量在一段时间内没有净减少，触底则意味着剩余量被提前清零或低估。排查时先核对数据层，再逐项找证据，避免把假设直接当成结论。

要点总览（TL;DR）

• 燃尽图长时间平台，先查剩余量是否每日登记、状态更新是否滞后，再查评审测试等待、任务拆分过粗和人员投入下降。
• 提前触底先区分真实完成与统计假象：核对范围变更记录、任务关闭与验收时间、估算偏差，以及统计是否遗漏缺陷等临时工作项。
• 排查顺序按先数据口径、再执行阻塞、后范围与估算推进，每步用状态停留时长、阻塞标记、更新记录和验收记录作证据。
• 未完成工作需在迭代评审中显式决策，是否结转由团队确认，不默认自动结转。
• 日常固定更新时点、范围变更留痕、约定拆分粒度与完成定义，可减少同类异常复发。

先分清平台与触底：症状、范围和数据口径

燃尽图的横轴是迭代时间，纵轴是剩余工作量。平台期表现为曲线连续多个工作日接近水平，剩余量下降幅度明显小于预期；提前触底表现为迭代尚未结束，剩余量已降到零或接近零，曲线提前贴底。观察窗口建议至少覆盖连续三到五个工作日，单日波动不足以判断形态异常。

两类形态的排查范围限定在当前迭代运行内，关注本迭代的工作项、状态流转和范围变更记录，不扩展到敏捷框架概念本身，也不涉及需求池的长期管理方法。

排查的第一步是确认剩余工作量的统计口径。不同团队可能按任务数量、故事点或工时统计，三种口径对同一迭代会画出不同曲线。口径本身没有对错，关键是团队约定与实际配置一致。若口径在迭代中途被调整，曲线形态会突变，这类变化属于数据层原因，需要先排除。

第二步检查状态更新是否滞后于实际进展。成员完成了任务但未及时流转状态，剩余量就不会下降，曲线表现为平台；反过来，任务被提前批量关闭，剩余量会骤降，曲线提前触底。核对方法是抽取若干工作项，比对状态变更时间与实际交付、验收记录的时间差。

形态	曲线表现	常见数据层原因	需要核对的字段
长时间平台	连续多个工作日剩余量几乎不降	状态更新滞后、剩余量未每日登记、统计口径中途变化	状态变更时间、剩余量更新记录、燃尽图统计口径配置
提前触底	迭代未结束剩余量已归零或接近零	范围被移出迭代、任务提前关闭、统计只覆盖部分工作项类型	迭代范围变更记录、工作项关闭时间与验收记录、统计包含的工作项类型

这张对照表的作用是把数据层原因先筛一遍。若核对后口径一致、更新及时，曲线仍异常，再进入执行层找原因。

长时间平台的可能原因与排除证据

平台期的共同特征是剩余量没有净减少，但背后的原因可能完全不同。下面按假设—证据的方式列出常见原因，每条都给出验证方法和排除条件。

任务集中在评审、测试或外部依赖等待

开发完成后任务卡在评审或测试环节，状态停留在“待评审”“待测试”，剩余量自然不降。外部依赖如第三方接口、环境准备未到位，也会让任务长期挂起。验证证据是查看各状态的平均停留时长，找出停留时间明显偏长的状态节点，并检查是否有阻塞标记或等待说明。排除条件是：状态停留时长正常、阻塞项有明确责任人和解除时间。

工作项拆分过粗

一个任务颗粒度过大，需要多天才能完成，期间状态一直是“进行中”，剩余量只在最后一天才下降。曲线因此长时间走平，最后突然下坠。验证方法是统计进行中任务的平均持续天数，对照团队约定的拆分粒度。排除条件是：多数任务能在两到三个工作日内完成状态流转。

剩余量登记习惯缺失

团队只在任务关闭时更新剩余量，过程中不登记实际剩余工时或点数，曲线就会呈现“平台加骤降”的组合。验证证据是查看每日剩余量更新记录，若多数工作项在迭代中段没有任何更新，说明登记习惯缺失。排除条件是：每日有稳定的剩余量更新记录。

人员投入下降

成员被抽调处理其他事务，或并行任务过多导致本迭代投入不足，实际产出下降，剩余量自然降得慢。验证证据是对比计划投入与实际工时日志，查看成员在迭代内的任务分布。排除条件是：实际投入与计划投入基本一致。

原因假设	验证证据	排除条件
评审、测试或外部依赖等待	状态停留时长、阻塞标记、等待说明	各状态停留时长正常，阻塞项有责任人和解除时间
工作项拆分过粗	进行中任务的平均持续天数	多数任务两到三个工作日内完成流转
剩余量登记缺失	每日剩余量更新记录	每日有稳定的剩余量更新
人员投入下降	工时日志、成员任务分布	实际投入与计划投入基本一致

提前触底的可能原因与排除证据

提前触底比平台更容易误导判断，因为曲线看起来“进展很好”，实际可能是剩余量被提前清零或低估。排查的核心是区分真实完成与统计假象。

范围被移出迭代或拆到下一个迭代

迭代中把部分工作项移出当前迭代，剩余量会相应减少，曲线随之下探。若移出动作集中发生，曲线可能直接触底。验证证据是迭代范围变更记录，核对每次移出的工作项、时间和原因。排除条件是：范围变更均有记录，且移出决策经过团队确认。

任务被提前关闭但验收未完成

成员把任务状态改为“已完成”，但评审或验收尚未通过，剩余量被提前扣除。验证方法是抽取已关闭任务，比对关闭时间与验收记录时间。排除条件是：关闭任务均有对应的验收通过记录。

估算偏小

任务初始估算低于实际工作量，剩余量基数偏小，曲线下降显得过快，容易提前触底。验证证据是对比估算值与实际工时日志，统计偏差较大的任务比例。排除条件是：估算与实际工时的偏差在团队可接受范围内。

统计只覆盖部分工作项类型

燃尽图只统计故事或任务，遗漏缺陷、临时插入的工作项，剩余量被低估，曲线提前贴底。验证方法是核对燃尽图统计包含的工作项类型，与迭代实际承载的全部工作比对。排除条件是：统计范围覆盖迭代内全部工作项类型。

原因假设	验证证据	排除条件
范围移出或拆分到下一迭代	迭代范围变更记录	变更均有记录且经团队确认
任务提前关闭	关闭时间与验收记录比对	关闭任务均有验收通过记录
估算偏小	估算值与实际工时日志对比	偏差在团队可接受范围内
统计遗漏工作项类型	统计范围与迭代全部工作比对	统计覆盖全部工作项类型

真实完成与口径失真的区分标准是完成定义和验收记录。任务满足团队约定的完成定义、有验收证据、范围变更经过确认，触底才可信；任一条件缺失，都应先按口径失真处理。

按排查顺序处置并验证恢复

排查按“先数据、再执行、后范围与估算”的顺序推进，每一步都有明确的产出，避免多头并进导致结论混乱。

1. 核对口径与更新记录。确认燃尽图的统计口径，检查每日剩余量更新和状态变更时间。若发现口径不一致或更新滞后，先修正数据，再观察一到两个工作日曲线是否恢复合理斜率。
2. 排查执行阻塞。对平台期，列出停留时间超长的状态节点和阻塞项，明确阻塞责任人与解除条件。对触底，抽查已关闭任务的验收记录，确认完成是否真实。
3. 核查范围与估算。调取迭代范围变更记录，核对移出、拆入的工作项；对比估算与实际工时，标记偏差较大的任务。

处置动作要落到具体对象：补登记剩余量、拆分长期进行中的任务、为阻塞项指定责任人和解除时间、修正明显偏小的估算。涉及批量修改状态或调整统计口径时，先导出当前迭代数据作为备份，或设定停止点，确认影响范围后再操作。

迭代结束时，未完成工作需重新评估并显式决策：是顺延到下一迭代、拆分后部分交付，还是调整范围。是否结转、如何结转应由团队在迭代评审中确认，不默认自动结转。

恢复验证的标准是连续数个工作日的曲线斜率与剩余量变化合理：平台期结束后剩余量应稳定下降，触底修正后曲线应回到与剩余工作匹配的位置。若修正后曲线仍异常，回到第一步重新核对数据口径。

在工具层面，ONES 支持通过敏捷看板管理任务状态，并在每日站立会议中借助看板对齐迭代进度与风险；ONES Project 提供看板、燃尽图等工具用于实时掌控进度，并支持任务工时统计与迭代规划。排查时可在系统中核对燃尽图的统计口径配置、工作项状态流转记录和迭代范围变更，把上述验证证据落到具体工作项上。

复发预防：让燃尽图持续可信

排查解决的是当前异常，减少复发靠的是迭代内的日常约定。以下清单可作为团队维护燃尽图可信度的基础。

• 固定更新时点。每天站立会前完成剩余量更新和阻塞标记，确保燃尽图反映的是当日真实状态，而非滞后数据。
• 范围变更留痕。迭代中移出、拆入工作项时记录变更原因和对剩余量的影响，让曲线变化有据可查。
• 约定拆分粒度与完成定义。任务拆分到两到三个工作日可完成的颗粒度，完成定义明确到验收标准，减少长期进行中和提前关闭两类问题。
• 回顾时回看曲线。迭代回顾中把燃尽图异常作为固定议题，分析平台或触底的成因，形成可执行的改进项并指定负责人。

这些约定不需要一次全部落地，可以从固定更新时点和范围变更留痕开始，运行一到两个迭代后再补充拆分粒度和回顾机制。燃尽图的价值在于持续可信，日常维护到位，异常排查的成本会明显下降。

常见问题

燃尽图平台期持续多久才值得启动排查？

建议以连续三到五个工作日为观察窗口。单日剩余量不变可能只是当天没有可关闭的任务，或成员忙于评审等不直接减少剩余量的工作。若连续多个工作日剩余量下降幅度明显小于预期，且状态更新记录显示工作项仍在流转，就值得按数据口径、执行阻塞的顺序排查。

范围变更导致的触底，是否一定说明燃尽图失真？

不一定。范围变更经过团队确认并留有记录，剩余量随之减少属于正常反映。需要警惕的是变更集中发生、缺少记录，或移出决策未经评审，这时曲线触底不能代表迭代真实进展。核对迭代范围变更记录中的工作项、时间和原因，是判断触底是否可信的关键一步。

修正数据口径后曲线仍未恢复，下一步查什么？

回到执行现场。平台期重点查停留时间超长的状态节点和阻塞项，明确责任人与解除条件；触底则抽查已关闭任务的验收记录，确认完成是否真实。若执行层也没有明显问题，再核查估算偏差和统计覆盖的工作项类型。每一步都保留核对记录，便于后续复盘。

迭代结束时未完成的工作应该怎么处理？

由团队在迭代评审中重新评估并显式决策：顺延到下一迭代、拆分后部分交付，或调整范围。是否结转、如何结转需要团队确认，不默认自动结转。这样处理可以避免剩余量被无声清零，也能让下一迭代的燃尽图起点反映真实工作量。

ONES 中排查燃尽图异常可以核对哪些信息？

ONES 支持通过敏捷看板管理任务状态，并在每日站立会议中借助看板对齐迭代进度与风险；ONES Project 提供看板、燃尽图等工具用于实时掌控进度，并支持任务工时统计与迭代规划。排查时可在系统中核对燃尽图的统计口径配置、工作项状态流转记录和迭代范围变更，把验证证据落到具体工作项上。具体统计口径与数据范围以实际项目配置为准。