迭代结束时发现目标未达成，先别急着归因于团队不努力。更有效的做法是把差距拆成范围变化、容量估算、执行阻塞、验收口径四类，用迭代内留下的记录逐项验证，再决定补做、砍范围还是重新排期。未完成的工作也需要逐项重新评估，不能默认整体结转到下一迭代。本文给出一条从差距清单到处置决策、再到恢复验证的排查路径。
要点总览（TL;DR）
- 先把“目标未达成”拆成未完成项、部分完成项、验收未通过项，并区分数量、质量、时间三个维度，避免笼统归因。
- 按范围变化、容量估算、执行阻塞、验收口径四类原因逐项找证据验证，主因不同，处置方式也不同。
- 处置按排查结论选择砍范围、补做或重新排期，三种方式可组合，并提前说明各自的风险边界。
- 未完成工作逐项重新评估剩余工作量和优先级，再决定结转、拆分或关闭，不默认整体带入下一迭代。
- 用下一迭代的目标达成率、阻塞停留时长和范围变更次数验证改进，并在规划与回顾中固化检查项。
先确认差距：目标未达成具体差在哪
“目标未达成”是一句结论，排查要从把它还原成事实开始。第一步是统一口径：迭代开始时承诺的目标是什么，实际交付了什么。承诺口径通常来自迭代计划会上确认的需求范围与验收标准，实际交付则以已通过验收的工作项为准。两者之间如果混入了迭代中追加的需求，直接对比总量会失真，需要先把范围变化单独标出来。
接着列一份差距清单，把迭代内所有工作项分成三类：完全未开始或未完成的、部分完成但未达到验收标准的、已完成但验收未通过的。每一类都要写清所属需求、当前状态和卡住的位置。这份清单是后续所有判断的基础，也是回顾会上讨论的事实依据。
最后确认差距落在哪个维度。数量维度指计划内的需求条目没有做完；质量维度指功能交付了但验收标准没有满足，或缺陷数量超出预期；时间维度指关键节点延后，影响了对外承诺的发布时间。三类差距的原因往往不同，混在一起讨论容易得出“就是做得慢”这类无法行动的结论。完成这一步，交付物是一份可核对的迭代目标差距清单，包含承诺范围、实际交付、差异条目和维度归类。
四类常见原因与对应的排除证据
差距清单出来后，按假设—证据的方式逐条验证原因。原因不能凭印象下结论，每一类都要找到对应的记录来支持或排除。下表列出四类常见原因、典型表现和可用于验证的证据来源。
| 原因类别 | 典型表现 | 验证证据 |
|---|---|---|
| 范围在迭代中扩大或需求变更 | 迭代中期新增需求、原有需求验收标准被修改、插入紧急事项 | 迭代内的需求变更记录、计划范围与实际范围的条目对比 |
| 容量估算与实际投入不符 | 成员请假、被抽调支援其他项目、会议占用大量时间 | 计划投入工时与实际工时日志的差异、成员可用天数记录 |
| 执行阻塞 | 依赖的外部接口未就绪、测试环境不可用、评审排队等待 | 阻塞项的标记记录与停留时长、依赖项的完成时间 |
| 验收口径不一致或完成定义模糊 | 开发认为已完成、验收方认为不达标；完成标准在迭代中才明确 | 完成定义文档、验收记录与驳回意见、迭代计划会上的确认记录 |
验证时注意区分主因和伴随现象。范围扩大常常同时带来容量紧张，但两者对处置方式的影响不同：范围问题优先谈砍范围，容量问题优先谈调整计划。如果证据显示某一类原因可以排除，也要记录下来，避免回顾会上重复争论。四类原因都排查过后仍无法解释差距的，再考虑估算方法本身是否系统性偏乐观，这属于下一迭代规划阶段要处理的问题。
按顺序排查：从数据到结论的处置路径
排查按固定顺序推进，可以减少先入为主的判断。第一步看迭代内的范围变更记录与工时投入：对比计划范围与最终范围，确认是否有需求在迭代中被追加或修改；对比计划工时与实际工时日志，确认投入是否与估算匹配。这一步能同时回答范围问题和容量问题。
第二步看阻塞项。找出迭代内被标记为阻塞的工作项，统计每项的停留时长和依赖状态。阻塞停留时间长的项目，往往集中在少数几个外部依赖或环境问题上，这类原因对目标的影响可以直接量化。如果阻塞项很少且停留时间短，执行阻塞就可以基本排除。
第三步核对完成定义与验收记录。检查迭代开始时是否明确了每个需求的验收标准，验收过程中是否有因标准理解不一致导致的反复。如果差距主要来自“做完了但没通过验收”，处置重点应放在统一完成定义，而不是增加投入。
根据排查结论选择处置方式，并注意各自的风险边界：
- 砍范围：适用于范围扩大是主因、且新增内容优先级不高的情况。风险在于对外承诺的交付内容减少，需要提前与相关方沟通，确认哪些内容可以延后。
- 补做：适用于差距集中在少数关键项、剩余工作量可控的情况。风险在于补做会挤占下一迭代的容量，需要同步调整下一迭代的计划范围。
- 重新排期：适用于容量系统性低估或阻塞短期无法解除的情况。风险在于排期调整可能影响下游依赖方的计划，需要明确新的时间点和依赖交接。
三种方式可以组合使用，例如对关键项补做、对低优先级项砍范围、对受外部依赖影响的部分重新排期。处置方案确定后，把结论和依据写入迭代回顾记录，作为下一迭代规划的输入。
未完成工作怎么处理：重新评估而非默认结转
未完成的工作项不能整体平移到下一迭代。默认结转会让下一迭代的范围在开始前就超出容量，也会让低价值事项长期占用资源。正确做法是逐项重新评估，评估两个问题：剩余工作量还有多少，这项工作是否仍然符合当前产品目标。
剩余工作量的评估要基于当前状态，而不是最初的估算。已经完成部分的工作项，重新估算剩余部分；一直未开始的工作项，确认是否还有启动的条件。优先级评估则要回到产品目标：这项工作对应的用户价值或业务目标是否仍然成立，是否有更高优先级的事项需要腾出容量。
评估后按三种方式处理：
- 结转：剩余工作量明确、优先级仍然靠前、下一迭代容量允许时，带入下一迭代并重新估算工时。
- 拆分：工作项过大或部分内容可以先交付时，拆成更小的条目，只把当前需要且能完成的部分带入下一迭代，其余部分回到待办列表重新排序。
- 关闭：目标已变化、价值不再成立或长期无法推进的事项，明确关闭并记录原因，避免反复出现在迭代中消耗讨论成本。
处理结果要形成书面规则并让团队知晓，例如“结转项必须重新估算且不超过下一迭代容量的固定比例”。规则的作用是让每次迭代结束时的处理动作一致，减少临时决策带来的争议。
验证恢复与防止复发
处置方案执行后，用下一迭代的数据验证改进是否生效。主要看三个信号：下一迭代的目标达成率是否回到正常水平；阻塞项的平均停留时长是否下降；迭代内的范围变更次数是否减少。三个指标同时改善，说明排查结论和处置动作方向正确；只有部分改善，则需要回到对应环节继续排查。
预防动作落在两个节点上。规划阶段核对容量与范围基线：把成员可用天数、会议和支援占用扣除后的真实容量作为计划依据，范围确认后冻结变更入口，新增需求走统一的评审流程。回顾阶段固化检查项，把本次排查中验证有效的问题整理成清单，例如“迭代开始前是否确认了每个需求的验收标准”“外部依赖是否已确认就绪时间”，在每次迭代计划会上逐项核对。
在记录与跟进环节，ONES 的迭代管理能力可以承接上述动作：产品负责人可按优先级把需求规划到对应迭代，并在迭代计划会上与团队评审需求与验收标准；需求确认后，设计、研发、测试人员用子任务拆分，便于跟踪；迭代执行中通过敏捷看板管理任务状态，在每日站会中对齐进度与风险；迭代结束后可借助燃尽图、工时日志等报表复盘进度、质量和成本偏差。这些记录正好对应前文排查所需的范围、工时和进度证据，让原因验证有据可查。
常见问题
迭代目标未达成，回顾会上应该先讨论原因还是先处理未完成的工作？
先处理事实和原因，再处理未完成项。回顾会开始时先把差距清单摆出来：哪些项未完成、哪些部分完成、哪些验收未通过，并确认承诺范围与实际范围是否一致。原因排查有了初步结论后，未完成项的处理才有依据——范围扩大导致的目标缺口，和容量低估导致的缺口，对未完成项的取舍判断并不相同。
如果时间有限，可以先用半小时对齐差距清单和主要原因假设，把未完成项的逐项评估放到会后或下一迭代规划前完成，避免在信息不全时匆忙决定结转。
迭代中插入紧急需求导致目标未达成，应该算团队的问题吗？
这属于范围变化类原因，判断重点是插入是否经过评审、是否同步调整了迭代承诺。如果紧急需求确实必要，但插入时没有重新评估容量、也没有和团队确认哪些原计划内容需要延后，那么问题出在变更流程上，而不是执行环节。
处置时优先考虑砍范围：确认新增内容的优先级，把优先级较低的原计划项移出当前迭代，并同步告知相关方交付内容的变化。下一迭代规划时，为紧急事项预留一定比例的容量缓冲，并明确插入需求需要走的评审入口。
团队人数没变，为什么这个迭代的容量明显不够用？
人数不等于可用容量。请假、被抽调支援其他项目、会议和评审占用，都会让实际可投入时间低于按人数推算的数值。排查时对比计划投入工时与实际工时日志，看差异集中在哪些成员和哪些时间段。
如果差异主要来自会议和临时支援，下一迭代规划时应按扣除后的真实可用天数计算容量，并把已知的请假和支援安排提前纳入计划。容量基线一旦确定，范围确认后再新增内容就需要走变更评审，避免计划范围在开始前就超出承载能力。
未完成的工作项在什么情况下应该直接关闭，而不是拆分或结转？
当这项工作对应的用户价值或业务目标已经不再成立，或者长期缺少推进条件、反复出现在迭代中却始终无法启动时，关闭是更合适的选择。关闭时要记录原因，例如目标调整、需求被替代或依赖方取消，让后续查看的人理解为什么不再做。
拆分适用于工作项过大、部分内容可以先交付的情况；结转适用于剩余工作量明确、优先级仍然靠前且下一迭代容量允许的情况。三种方式的选择依据是剩余工作量和当前产品目标，而不是工作项已经投入了多少时间。
改进措施执行后，怎么判断问题真的解决了？
看下一迭代的三个信号：目标达成率是否回到正常水平，阻塞项的平均停留时长是否下降，迭代内的范围变更次数是否减少。三个信号同时改善，说明排查结论和处置动作方向正确；只有部分改善，就回到对应环节继续排查，例如范围变更次数没有下降，说明变更入口的管控还没有落地。
验证周期建议至少覆盖一到两个完整迭代，单个迭代的数据容易受偶发因素影响。验证有效的检查项写入迭代计划会的核对清单，让预防动作成为固定流程的一部分。
