迭代进行到一半，突然插入一个紧急需求，或者发现原定工作量根本做不完，团队按什么条件判断要不要调整范围、由谁拍板、调整后怎么记录？本文给出一份虚构团队的迭代范围调整规则填写示例，覆盖触发条件、分级审批、容量核算、变更记录和未完成工作处理，并逐项解释填写理由，帮助读者判断哪些结构可以迁移到自己的团队。
要点总览（TL;DR）
- 迭代范围调整规则应覆盖新增需求、需求变更、容量不足、外部阻塞四类场景，并包含触发条件、分级审批、容量核算、变更记录、未完成工作处理六个部分。
- 示例按影响程度分三级：微调直接确认、替换需等量移出并审批、目标变更需团队确认，分级阈值应参考团队历史调整分布设定。
- 容量核算以替换为默认原则，新增一项须移出等量工作，净增仅在剩余容量存在时允许并设上限，容量口径需在规划时统一。
- 未完成工作不默认结转，需在评审会上逐项重新评估是否仍需要、优先级与估算是否变化，再决定重新排入、退回待办或关闭。
- 规则骨架可迁移，分级阈值、审批人、容量口径需按团队调整；规则不能替代迭代目标本身的澄清。
示例要解决什么问题：迭代范围调整的填写目标
这份示例要交付的是一份可以直接参照填写的规则文档，回答团队在迭代中出现范围变动时的操作问题：什么情况算需要调整、调整分几档、谁有权决定、调整后留下什么记录、没做完的工作怎么处理。规则的目标是让范围调整从口头协商变成有据可查的团队约定，减少迭代末期因范围蔓延导致的目标失焦。
需要说明的是，本文中的团队、角色、数字均为虚构情景，用于演示规则文档的填写方式，不代表任何真实客户案例或实测效果。读者可以把它当作模板骨架，替换成自己团队的实际参数。
示例覆盖四类调整场景：
- 新增需求：迭代目标之外的新工作被要求插入当前迭代。
- 需求变更：已纳入迭代的需求在范围、验收标准或优先级上发生变化。
- 容量不足：成员请假、故障支援等原因导致可用工时低于计划。
- 外部阻塞：依赖的接口、数据或第三方交付延迟，导致原定工作无法推进。
示例产出的规则文档包含六个部分：适用范围与角色、触发条件与调整分级、审批角色与决策时限、容量核算与替换原则、变更记录字段、未完成工作的重新评估方式。这六个部分构成一份完整规则的最小集合，缺任何一项都会让规则在执行时留下模糊地带。
完整示例：一份迭代范围调整规则怎么填
以下为示例团队已填写的规则全文。示例背景设定：一个 7 人产品研发小组，包含产品负责人 1 名、开发 4 名、测试 1 名、设计 1 名；采用两周固定周期迭代；每迭代开始时确定一个迭代目标并锁定 Sprint Backlog。以下内容均为示例填写，供参照。
一、适用范围与角色
本规则适用于迭代启动会之后、迭代评审之前发生的所有范围变动。相关角色及职责：产品负责人负责判断需求价值与优先级；迭代目标负责人（示例中由产品负责人兼任）负责对二级及以上调整做最终决策；开发负责人负责核算容量影响；全体成员负责提出变更并确认记录完整。
二、触发条件与调整分级
| 级别 | 触发条件 | 示例判断标准 | 处理方式 |
|---|---|---|---|
| 一级：微调 | 单个需求的工作量变化在 0.5 人日以内，且不影响迭代目标 | 如验收标准补充、字段增减 | 开发负责人确认后直接调整，当日记录 |
| 二级：替换 | 新增或变更工作量超过 0.5 人日，或影响迭代内某个功能交付 | 如插入一个中等规模需求 | 需移出等量工作，迭代目标负责人审批 |
| 三级：目标变更 | 变动导致迭代目标本身需要修改，或累计替换超过迭代总容量的 20% | 如核心功能被整体推迟 | 迭代目标负责人发起，团队确认后重述迭代目标 |
三、审批角色与决策时限
一级调整由开发负责人确认，无需等待审批，但须在当日结束前完成记录。二级调整由迭代目标负责人在收到申请后 1 个工作日内给出决定，决定选项为同意替换、推迟到下个迭代、拒绝。三级调整由迭代目标负责人发起，需在团队站会上说明原因并取得团队确认，决策时限为 2 个工作日。超时未决策的申请默认推迟到下个迭代评估，不自动进入当前迭代。
四、容量核算与替换原则
容量以迭代内剩余可用人日为口径核算。示例中，两周迭代按每人 8 个可用人日估算，扣除已排期工作后得到剩余容量。替换原则为：新增一项工作，须移出工作量相当的一项已排期工作，移出项回到待办列表并标注原因。净增工作仅在剩余容量确实存在且迭代目标负责人同意时允许，且净增总量不超过迭代总容量的 10%。
五、变更记录字段
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 提出人 | 发起调整的成员姓名 | 产品负责人 |
| 提出日期 | 申请发起的日期 | 迭代第 5 个工作日 |
| 调整类型 | 新增、变更、容量不足、外部阻塞 | 新增 |
| 调整级别 | 一级、二级、三级 | 二级 |
| 原因 | 业务背景与紧迫性说明 | 客户反馈的合规字段缺失，影响上线验收 |
| 影响评估 | 涉及的工作项、工作量、对迭代目标的影响 | 新增约 1.5 人日，需移出同等规模的报表优化项 |
| 决策 | 同意替换、推迟、拒绝及决策人 | 同意替换，迭代目标负责人 |
| 决策日期 | 给出决定的日期 | 迭代第 6 个工作日 |
六、未完成工作的重新评估
迭代结束时未完成的工作不默认结转到下个迭代。每项未完成工作需在评审会上重新评估：确认是否仍然需要、优先级是否变化、原估算是否偏差过大。评估结论分为三类：重新排入下个迭代待办并重新估算、退回待办列表等待排期、关闭并记录原因。重新排入的工作需在下个迭代规划时与其他需求一起参与优先级排序，不因“上次没做完”而自动获得优先位置。
逐项解释：每个字段为什么这样填
规则的价值在于每条设定背后有可解释的判断逻辑。以下逐项说明示例中关键条目的填写理由，读者理解逻辑后可以按自己团队的情况重新设定参数，而不是照抄文字。
触发条件为什么按影响程度分级，而不是一刀切
如果所有调整都走同一套审批，团队会在小事上消耗决策精力，在大事上反而因为流程疲劳而放松把关。示例按工作量和对迭代目标的影响分为三级，让微调快速通过、让影响目标的变化获得足够关注。分级的阈值（0.5 人日、20%）是示例参数，实际填写时应参考团队历史迭代中调整的分布来确定，阈值过严会让规则被绕过，过松则失去筛选作用。
审批角色为什么与迭代目标负责人绑定
范围调整的本质是在“做新的事”和“守住迭代目标”之间取舍，做这个取舍的人必须对迭代目标负责。示例把二级、三级的决策权交给迭代目标负责人，而不是交给职位更高但与当前迭代目标无关的人，是为了让决策者对取舍结果承担责任。如果团队中产品负责人与迭代目标负责人是不同角色，规则中应明确两者在调整申请中的分工：谁提价值判断，谁做最终取舍。
容量核算为什么以替换为主、净增为辅
迭代容量在规划时已经分配完毕，新增工作必然挤占原有工作。以替换为默认原则，迫使提出方说明“为了做这件事，我们不做哪件事”，把取舍显性化。净增只在剩余容量确实存在时允许，并设置 10% 的上限，防止“都很重要”式的范围膨胀。容量口径（示例为每人 8 个可用人日）需要团队在规划时统一，否则替换是否等量无法判断。
未完成工作为什么重新评估，而不是默认结转
默认结转会让待办列表不断累积未验证的工作，下个迭代的规划被历史包袱占据，优先级判断失真。重新评估要求团队对每项未完成工作回答“还要不要、急不急、估算准不准”，把结转变成一次主动决策。这一做法与迭代评审回顾配合使用效果更好：评审会上确认工作状态，回顾会上分析未完成的原因是否指向估算方法或外部依赖问题。
记录字段如何支撑评审回顾
示例中的八个记录字段不是为记录而记录。提出日期与决策日期可以反映审批时限是否被遵守；调整类型与级别的分布可以看出范围变动的来源结构；影响评估与决策的对应关系可以在回顾时检验取舍是否合理。当团队在回顾会上讨论“这个迭代为什么没达成目标”时，这些字段提供了可追溯的事实依据，而不是依赖记忆复述。
规则落地时，变更记录需要依附在工作项和迭代上才能被持续使用。在 ONES 中，迭代内的需求变更可以通过工作项的状态流转和属性字段留下痕迹，调整记录与迭代评审共用同一套工作项数据，回顾时可以直接按迭代筛选查看变更历史，减少另行维护表格的成本。这一衔接适用于已经把迭代和工作项放在同一系统中管理的团队。
可迁移规律：换团队时哪些结构可以保留
示例中的具体数字和角色名称属于虚构团队的设定，但规则的整体骨架与团队规模关系不大，可以直接保留。需要按团队情况调整的是参数和责任人，而不是结构本身。
| 部分 | 处理方式 | 说明 |
|---|---|---|
| 触发条件、分级、审批、记录、复盘五个环节 | 保留 | 构成范围调整的完整闭环，缺一环规则就会在执行中失效 |
| 分级阈值（工作量、容量占比） | 调整 | 按团队历史调整分布和迭代周期长度重新设定 |
| 审批人设置 | 调整 | 按团队角色分工确定谁对迭代目标负责 |
| 容量口径（人日估算方式） | 调整 | 与团队规划时的估算单位保持一致 |
| 记录字段清单 | 基本保留 | 可增减字段，但提出人、原因、影响、决策、日期五项建议保留 |
规则还需要与迭代目标和 Sprint Backlog 衔接。填写时应在规则开头写明本规则服务于哪个迭代目标，并说明调整申请针对的是 Backlog 中的哪些工作项。这样在判断“是否影响迭代目标”时有明确参照，而不是凭感觉判断。规则文档本身建议放在团队可共同访问的位置，与迭代规划、评审回顾的记录放在一起，形成可追溯的迭代管理链条。
适用边界：这套示例在什么情况下要改
这份示例适用于采用固定周期迭代、每个迭代有明确目标的团队。规则的前提是迭代目标在启动时已经澄清，团队对容量有基本估算能力，且调整申请能够被及时提出。如果这些前提不成立，规则本身无法解决范围失控的问题，需要先补上目标澄清和估算实践。
以下情形需要对示例做针对性调整：
- 需求来源高度不稳定：如果外部需求持续高频插入，二级调整的 1 个工作日决策时限和替换原则可能造成频繁返工，需要提高分级阈值或设置固定的插入窗口。
- 外部依赖占比高：当迭代内大量工作依赖第三方交付时，外部阻塞应单独设为一类触发条件，并明确阻塞发生后的责任人和升级路径，而不是混在容量不足里处理。
- 团队规模明显不同：人数较多的团队审批链条需要更明确的分工，人数较少的团队可以合并一级和二级的确认环节，但记录要求不建议省略。
- 未完成工作处理与评审机制脱节：如果团队没有稳定的迭代评审和回顾节奏，重新评估环节容易流于形式，需要先把评审回顾固定下来再执行本规则。
规则不能替代迭代目标本身的澄清。一份写得再完整的调整规则，也只能在目标清晰的前提下判断什么该调整、什么不该调整。填写规则时，建议把“本迭代目标是什么”作为文档的第一项内容，让所有调整判断都有共同的参照点。
常见问题
迭代进行中插入紧急需求，按示例规则应该走哪一级？
取决于工作量和对迭代目标的影响。示例中，工作量变化在 0.5 人日以内且不影响迭代目标的，走一级微调，开发负责人确认后当日记录；超过 0.5 人日或影响某个功能交付的，走二级替换，需移出等量工作并由迭代目标负责人审批；如果变动导致迭代目标本身需要修改，或累计替换超过迭代总容量的 20%，则升级为三级目标变更。实际使用时，0.5 人日和 20% 都是示例参数，应按团队历史调整分布重新设定。
替换原则要求移出等量工作，如果团队剩余容量确实还有富余，能不能直接净增？
示例允许净增，但设有条件：剩余容量确实存在，且迭代目标负责人同意，净增总量不超过迭代总容量的 10%。这样设计是为了防止“都很重要”式的范围膨胀，同时给真正紧急且容量允许的情况留出通道。判断剩余容量时，需要以规划时统一的容量口径为准，否则“是否等量”无法比较。如果团队经常出现净增申请，建议在回顾会上检查规划阶段的容量估算是否偏保守。
未完成的工作为什么不能直接结转到下个迭代？
默认结转会让待办列表不断累积未验证的工作，下个迭代的规划被历史包袱占据，优先级判断失真。示例要求每项未完成工作在评审会上重新评估三件事：是否仍然需要、优先级是否变化、原估算是否偏差过大。评估结论分为重新排入下个迭代并重新估算、退回待办列表等待排期、关闭并记录原因三类。重新排入的工作需与其他需求一起参与优先级排序，不因“上次没做完”自动获得优先位置。
团队没有稳定的评审回顾节奏，这套规则能直接用吗？
建议先把评审回顾固定下来再执行。示例中未完成工作的重新评估、变更记录的分析都依赖评审回顾作为执行场合；如果评审回顾不稳定，重新评估容易流于形式，记录字段也缺少被使用的场景。可以先从每迭代固定一次评审和一次回顾开始，把工作状态确认和原因分析纳入议程，再逐步引入分级审批和容量核算。规则本身不能替代迭代目标的澄清，填写时建议把“本迭代目标是什么”作为文档第一项内容。
团队人数和示例差别很大，哪些部分需要改？
结构保留，参数调整。触发条件、分级、审批、记录、复盘五个环节构成完整闭环，建议保留；分级阈值按团队历史调整分布和迭代周期长度重新设定；审批人按团队角色分工确定谁对迭代目标负责；容量口径与规划时的估算单位保持一致。人数较少的团队可以合并一级和二级的确认环节，但记录要求不建议省略；人数较多的团队需要更明确的审批分工。记录字段可增减，提出人、原因、影响、决策、日期五项建议保留。
