迭代目标未达成，很少是单一原因造成的。常见情况是规划时容量估高、迭代中范围被临时插入、执行中阻塞没有及时暴露、验收标准又不够清楚，几项叠加后目标才落空。要找到真实原因，需要先把“没达成”拆成可核对的事实，再按规划、执行、验收、外部四类逐项找证据，区分已证实原因与仍属猜测的部分，最后针对确认的原因安排处置并验证恢复。ONES可在迭代目标、工作项状态与阻塞记录之间提供统一的跟踪入口，方便对照排查。
要点总览（TL;DR）
- 迭代目标未达成通常是规划、执行、验收、外部四类原因叠加的结果，诊断前先把差距拆成范围、质量、时间三类可核对的事实。
- 原因排查先列假设再找证据：容量与实际投入对比、迭代中变更统计、验收标准与评审退回记录、阻塞等待时长，证据不足的标注待确认。
- 未完成工作逐条重新评估优先级与必要性，再决定纳入下个迭代、退回需求池或标注等待条件，不默认自动结转。
- 处置按原因分类：变更准入规则、按实际投入重估容量、补齐完成定义与自检、阻塞设责任人与升级时限；调整承诺目标需相关方确认。
- 用承诺完成率、范围变更次数、阻塞平均处理时长、评审退回项数量验证恢复，并把改进项纳入下个迭代规划检查清单。
先界定差距：目标未达成具体差在哪里
诊断的第一步是把笼统的“没达成”转成可核对的事实。同一个迭代目标未达成，可能表现为计划内条目没做完，也可能表现为条目做完了但质量不达标，还可能是范围和质量都达标但时间延后。三类症状对应的原因方向不同，混在一起讨论容易各说各话。
界定差距时先确认对比口径。以迭代开始时承诺的Sprint Backlog和目标为基准，还是以中途调整后的版本为基准，结论会完全不同。如果迭代中目标被正式调整过，应同时保留原始承诺和调整后版本两份记录，分别说明差距。口径不统一时，先统一口径再排查原因。
差距清单建议按以下结构记录：
| 症状类型 | 判断标准 | 需记录的信息 |
|---|---|---|
| 范围差距 | 计划内条目未完成 | 未完成条目清单、各自完成进度、剩余工作量 |
| 质量差距 | 条目已完成但未达验收标准 | 未达标准条目、具体缺失项、评审退回记录 |
| 时间差距 | 目标内容延期交付 | 延期天数、延期影响的上下游或交付节点 |
清单完成后应能回答三个问题：差了多少条目、差在哪些具体条目上、差距影响了谁。这份清单是后续所有原因排查的基准，排查过程中不再反复改变对“差距”的定义。
按规划、执行、验收、外部四类列原因假设
原因排查容易犯的错误是先有结论再找理由，比如直接归因为“团队执行力不够”或“需求太多”。更稳妥的做法是先列出可能的原因假设，每条假设附上可观察的迹象，再用证据逐项验证。以下四类覆盖了迭代目标未达成的主要方向。
规划类假设
- 容量估算偏高：排期时按理想工时估算，未扣除会议、支持、休假等实际占用。迹象是迭代前期进度正常、后期集中延期。
- 目标超出产能：承诺条目总量明显大于团队历史平均完成量。迹象是迭代一开始就存在大量未启动条目。
- 任务拆解过粗：大颗粒任务掩盖了实际工作量，执行中才发现远比预想复杂。迹象是某几条任务长期停留在进行中。
- 依赖未识别：条目依赖其他团队交付或前置条件，规划时未标注。迹象是条目在等待外部输入时停滞。
执行类假设
- 范围临时插入：迭代中新增需求或插入高优先级事项，挤占原计划容量。迹象是迭代中工作项数量净增。
- 需求变更未受控：已启动条目的要求中途改变，导致返工。迹象是同一条目多次修改描述或验收条件。
- 每日跟进未暴露阻塞：站会流于形式，成员遇到困难未及时上报。迹象是阻塞在迭代后期才集中出现。
- 人员可用性变化：关键成员请假、被抽调或同时承担多项事务。迹象是特定成员负责的条目集中停滞。
验收类假设
- 完成定义不清：团队对“做完”的理解不一致，开发认为完成、验收方认为未完成。迹象是评审时频繁出现口径争议。
- 验收标准缺失：条目缺少明确的验收条件，评审时才发现遗漏。迹象是评审退回项集中在需求理解偏差上。
- 评审时才发现不达标：过程中缺少自检环节，问题积压到评审暴露。迹象是评审退回项数量明显偏高。
外部类假设
- 等待决策：关键方案或优先级需要上级确认，等待期间工作停滞。迹象是条目长期处于待确认状态。
- 环境或数据未就绪：测试环境、依赖系统或数据准备延迟。迹象是开发完成但无法验证。
- 跨团队配合延迟：接口联调、上游交付等依赖方响应慢。迹象是阻塞项等待时长明显超过预期。
用证据排除假设：每类原因怎么验证
列出假设之后，关键是给每条假设找到支持或排除的证据。验证时按“规划—执行—验收—外部”的顺序推进，因为规划偏差往往会放大执行和验收环节的问题。证据不足的假设应标注为待确认，不能直接写成确定原因。
| 原因类别 | 验证证据 | 判定方式 |
|---|---|---|
| 规划类 | 承诺容量与实际投入工时对比；任务拆解粒度记录；依赖标注情况 | 实际投入显著低于承诺容量，或大颗粒任务占比高，支持规划偏差假设 |
| 执行类 | 迭代中新增与变更条目统计；站会记录；阻塞项从提出到解决的时长 | 净增条目挤占容量、阻塞处理时长偏长，支持执行失控假设 |
| 验收类 | 完成定义与验收标准文档；评审记录中的退回项及原因 | 退回项集中指向标准缺失或理解偏差，支持验收问题假设 |
| 外部类 | 阻塞项清单及等待时长；决策与配合方的响应记录 | 等待时长超出约定时限且非团队可控，支持外部阻塞假设 |
验证时注意两点。其一，同一症状可能对应多条假设，比如“条目停滞”既可能是依赖未识别，也可能是人员可用性变化，需要看停滞条目的具体归属和等待对象。其二，区分相关与因果：迭代中确实发生了范围插入，但如果插入条目体量很小、原计划条目本身也未完成，范围插入就不是主因，主因应回到规划或执行环节继续查。
验证结束后形成一份原因结论：每条假设标注“支持”“排除”或“待确认”，支持的原因写明证据来源，待确认的原因写明还缺什么信息、由谁补充。这份结论是后续处置的依据，避免处置动作建立在猜测之上。
在证据收集环节，如果迭代目标、工作项状态、阻塞记录分散在不同表格和聊天记录里，对照成本会很高。ONES的迭代管理支持将迭代目标与工作项关联，工作项状态变更和阻塞标记在同一处留痕，评审退回项也可随工作项记录，便于按上述四类逐项调取证据。是否引入工具承载这些记录，取决于团队当前记录是否完整；记录本身缺失时，先补记录习惯比换工具更优先。
针对已确认原因的处置步骤
处置应针对已证实的原因展开，未确认的假设先补证据再决定是否行动。以下动作按原因类别列出，涉及调整已承诺目标时，需与相关方确认，避免单方面变更。
未完成工作的安排
未完成条目不应默认自动结转到下一迭代。逐条重新评估优先级与必要性：仍然必要的条目，评估剩余工作量后纳入下个迭代规划，并说明占用多少容量；优先级下降或价值已变化的条目，退回需求池重新排序；因外部条件短期无法推进的条目，标注等待条件与责任人。评估结果形成书面记录，作为下个迭代规划的输入。
范围失控的处置
建立迭代内变更的准入规则：明确哪些情况允许插入、由谁审批、插入后需要移出哪些等量工作。每次变更留下记录，包括变更内容、原因、审批人和对容量的影响。规则的作用是让变更可见可控，而非禁止变更。
规划偏差的处置
下个迭代按实际投入重估容量，用历史完成数据替代理想估算，并预留会议、支持等非开发时间。承诺范围相应缩小，宁可少承诺、按承诺交付。任务拆解细化到可判断工作量的粒度，依赖关系在规划阶段标注清楚。
验收问题的处置
补齐完成定义与验收标准，条目启动前确认验收条件。评审前安排自检环节，由条目负责人对照标准逐项核对，减少评审阶段的退回。评审退回项记录原因，作为标准完善的输入。
阻塞的处置
每个阻塞项明确责任人与升级路径，设定等待时限。超过时限未解决的，按升级路径上报，避免阻塞在团队内部静默积压。跨团队依赖在规划阶段约定交付时间，迭代中跟踪响应情况。
验证恢复与防止复发
处置是否生效，需要在下个迭代用指标验证，而不是凭感觉判断“这次好多了”。建议跟踪以下指标，并与问题迭代及此前几个迭代对比：
- 承诺完成率：下个迭代承诺条目中按期完成的比例，反映规划准确度与执行稳定性。
- 范围变更次数：迭代中新增、移出、变更条目的次数，反映变更控制是否生效。
- 阻塞平均处理时长：阻塞项从提出到解决的平均时间，反映外部配合与升级机制的效果。
- 评审退回项数量：评审阶段退回的条目数及原因分布，反映验收标准与自检环节的质量。
指标改善需要观察至少一个完整迭代，单次波动不足以说明问题已解决。若某项指标没有改善，回到对应原因类别重新验证，检查处置动作是否真正执行、执行中是否遇到新条件。
在迭代回顾中复盘已确认原因，形成可执行的改进项并指定负责人和完成时间。改进项要具体到动作，比如“下个迭代规划时按近三个迭代实际完成量确定承诺容量”，而非“提高估算准确性”这类无法验证的表述。
复发预防的关键是建立迭代中的早期信号：容量使用偏差在迭代中期就应被察觉，阻塞积压超过设定时限即触发升级，变更频率异常时及时评估对目标的影响。把这些检查项纳入下个迭代的规划检查清单，在规划会上逐项确认，让上一次的诊断结论转化为下一次的规划动作。ONES的迭代看板与工作项状态流转可用于持续观察这些信号，具体采用何种跟踪方式，仍以团队已有的记录习惯和协作节奏为准。
常见问题
迭代中目标被正式调整过，诊断时应该以哪个版本为基准？
建议同时保留原始承诺和调整后版本两份记录，分别说明差距。以原始承诺为基准，能看出目标偏移的幅度和原因；以调整后版本为基准，能判断调整后的目标是否达成。两个口径的结论都要写进差距清单，并在排查原因时注明本次诊断采用哪个口径，避免讨论中反复切换标准。
多条原因假设都找到了一些迹象，怎么判断哪条是主因？
先看证据强度：有完整记录支撑的假设优先于仅凭印象的假设。再看影响量级，比如范围插入确实发生，但插入条目体量很小、原计划条目本身也未完成，范围插入就不是主因，应回到规划或执行环节继续查。还可以看时间顺序，规划偏差往往在迭代前期就埋下，执行和验收问题多在中期以后显现。无法区分时标注为多因叠加，分别安排处置动作。
未完成的工作直接放到下个迭代继续做，有什么问题？
直接结转会让下个迭代的承诺容量被旧工作占满，新目标难以排入，也容易掩盖原迭代的真实问题。更稳妥的做法是逐条重新评估：仍然必要的条目评估剩余工作量后纳入规划并说明占用容量；优先级下降或价值变化的条目退回需求池重新排序；受外部条件限制的条目标注等待条件与责任人。评估结果形成书面记录，作为下个迭代规划的输入。
团队记录不完整，证据收集做不起来怎么办？
先补记录习惯，再谈工具。可以从下个迭代开始固定几项最小记录：迭代开始时承诺的条目与容量、迭代中每次范围变更的内容与审批人、阻塞项的提出与解决时间、评审退回项及原因。这些记录积累一到两个迭代后，原因验证就有据可查。如果记录分散在多个表格和聊天记录里，对照成本高，可以考虑用统一的工作项与迭代跟踪入口承载，但记录本身缺失时，换工具并不能替代补习惯。
处置动作执行后，多久能判断问题已经解决？
建议至少观察一个完整迭代，单次波动不足以说明问题已解决。对比问题迭代与此前几个迭代的承诺完成率、范围变更次数、阻塞平均处理时长、评审退回项数量。若某项指标没有改善，回到对应原因类别重新验证，检查处置动作是否真正执行、执行中是否遇到新条件。指标改善后仍需在回顾中确认改进项已固化为规划检查清单中的动作，防止下一个迭代复发。
