迭代计划被临时需求打乱，团队常凭印象归因：有人觉得是估得太满，有人觉得是变更失控。更可靠的做法是先核对容量基线，再检查变更的准入与记录，用最近两三个迭代的数据把两类原因分开。本文给出一套可执行的诊断与处置路径，适用于单个迭代运行中的范围波动。
要点总览（TL;DR）
- 先看偏差出现的时间点：迭代刚开始承诺量就高于历史完成量，偏向容量估算问题；前期正常、中途插入需求后失守，偏向变更管理问题。
- 再看插入需求是否伴随替换或延后动作：有准入判断和替换机制仍完不成，容量基线需要修正；无记录、无替换，变更管理是主因。
- 两类原因常叠加，处置顺序是先修容量基线、再收紧变更准入，顺序颠倒会让调整互相抵消。
- 用承诺完成率、中途插入需求占比、变更后替换或延后执行率连续观察一两个迭代，单次波动不足以支撑结论。
- 未完成工作重新评估后再决定去向，不默认结转到下一迭代，否则偏差被掩盖，下一轮判断继续失真。
症状与范围：计划被打乱具体表现成什么样
“总被打乱”是一个笼统感受，先把它拆成可观察的症状，才能找到对应的证据。常见的波动有四类，各自的信号不同：
- 承诺量长期完不成：每个迭代结束时都剩下一截工作，且剩余比例稳定出现，说明承诺量与实际可交付能力之间存在系统性差距。
- 中途插入需求：迭代开始后不断有新需求进入当前迭代，团队被迫在原有承诺之外分配时间。
- 范围悄悄扩大：需求条目没有明显增加，但已有需求的验收标准、交互细节或关联任务在迭代中不断加码，工作量在无形中膨胀。
- 迭代末集中返工：前期进度看似正常，最后几天大量任务回到进行中或重新打开，交付质量与计划同时失守。
本文讨论的范围限定在单个迭代运行中的范围波动。迭代结束时未完成的工作需要重新评估优先级和规模，再决定进入哪个迭代，不默认自动结转到下一个迭代，否则偏差会被掩盖，下一轮判断继续失真。
判断需要的最小记录范围包括四项：迭代开始时确认的承诺清单；团队实际可投入的工时或点数；每次变更发生的时间与来源；变更发生后对应的替换或延后动作。这四项记录不需要额外系统，用迭代看板、需求条目和简单的变更日志即可积累。缺少其中任何一项，后续排查都会退回到凭感觉归因。
两类原因假设：容量估算偏高与变更管理失效
把原因直接当结论，是这类问题最常见的误判。更稳妥的方式是先提出假设，再找证据验证或推翻。容量估算与变更管理两类问题留下的证据并不相同。
| 原因假设 | 典型表现 | 可验证证据 | 反证条件 |
|---|---|---|---|
| 容量估算偏高 | 把名义可用时间当实际容量，未扣除会议、支持、休假；估点口径前后不一致；承诺量超出历史交付能力 | 迭代开始时承诺量就高于过去几个迭代的平均完成量；实际投入工时明显低于计划工时；同类需求在不同迭代的估点差异大 | 承诺量处于历史完成区间内，迭代前期进度正常，偏差主要出现在中途插入需求之后 |
| 变更管理失效 | 插入需求没有准入判断；变更未记录影响；没有替换或延后机制；变更决策集中在迭代中途由单方推动 | 中途新增需求数量与占用比例可统计；变更发生时没有对应的移除或延后条目；变更来源集中在少数渠道且无评估记录 | 迭代内几乎没有新增需求，范围变化主要来自原有需求的细化，且完成量仍持续低于承诺 |
两类假设可以同时成立。容量估算偏高的团队，一旦遇到插入需求，缺口会被迅速放大；变更管理失效的团队，即使容量估算合理，也会因为范围持续膨胀而完不成承诺。排查时要区分主因与叠加因素，而不是二选一。
排查顺序：先查容量基线，再查变更记录
排查按固定顺序执行，目的是让每一步的结论都能被下一步的数据检验。
第一步，核对容量基线。取最近两三个迭代的承诺量与实际完成量做对比，重点看偏差出现的时间点。如果迭代刚开始时承诺量就已明显高于历史平均完成量，或者实际投入工时长期低于计划工时，容量估算偏高的可能性较大。这一步用燃尽图的早期走势也能辅助判断：曲线从第一天起就偏离理想线，通常指向起始承诺过高。
第二步，统计变更情况。逐条列出迭代中途插入的需求，记录数量、来源渠道、占用的工时或点数比例，并检查每次插入是否伴随替换或延后动作。插入需求占比高、且多数没有替换动作，变更管理失效的证据就比较充分。
第三步，区分主因与叠加因素。可以用一个简单的分界示例：某迭代承诺 40 点，历史平均完成 32 点，中途插入 10 点需求且未移除任何原承诺，最终完成 30 点。这里起始承诺已超出历史能力，属于容量问题；插入需求未做替换，属于变更问题；两者叠加导致缺口扩大。若起始承诺为 30 点、中途插入 10 点且移除了 8 点原需求，最终仍只完成 28 点，则主因更偏向容量估算与执行效率，变更管理相对可控。
排查中有两类误判需要避免。一是把偶发紧急需求当成常态，用一次异常迭代否定整个计划机制；二是在证据不足时把估算偏差归为团队能力问题，这会掩盖容量口径和变更流程本身的缺陷。判断依据应来自记录，而不是印象。
按判断结果处置：容量修正与变更准入的具体动作
主因不同，处置动作的落点也不同。容量估算为主时，调整的是承诺的起点；变更管理为主时，调整的是范围进入迭代的门槛。
容量估算为主时的动作：
- 按历史交付能力设定承诺上限，例如以过去三个迭代完成量的中位数作为参考基线，而不是按名义可用人力排满。
- 在承诺中预留缓冲，用于吸收支持、会议、缺陷处理等常规消耗，缓冲比例依据历史工时日志确定。
- 统一估点口径，明确同类需求的估算参照物，减少不同成员之间的尺度差异。
变更管理为主时的动作：
- 建立插入需求的准入判断：明确哪些类型可以进入当前迭代，例如影响线上稳定性的紧急修复，其余进入待办列表排队。
- 要求变更时同步说明替换或延后对象，即“进一个、出一个”，保持迭代总量稳定。
- 记录每次变更的决策人、时间、来源和影响评估，让变更可追溯，也为下一轮判断积累数据。
两类问题叠加时，先修容量基线，再收紧变更准入。容量基线不准，变更准入就缺少判断“还有没有余量”的参照；变更记录不完整，容量修正后的效果也无法验证。顺序颠倒容易让调整动作互相抵消。
涉及承诺调整时有明确的风险边界：调整已承诺的范围需要与相关方确认，不能由团队单方面移除；涉及对外交付承诺时，先评估影响范围和替代方案，再执行变更，并保留确认记录作为停止点，避免变更在传递中失真。
在记录与复盘环节，ONES 的迭代规划支持产品负责人按优先级把需求规划到对应迭代，并在迭代计划会议上与团队共同评审；迭代执行中可通过敏捷看板对齐进度与风险，燃尽图用于观察效率走势；迭代回顾时可结合燃尽图、工时日志等报表复盘进度与成本偏差。这些记录正好覆盖排查所需的承诺清单、进度数据和变更痕迹，让容量基线与变更情况的核对有据可查。
验证与复发预防：用下一两个迭代确认判断是否成立
处置是否有效，需要用数据验证，而不是凭一次顺利的迭代下结论。建议观察三个指标：
- 承诺完成率：迭代实际完成量占承诺量的比例，用于检验容量基线是否校准。
- 中途插入需求占比：插入需求占用的工时或点数占迭代总量的比例，用于检验变更准入是否生效。
- 变更后替换或延后执行率：发生变更时同步执行替换或延后动作的比例，用于检验变更机制是否真正落地。
验证周期建议连续观察一两个迭代，对照处置前后的数据变化。单次波动可能来自假期、人员变动或偶发故障，不足以支撑结论；连续两个迭代同向改善，判断才相对可靠。
复发预防的关键是把判断项纳入常规运行。在迭代回顾中固定检查两项内容：容量基线是否仍与历史交付能力匹配，变更记录是否完整、替换动作是否执行。把这两项作为回顾的固定议题，问题刚露头时就能被发现，而不必等到计划再次被打乱。
如果验证后指标没有改善，说明原判断可能不成立，需要回到假设阶段重新检查：容量数据是否统计口径一致，变更记录是否遗漏了来源，或者问题实际出在需求细化不足、依赖阻塞等其他环节。必要时缩小观察范围，先聚焦一个迭代、一个需求类型做对照，再逐步扩大结论的适用范围。
常见问题
迭代刚开始进度正常，中途插入需求后才完不成，还需要查容量吗？
需要，但排查重点不同。这种情况变更管理是主因，容量基线可以作为对照检查：如果起始承诺量本身就在历史完成区间内，容量问题不是主要矛盾，处置应落在插入需求的准入判断和替换机制上。如果起始承诺已接近历史完成上限，插入需求只是把原本就存在的缺口提前暴露，两类问题需要一起处理。
临时需求来自上级或客户，团队没有拒绝的空间，变更管理还怎么做？
变更管理处理的是范围进入迭代的方式，而非拒绝需求本身。可行的做法是把“接不接”转为“换什么”：需求进入当前迭代时，同步明确被替换或延后的原承诺条目，保持迭代总量稳定；同时记录变更的决策人、来源和影响，让后续复盘有据可查。涉及对外交付承诺时，先评估影响范围和替代方案，再执行变更并保留确认记录。
团队规模小、没有专职项目经理，这套排查会不会太重？
排查所需的最小记录只有四项：迭代承诺清单、实际投入工时或点数、变更发生时间与来源、变更后的替换或延后动作。小团队用迭代看板加一份简单的变更日志即可积累，不需要额外系统。观察周期也可以缩短，先聚焦一个迭代、一类需求做对照，结论成立后再扩大范围。
容量基线按历史完成量设定后，遇到假期或人员变动怎么办？
容量基线是参考值，需要按迭代实际情况调整。假期、人员变动、支持类工作都会压缩实际可投入时间，应在承诺时从基线中扣除，而不是沿用上一个迭代的数字。缓冲比例依据历史工时日志确定，调整后的承诺量仍要与团队确认，避免把参考基线当成固定配额。
用工具记录变更，需要记录到什么颗粒度？
记录到能支撑判断即可：变更发生的时间、来源渠道、涉及的需求条目、占用的工时或点数，以及对应的替换或延后对象。ONES 的迭代规划支持产品负责人按优先级把需求规划到对应迭代，并在迭代计划会议上与团队共同评审；迭代执行中可通过敏捷看板对齐进度与风险，燃尽图用于观察效率走势；迭代回顾时可结合燃尽图、工时日志等报表复盘进度与成本偏差。这些记录覆盖了排查所需的承诺清单、进度数据和变更痕迹。
