迭代进行到一半，突然插入一个“紧急需求”，或者原有需求被要求“顺手扩大一点”，都会让团队对本周期的交付承诺产生怀疑。处理这类问题，先要区分正常的需求澄清与已经发生的范围蔓延，再依据变更记录、容量占用和决策过程判断原因，按登记、评估、决策、调整、同步的路径处置，最后用迭代目标达成情况和未完成项重新评估来验证是否恢复。
要点总览（TL;DR）
- 先区分需求澄清与实质范围变更：改动是否改变“本迭代要交付什么”，改变就走变更流程。
- 原因排查按顺序推进：先看变更来源与频率，再对比容量与估算，最后检查优先级决策机制，每步都用记录类证据验证。
- 处置按登记、影响评估、决策取舍、调整计划、同步相关角色五步完成，涉及已承诺交付或跨团队依赖时先评估再动。
- 处置后用迭代目标可达性、容量占用和变更登记完整性验证恢复；未完成工作按价值与依赖重新评估后再排期，不默认结转。
- 预防靠四条规则：变更准入条件、迭代冻结时点、容量缓冲和固定的优先级评审节奏。
迭代范围变更通常表现为什么症状
范围变更在迭代中并不罕见，真正需要干预的是那些改变了迭代目标或超出团队容量的改动。判断时不要只看“有没有新需求进来”，而要看改动是否影响了本迭代已承诺的交付内容。以下症状可以作为识别起点。
| 症状 | 具体表现 | 主要影响对象 |
|---|---|---|
| 迭代中新增需求 | 迭代开始后，有需求被直接加入当前 Sprint Backlog，未经过计划会议评审 | 迭代目标、容量、Sprint Backlog 条目 |
| 需求被放大 | 原条目在开发过程中追加功能点、扩大数据范围或增加端侧适配 | 容量占用、交付时间、测试范围 |
| 验收标准变化 | 开发接近完成时，验收条件被修改或补充，导致已完成工作需返工 | 交付承诺、评审结论、返工工时 |
| 优先级被外部改写 | 非产品负责人角色直接调整条目顺序，团队被迫切换工作重心 | 迭代目标、Sprint Backlog 顺序、团队节奏 |
| 依赖方临时变更接口 | 上游团队调整交付内容或时间，本迭代工作需重新适配 | 依赖关系、联调计划、交付承诺 |
影响范围可以从四个对象逐一核对。迭代目标是首要判断依据：如果改动使原目标无法达成，就属于实质变更。容量占用看团队剩余工时是否被新增工作挤占，尤其是关键角色是否已经满负荷。Sprint Backlog 条目看是否有条目被替换、拆分或删除，以及这些动作是否留有记录。评审与交付承诺则看对外承诺的时间点、范围和验收口径是否发生变化。
需要区分两类情况。一类是可接受的澄清：需求描述中的歧义被消除，验收标准的表述更精确，实现方式在原有目标内调整，工作量变化在团队可吸收的缓冲范围内。这类澄清通常由团队内部消化，记录在条目备注中即可。另一类是实质变更：新增了原计划外的工作内容，扩大了交付范围，或者改变了迭代目标本身。实质变更应进入变更流程，经过影响评估和决策，而不是由提出人直接推动落地。判断标准可以简化为一句：改动是否改变了“本迭代要交付什么”，改变了就走流程，没改变就按澄清处理。
范围变更的原因假设与排除证据
范围变更的原因往往被归结为“需求方太急”，但这个结论缺少证据支撑。更稳妥的做法是先列出假设，再用记录类证据逐项验证，避免把猜测当成原因。常见假设及对应证据如下。
| 原因假设 | 验证证据 | 判断要点 |
|---|---|---|
| 需求澄清不足 | 变更记录中条目的原始描述、验收标准版本、提出澄清的时间点 | 若多数变更发生在开发中后期且集中在验收标准，说明规划阶段澄清不充分 |
| 外部紧急插入 | 需求来源、提出人、提出时间、是否经过优先级评审 | 若变更集中在少数外部角色且绕过评审，属于插入渠道问题 |
| 估算与容量偏差 | 计划工时与实际工时对比、团队可用人力变化、请假与支持性工作记录 | 若变更伴随大面积延期而非新增条目，更可能是估算或容量问题 |
| 依赖阻塞导致返工 | 阻塞时长记录、依赖方交付时间、返工条目清单 | 若返工集中在跨团队接口附近，需先解决依赖协同 |
| 优先级治理缺失 | 优先级调整记录、决策人、调整频率 | 若优先级在迭代内被频繁改写且无决策记录，属于治理机制问题 |
排查顺序建议从变更来源与频率入手。先统计本迭代内变更的次数、提出人和提出时间分布，判断是单点插入还是持续性流入。这一步能快速区分“偶发事件”和“渠道失控”。接着看容量与估算：把计划工时、实际工时和可用人力放在一起对比，确认团队是否在满负荷状态下承接了额外工作。最后看流程与决策机制：变更是否有登记、是否经过评估、由谁拍板、是否留下记录。这个顺序的好处是先处理可量化的事实，再讨论机制问题，避免一上来就归因于“流程不规范”而缺少依据。
验证时要注意证据的完整性。变更记录如果只记了“加了什么”，没有记“为什么加、谁提出的、影响了哪些条目”，排查就会退回猜测。因此日常就需要保留提出人、期望时间、影响条目和决策结论这几项信息。对于依赖阻塞类原因，阻塞时长和返工条目要能对应上，否则无法区分是依赖问题还是估算问题。
按变更请求类型安排处置步骤
确认属于实质变更后，按登记、评估、决策、调整、同步五步推进。每一步都有明确的产出，避免变更在口头沟通中流失或反复。
第一步，登记。记录变更来源、提出人、期望完成时间、涉及的需求条目和变更内容描述。登记的目的不是增加审批层级，而是让后续评估有据可查。登记时同步标注该变更与当前迭代目标的关系：是支撑原目标，还是引入了新目标。
第二步，影响评估。从四个维度评估：对迭代目标的影响，判断原目标是否仍可达成；对容量的影响，估算新增或扩大部分所需工时，并对照团队剩余可用工时；对依赖的影响，确认是否涉及跨团队接口、联调窗口或外部交付节点；对交付承诺的影响，核对对外承诺的范围和时间是否需要调整。评估结论应写成可比较的选项，例如“接受则目标调整为 A，推迟则本迭代目标不变”。
第三步，决策与取舍。明确决策人，通常是产品负责人与团队共同确认，涉及跨团队资源时需相关方参与。决策结果限定为四类：接受并调整计划、推迟到后续迭代、拆分后部分纳入、替换掉当前迭代中优先级更低的条目。每类结果都要写清取舍依据，尤其是替换时说明被替换条目的去向。决策记录保留在变更条目上，便于回顾时追溯。
第四步，调整。根据决策更新 Sprint Backlog，包括新增、拆分、移除条目，重新分配负责人，调整验收标准。调整后重新核对迭代目标表述，确保目标与当前条目一致。
第五步，同步。通知受影响的角色，包括测试、设计、依赖方和对外承诺的相关人。同步内容包含变更内容、决策结论、对交付时间的影响和下一步安排。
风险边界需要提前交代。涉及已对外承诺的交付内容时，先完成影响评估再动计划，避免先改后补造成承诺失信。涉及跨团队依赖时，先与依赖方确认接口和时间，再调整本团队条目，防止单方面变更引发联调失败。如果评估发现变更会导致迭代目标整体失效，应暂停调整，回到迭代目标层面重新决策，而不是在条目层面反复修补。在记录环节，ONES 的迭代规划与看板能力可以承载需求条目、子任务拆分和状态跟踪，变更登记与决策结论可随条目一并保留，便于后续回顾时对照。
如何验证恢复并减少再次发生
处置完成后，需要确认迭代是否回到可控状态。验证信号包括三项：迭代目标是否仍可达成，用剩余条目和剩余工时对照判断；容量占用是否回到可控区间，看关键角色是否仍有缓冲吸收突发工作；变更是否按流程登记，抽查本迭代变更条目是否都有来源、评估和决策记录。三项中若有一项不成立，说明处置尚未闭环，需要回到决策环节重新取舍。
未完成工作需要重新评估，而不是默认结转到下个迭代。具体做法是：先按价值判断条目是否仍值得做，再按依赖关系确认排入顺序，最后在下个迭代规划时与其他候选需求一起比较。默认自动结转会把本迭代的范围问题带入下个迭代，掩盖容量与估算的真实偏差。重新评估的产出是明确的去向：进入下个迭代、回到待办列表等待排序，或关闭。
复发预防可以从四条规则入手。明确变更准入条件，写清哪些类型的变更可以直接澄清、哪些必须走登记评估。设定冻结时点，例如迭代最后若干天只接受影响交付承诺的紧急变更，其余进入下个迭代。保留容量缓冲，在迭代规划时预留一定比例的可用工时应对插入和返工，缓冲比例根据历史变更频率确定。固定优先级评审节奏，把优先级调整集中到规划会议或固定的评审窗口，减少迭代内的临时改写。迭代回顾时，用燃尽图、工时日志等数据对照计划与实际，复盘变更次数、来源分布和容量偏差，把有效的规则写入下个迭代的工作约定。
常见问题
迭代中途插入紧急需求，团队应该先做什么？
先登记，再评估，不要直接开工。登记时记录提出人、期望时间、涉及条目，并标注它与当前迭代目标的关系。随后评估对迭代目标、剩余容量、依赖和对外承诺的影响，把结论写成可比较的选项，例如“接受则目标调整为 A，推迟则本迭代目标不变”。由产品负责人与团队共同决策，结果限定为接受、推迟、拆分或替换四类之一。涉及已对外承诺的交付时，先完成评估再调整计划。
需求澄清和范围变更的界限怎么划？
看改动是否改变了“本迭代要交付什么”。消除描述歧义、把验收标准表述得更精确、在原有目标内调整实现方式，且工作量在团队缓冲范围内，属于澄清，记录在条目备注中即可。新增原计划外的工作、扩大交付范围或改变迭代目标本身，属于实质变更，应进入登记与评估流程。边界模糊时，以迭代目标是否仍可达成作为最终判断依据。
变更被接受后，被替换掉的条目怎么处理？
决策时就要写清被替换条目的去向，避免它在迭代中无声消失。常见去向有三种：回到待办列表等待重新排序、排入后续迭代、直接关闭。无论哪种，都应在变更记录中保留取舍依据，便于迭代回顾时核对范围变化与容量偏差。被替换条目如果仍具价值，下个迭代规划时应与其他候选需求一起比较，而不是默认优先恢复。
迭代结束后未完成的工作可以直接带到下个迭代吗？
建议重新评估后再安排。先按价值判断条目是否仍值得做，再按依赖关系确认排入顺序，最后在下个迭代规划时与其他候选需求一起比较。默认自动结转会把本迭代的范围问题带入下个迭代，掩盖容量与估算的真实偏差。重新评估的产出是明确去向：进入下个迭代、回到待办列表等待排序，或关闭。
怎样判断范围变更处置是否已经生效？
看三项信号：迭代目标是否仍可达成，用剩余条目与剩余工时对照；容量占用是否回到可控区间，关键角色是否仍有缓冲吸收突发工作；本迭代的变更是否都有来源、评估和决策记录。三项中有一项不成立，说明处置尚未闭环，需要回到决策环节重新取舍，而不是在条目层面继续修补。
