制定迭代范围调整规则，核心是把“谁能改、什么条件下改、改了怎么记录、改完怎么验证”固化成一条可执行流程：先明确迭代目标与容量基线，再设定变更触发条件与分级审批，接着规定变更的输入材料、评审动作与产出记录，最后用完成检查确认规则真正被执行。规则聚焦当前迭代内的范围增减，未完成工作需重新评估，不默认自动结转。
要点总览（TL;DR）
- 先固定迭代目标、容量口径与范围边界三项基线，后续每次变更判断才有共同参照。
- 把允许调整的情形限定为需求变更、缺陷阻塞、外部依赖变化和容量假设失效，并按影响程度分为微调、一般变更、重大变更，对应不同审批角色与时限。
- 一次调整走固定步骤：提交申请材料、组织评审、更新工作项与工时、形成变更记录并通知相关方。
- 用角色—职责—交付物对照表明确产品负责人、迭代负责人、开发团队和相关方的分工，并指定升级与争议处理责任人。
- 每个迭代回顾时逐条核对申请、审批、记录、容量复核与未完成工作重新评估，连续出现同类偏差就修订规则条款。
先定基线：迭代目标、容量与范围边界
范围调整规则要能判断“这次改动是否合理”，前提是迭代开始时已经有一份可对照的基线。基线缺失时，任何变更讨论都会退回到“感觉做不完”或“这个需求很急”的主观判断。基线说明建议在迭代计划会议结束时定稿，随迭代文档一并留存。
迭代目标的写法与可衡量标准
迭代目标描述本迭代要达成的业务结果，避免写成任务清单。一个可用的写法包含三部分：面向谁、交付什么、以什么指标判断达成。例如“让新注册用户在本迭代内可以完成手机号绑定，绑定成功率在测试环境达到约定阈值”。目标数量控制在一条到三条，超出说明本迭代承载了多个方向，需要拆分。
可衡量标准要落到可观察的验收条件上：功能验收标准、质量门槛（如缺陷等级分布）、上线范围。目标与验收标准在迭代计划会议上由产品负责人和团队共同确认，确认后作为范围判断的参照。
团队容量基线的估算口径
容量基线回答“这个迭代团队实际能投入多少”。常用口径是：可用人力乘以迭代内可用工作日，再扣除会议、支持、休假等非交付时间，得到可用工时；同时用历史迭代的实际完成量作为交叉校验。两种口径同时记录，出现偏差时能看出是估算问题还是执行问题。
容量基线需要写明假设条件：参与人员名单、每人投入比例、外部支持占用。假设变化本身就是范围调整的触发信号之一。
Sprint Backlog 的范围边界与缓冲约定
范围边界要明确本迭代承诺交付的工作项清单，以及清单之外的工作如何处理。建议在容量中预留一定比例的缓冲，用于吸收估算误差和临时阻塞；缓冲比例由团队根据历史波动确定，并在基线说明中写清楚。缓冲的使用同样需要记录，避免缓冲被当成额外容量反复消耗。
基线说明的产出物是一页文档，包含：迭代目标与验收标准、容量估算口径与假设、承诺工作项清单、缓冲比例与使用约定。这份文档是后续所有变更评审的共同参照。
范围调整的触发条件与分级规则
规则要回答两个问题：什么情况允许调整，以及不同影响程度的调整由谁在多长时间内决定。把这两件事写清楚，可以避免每次变更都升级到全员讨论，也能防止小改动绕过记录。
允许调整的典型触发条件
- 需求变更：业务方提出新的高优先级需求，或已承诺需求的验收标准发生实质变化。
- 缺陷阻塞：出现阻断性缺陷，修复所需工作量超出原估算，影响其他工作项推进。
- 外部依赖变化：接口、第三方服务、上游团队交付延迟或口径改变，导致原计划无法按原方式执行。
- 容量假设失效：关键人员长期缺位、支持任务激增，使实际可用工时明显低于基线。
不满足上述条件的需求，进入产品待办列表等待下一轮规划，不占用当前迭代的调整通道。
按影响程度分级
分级依据建议用三个维度综合判断：工作量增减占迭代容量的比例、是否影响迭代目标的达成、是否引入新的外部依赖。团队可结合自身规模调整阈值，下表给出一个可参考的分级框架。
| 级别 | 判断标准（参考） | 审批角色 | 决策时限 |
|---|---|---|---|
| 微调 | 工作量增减在容量的小比例范围内，不影响迭代目标，不引入新依赖 | 产品负责人与迭代负责人确认，团队知会 | 当个工作日内 |
| 一般变更 | 工作量增减达到容量的中等比例，或需要替换一个承诺工作项 | 产品负责人审批，迭代负责人评估容量影响，团队评审 | 一到两个工作日内 |
| 重大变更 | 影响迭代目标达成，或增减幅度超过约定上限，或引入新的外部依赖 | 产品负责人与相关方共同决策，迭代负责人组织评审 | 在迭代内尽快安排，必要时调整迭代目标 |
分级表要写明“超出上限时如何处理”：通常意味着迭代目标需要重新确认，而不是简单把工作塞进剩余时间。审批时限的作用是防止变更悬而未决，超时未决按默认拒绝处理，需求回到待办列表。
调整的操作步骤：输入、动作与产出
一次范围调整应走完固定步骤，每一步都有明确的输入、动作、输出和完成标志。流程卡可以贴在团队文档中，任何人发起变更时按卡执行。
变更申请需要提交的输入材料
- 变更内容说明：新增、删除或修改的工作项，以及对应的验收标准。
- 变更理由：对应哪条触发条件，不满足触发条件的不进入评审。
- 工作量估算：由提出方与相关开发人员共同给出，注明估算依据。
- 影响分析：对迭代目标、其他工作项、外部依赖和上线时间的影响。
- 建议的处理方式：替换哪个工作项、是否使用缓冲、是否需要调整目标。
评审会议的动作与参与角色
评审由迭代负责人组织，参与角色至少包括产品负责人、相关开发与测试人员。会议动作按顺序进行：确认触发条件成立；核对工作量估算与容量余量；判断影响级别；按级别由对应角色做出决定；记录决定结果与附加条件。评审结论只有三种：接受并调整、拒绝并回到待办、延期到下一轮规划再议。
调整后对 Sprint Backlog、任务与工时的更新
决定接受后，产品负责人更新迭代工作项清单，开发人员拆分或关闭对应任务，工时估算同步修正，容量基线中的剩余可用工时重新计算。更新动作要在评审当天完成，避免看板状态与实际承诺脱节。在使用 ONES 的团队中，需求与相关任务可以规划至迭代并分配负责人，任务状态通过敏捷看板管理，调整后的清单和进度能在同一处对齐；迭代回顾时还可借助燃尽图、工时日志等报表复盘进度与成本偏差。
记录与通知的产出要求
每次调整产出一条变更记录，包含：申请材料、评审结论、审批人、调整前后的工作项清单、容量变化、生效时间。记录同步给团队和相关方，并在每日站会或迭代沟通中说明。变更记录与迭代文档关联保存，便于回顾时追溯。ONES Wiki 支持文档关联任务，可将规则说明、变更记录与对应工作项放在一起，减少文档与任务之间的来回查找。
角色分工与交付物清单
职责清晰是规则可执行的前提。每个角色在范围调整中承担不同动作，交付物在交接节点上完成移交，避免出现“谁都同意、没人记录”的情况。
| 角色 | 主要职责 | 关键交付物 | 交接节点 |
|---|---|---|---|
| 产品负责人 | 判断需求价值与优先级，决定是否发起变更，确认迭代目标是否调整 | 变更申请中的价值说明与优先级判断；调整后的工作项清单 | 评审会前提交申请，评审后更新清单 |
| 迭代负责人（Scrum Master 或同等角色） | 组织评审、核对容量、维护流程执行、跟踪记录完整性 | 评审纪要、变更记录、容量复核结果 | 评审当天完成记录，迭代结束前汇总 |
| 开发团队 | 提供工作量估算与影响分析，执行任务拆分与状态更新 | 估算结果、任务拆分与工时修正 | 评审前给出估算，决定后当天更新任务 |
| 相关方 | 提出业务侧变更需求，参与重大变更决策，接收调整通知 | 需求说明与期望时间；对重大变更的决策意见 | 申请阶段提交，重大变更评审时参与 |
升级与争议处理指定明确责任人：分级判断出现分歧时，由产品负责人与迭代负责人共同裁定；涉及迭代目标调整的争议，提交相关方共同决策。裁定结果同样写入变更记录，作为后续类似情形的参照。
示例：一次迭代中段的范围调整如何走完流程
以下为演示情景，用于说明规则如何从触发走到落地，团队可替换为自身业务对象。
情景设定：某团队处于两周迭代的第 6 个工作日，迭代目标为完成订单查询功能的改造。此时业务方提出，合作方接口将在下周切换，需要提前适配，否则线上查询会受影响。该需求不在本迭代承诺清单内。
第一步，判断触发条件。该需求属于外部依赖变化，满足允许调整的条件。产品负责人提交变更申请，附接口切换说明、影响范围、初步工作量估算，以及建议替换的低优先级工作项。
第二步，按分级规则判断。估算显示适配工作量约占本迭代剩余容量的中等比例，且需要替换一个承诺工作项，判定为一般变更。迭代负责人核对剩余容量与缓冲余量，确认替换后目标仍可达成。
第三步，走审批。产品负责人审批通过，团队在评审中确认估算与替换方案，决定使用部分缓冲吸收估算误差。评审当天形成变更记录，写明申请材料、结论、审批人和调整前后清单。
第四步，更新 Backlog 与沟通。产品负责人将适配需求加入当前迭代并分配负责人，被替换的工作项退回待办列表并标注原因；开发人员拆分任务、修正工时；迭代负责人在站会上向团队说明调整内容与新的优先级顺序。
第五步，复核目标与容量。调整后重新核对迭代目标是否仍然成立，剩余可用工时是否覆盖新清单。本例中目标不变，容量在缓冲范围内，规则允许继续执行。若复核发现目标无法达成，则升级为重大变更，重新确认迭代目标。
完成检查：规则是否真正被执行
规则写出来不等于被执行。迭代结束前的检查用于发现偏差，回顾会上的复盘用于修订规则本身。检查项应逐条核对，结果记入迭代回顾材料。
- 本迭代每次范围调整是否都有申请材料、评审结论和变更记录，三者能否对应到具体工作项。
- 调整是否按分级表由对应角色审批，是否存在越级或事后补批的情况。
- 调整后是否重新核对容量与迭代目标，缓冲使用是否有记录。
- 未完成工作是否在新一轮规划中重新评估优先级与容量，未默认自动结转。
- 变更记录是否同步给团队和相关方，看板状态与承诺清单是否一致。
- 分级阈值、审批时限、缓冲比例是否与实际执行情况匹配，是否需要修订。
规则本身的复盘建议每个迭代回顾时用少量时间检查一次，连续多个迭代出现同类偏差时修订规则条款，修订结果更新到基线说明和流程卡中。迭代回顾可以结合燃尽图、工时日志等数据核对调整前后的进度与成本变化，把经验沉淀到团队知识库，供下一轮规划参考。
常见问题
迭代进行到一半，业务方坚持要把新需求加进来，规则上应该怎么处理？
先判断新需求是否满足允许调整的触发条件。如果属于需求变更且优先级确实高于当前承诺的工作项，就按分级规则评估影响：工作量增减占容量的比例、是否影响迭代目标、是否引入新的外部依赖。影响小的由产品负责人与迭代负责人确认即可；需要替换承诺工作项的走一般变更；影响目标达成的升级为重大变更，由产品负责人与相关方共同决策。
如果新需求不满足触发条件，就进入产品待办列表等待下一轮规划，不占用当前迭代的调整通道。规则提前写清楚这一点，团队在沟通时才有据可依。
分级审批的阈值怎么定，团队规模小是否可以直接简化？
阈值没有统一标准，建议用工作量增减占迭代容量的比例、是否影响迭代目标、是否引入新依赖三个维度综合判断，并结合团队历史波动确定具体数值。团队规模较小时，可以把微调和一般变更合并为一级，由产品负责人审批、迭代负责人记录，重大变更仍保留共同决策。
简化的是审批层级，申请材料、评审结论和变更记录这些动作建议保留，否则后续回顾时无法追溯调整原因。
调整后容量不够，未完成的工作项可以直接带到下一个迭代吗？
不建议默认自动结转。未完成工作应在新一轮规划中重新评估优先级与容量，确认它是否仍然值得做、估算是否需要修正，再决定是否纳入下一迭代的承诺清单。直接结转容易让迭代容量被历史遗留工作占满，也掩盖了原估算或执行中的问题。
重新评估的结果记入规划材料，与本次范围调整的变更记录一并留存，回顾时可以对照查看偏差来源。
规则执行一段时间后出现“先做后补”的情况，怎么纠正？
先确认是流程太重还是执行习惯问题。如果微调级别的审批链条过长，可以简化该级别的动作，让日常小改动有快速通道；如果是团队对记录价值认识不足，可以在迭代回顾中展示变更记录对追溯和估算改进的作用。
检查项中增加一条“是否存在越级或事后补批”，每次回顾逐条核对。连续多个迭代出现同类偏差时，修订分级阈值或审批时限，并把修订结果更新到基线说明和流程卡中。
范围调整规则和迭代目标冲突时以哪个为准？
迭代目标是范围判断的参照之一，不是不可调整的固定项。当变更影响目标达成时，规则应把它归入重大变更，由产品负责人与相关方共同决策：要么调整目标，要么拒绝变更。关键在于决策过程有记录、有明确的责任人，而不是让团队在目标不变的情况下硬塞工作。
目标调整后，容量与剩余工时同步复核，确保新目标与可用资源匹配。
