迭代范围调整规则要解决的是“迭代进行中有人要加需求、换需求或减需求时，团队按什么依据判断、由谁拍板、改完怎么留痕、没做完的工作怎么处理”。一份可执行的规则至少包含范围基线、变更触发条件与分级、审批角色与时限、变更记录与同步、未完成工作的处理口径五部分。其中未完成工作应回到待办重新评估优先级与工作量，由产品负责人决定是否纳入下一迭代，不默认自动结转。
要点总览（TL;DR）
- 一份可执行的迭代范围调整规则至少包含五部分：范围基线、变更触发条件与分级、审批角色与时限、变更记录与同步、未完成工作的处理口径。
- 流程按四步跑通：锁定并公开基线、受理变更并分级、按级别审批并更新 Sprint Backlog、同步相关角色并在每日跟进中跟踪，每步都有明确的输入、输出和完成标志。
- 产品负责人负责分级判断与决策，开发团队提供工作量与风险评估，迭代负责人或项目经理负责登记、记录与同步，评估与决策分开写能减少评审拉扯。
- 未完成工作回到待办重新评估优先级与工作量，由产品负责人决定是否纳入下一迭代，不默认自动结转。
- 用基线可追溯、变更留痕、未完成项重新评估、跟进与回顾引用记录、规则定期复盘五项检查判断规则是否真正落地。
范围调整规则先定哪几件事
规则写成一页纸也能执行，前提是每一部分都落到具体对象和判断标准上。只写“严格控制范围变更”这类原则，团队在遇到具体请求时仍然无法判断该找谁、要不要开会。下面五项构成一份规则的最小集合，可以拿现有规则逐项对照，缺哪项补哪项。
1. 范围基线：明确“改的是什么”
基线是判断“是否发生变更”的参照物。规则中要写清基线由三样东西组成：本次迭代目标（一到两条可验证的成果描述）、迭代容量（团队在本迭代可投入的人天或故事点上限）、Sprint Backlog 中的承诺项清单。基线在迭代计划会议结束时锁定并公开，之后任何新增、替换、删除都对照这份基线判断影响。基线本身要有版本，调整后生成新版本，旧版本保留可查。
2. 变更触发条件与分级
不是所有改动都需要走完整评审。规则按影响程度分两级即可覆盖多数团队：
- 轻量变更：工作量相当的需求替换、不改变迭代目标的优先级微调、澄清类补充说明。由产品负责人确认后记录，不需召开评审会。
- 评审变更：新增净工作量、改变迭代目标、挤占已承诺项容量、影响对外交付时间的调整。必须经产品负责人评审，必要时拉上开发负责人评估影响后再决定。
分级标准要写成可判断的条件，例如“新增工作量超过本迭代剩余容量的 10%”比“影响较大”更容易执行。阈值由团队根据自身容量确定，写进规则后保持一致。
3. 审批角色与决策时限
规则要指定每级变更的决策人：轻量变更由产品负责人确认；评审变更由产品负责人决策，开发负责人提供影响评估意见。同时约定时限，例如评审变更在受理后一个工作日内给出结论，避免请求悬空导致团队反复讨论。决策结论只有三种：接受并调整范围、推迟到后续迭代、拒绝，每种结论都要有记录。
4. 变更记录字段与同步对象
记录字段建议固定为：变更内容、提出人、提出时间、影响评估（工作量与目标影响）、分级结论、决策人与决策时间、调整后的范围说明。同步对象包括开发团队全体、测试负责人，以及受交付时间影响的外部相关方。记录集中存放，与迭代工作项关联，便于回顾时统计。
5. 未完成工作的处理口径
规则要明确：迭代结束时未完成的工作项不自动进入下一迭代，而是回到待办列表，由产品负责人结合下一迭代目标重新评估优先级和工作量，再决定是否纳入。重新评估时要更新剩余工作量估算，避免把过期估算直接带入新迭代。这条口径写进规则，可以防止迭代容量被历史遗留项悄悄占满。
按四步建立调整流程
要素确定后，把它们串成一条从基线锁定到日常跟踪的流程。每一步都说明输入、动作、输出和完成标志，团队照此执行即可，不需要每次重新讨论流程。
第一步：锁定范围基线并公开
输入：迭代目标、团队容量、已评审的 Sprint Backlog 候选清单。动作：在迭代计划会议上确认目标与验收标准，将需求拆分到可执行的任务粒度，分配负责人，形成基线版本。输出：基线版本（目标 + 容量 + 承诺项清单）。完成标志：基线对全员可见，版本号或锁定时间可查。ONES 的迭代规划支持产品负责人按优先级将需求规划至迭代，并在计划会议上与团队共同评审；需求与验收标准达成一致后，团队可用子任务拆分需求，便于后续跟踪。
第二步：受理变更请求并判断触发条件
输入：变更描述、提出人、期望时间、初步影响说明。动作：由产品负责人或迭代负责人对照分级标准判断属于轻量变更还是评审变更；评审变更需补充工作量估算和目标影响分析。输出：分级结论与影响评估。完成标志：变更请求已登记，分级结论和评估内容写入记录，提出人收到受理反馈。
第三步：按级别审批并更新 Sprint Backlog
输入：分级结论、影响评估。动作：轻量变更由产品负责人确认后直接调整；评审变更由产品负责人决策，开发负责人给出可行性意见，结论为接受、推迟或拒绝。接受时同步调整 Sprint Backlog，移除或缩减被挤占的承诺项，并更新基线版本。输出：变更记录、调整后的范围与基线版本。完成标志：Sprint Backlog 已反映调整，变更记录包含决策人与决策时间，被移出的工作项已回到待办并标注原因。
第四步：同步相关角色并在每日跟进中跟踪
输入：变更记录、调整后的范围。动作：迭代负责人向团队和相关方同步变更内容与影响；每日跟进时对照调整后的范围检查进度与风险，把变更带来的新风险列为跟踪项。输出：同步记录、跟踪项清单。完成标志：团队成员知晓当前有效范围，每日站会或看板上的进度口径与最新基线一致。ONES 的敏捷看板可在每日站立会议中可视化对齐迭代进度与风险，变更后的范围可以直接体现在任务状态和跟踪项上。
角色分工与各自交付物
规则能否执行，取决于每个角色是否清楚自己交付什么。下表按动作列出分工，团队可以据此在规则中写明责任人姓名或岗位。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 提出方（需求方或团队成员） | 说明变更内容、原因与期望时间 | 变更请求（含初步影响说明） |
| 产品负责人 | 判断分级、评估目标影响、做出决策、决定未完成工作去向 | 分级结论、决策记录、待办优先级调整 |
| 开发团队（含开发负责人） | 评估工作量与技术可行性，拆分或调整任务 | 影响评估（工作量、风险）、调整后的任务拆分 |
| 迭代负责人或项目经理 | 登记变更、维护记录、同步相关方、跟踪执行 | 变更记录、同步通知、跟踪项清单 |
| 测试负责人 | 评估测试范围与回归影响 | 测试影响说明 |
| 全体成员（回顾环节） | 复盘变更频率、原因与处理效果 | 回顾结论与规则改进建议 |
分工中容易出问题的是“评估”和“决策”混在一起：开发团队提供工作量和风险判断，产品负责人对是否调整范围负责。规则中把这两件事分开写，可以减少评审会上反复拉扯。回顾环节则承担规则自身的迭代：统计本迭代变更次数、分级分布和被拒绝的原因，判断阈值和审批时限是否合理。
一个范围调整的完整示例
以下为演示情景，用于说明规则如何跑通，数值为示例设定。
情景：某团队处于一个两周迭代的第 5 个工作日，迭代目标为完成订单查询接口改造，容量为 40 人天，Sprint Backlog 已锁定。此时业务方提出一个紧急的报表导出需求，希望本迭代内上线。
判断分级：产品负责人对照规则，该需求为新增功能，预估 6 人天，占本迭代剩余容量约 30%，且会挤占已承诺的接口联调任务，属于评审变更。
影响评估：开发负责人评估后给出结论：6 人天估算基本可信，若插入该需求，接口联调需推迟到下一迭代，迭代目标中的“完成联调”无法达成；测试负责人补充回归范围会增加两个模块。
审批与记录：产品负责人当日组织短会，结论为“推迟到下一迭代”，理由是当前迭代目标涉及对外接口约定，变更成本高于报表需求的时效收益。变更记录填写提出人、时间、影响评估、分级结论、决策人与决策时间，并同步给业务方和团队。
未完成工作的处理：迭代结束时有 3 个任务未完成，其中 2 个属于联调准备。迭代负责人将其移回待办，产品负责人在下一迭代计划时重新评估：1 个任务因接口方案变化需重新估算，另 1 个任务优先级下调，暂不纳入下一迭代。整个过程在回顾会上作为变更管理案例讨论，团队据此把“新增工作量超过剩余容量 20% 即触发评审”写入规则。
规则落地的完成检查
规则发布不等于落地。用下面这份清单逐项核对，可以判断规则是否真正在日常运行中起作用。
| 检查项 | 核验方式 | 通过标准 |
|---|---|---|
| 基线是否公开且版本可追溯 | 抽查最近两个迭代的基线记录 | 每个迭代有明确的基线版本和锁定时间，调整后有新版本 |
| 变更是否都有记录和审批结论 | 对照变更记录与 Sprint Backlog 实际变化 | 每次范围变化都能找到对应记录，含分级、决策人和时间 |
| 未完成工作是否经过重新评估 | 检查上一迭代未完成项的流向 | 未完成项回到待办并有重新估算或优先级说明，无自动结转 |
| 每日跟进与评审回顾是否引用变更记录 | 查看站会跟踪项和回顾会材料 | 跟踪项与变更记录对应，回顾会有变更频率与原因分析 |
| 规则是否定期复盘并调整 | 查看规则修订记录 | 至少每季度或每若干迭代复核一次阈值、时限和分级标准 |
检查中发现的问题通常集中在两处：变更记录只记结果不记影响评估，导致回顾时无法判断决策质量；未完成项被直接拖入下一迭代，基线形同虚设。前者通过固定记录字段解决，后者通过把“重新评估”设为纳入下一迭代的前置动作解决。规则运行一段时间后，可结合迭代回顾中的燃尽图、工时日志等数据，复盘变更对进度和成本的实际影响，再调整分级阈值与审批时限，让规则随团队实际节奏逐步校准。
常见问题
迭代进行中收到紧急需求，怎么判断该走轻量记录还是完整评审？
先对照规则里的分级标准，看这次调整是否改变迭代目标、是否新增净工作量、是否挤占已承诺项的容量、是否影响对外交付时间。四项中命中任意一项，就按评审变更处理，由产品负责人组织评估后再决策；只是工作量相当的需求替换、不改变目标的优先级微调或澄清类补充，走轻量记录即可。
分级标准要写成可判断的条件，例如“新增工作量超过本迭代剩余容量的 10%”，阈值由团队按自身容量确定并写进规则。示例中的团队就是在一次评审变更之后，把“新增工作量超过剩余容量 20% 即触发评审”固化进规则的。
产品负责人和开发负责人在范围调整中意见不一致时，以谁为准？
规则里要把评估权和决策权分开：开发团队负责给出工作量、技术可行性和风险判断，产品负责人对是否调整范围、调整哪一项负责。意见不一致时，以产品负责人的决策为准，但影响评估意见要完整写入变更记录，作为后续回顾判断决策质量的依据。
如果分歧集中在技术可行性本身，可以约定由开发负责人给出明确结论，产品负责人据此在“接受、推迟、拒绝”三种结论中选择，避免在会上反复讨论而没有结论。
迭代结束时未完成的工作，可以直接带到下一迭代继续做吗？
按本文建议的口径，未完成工作回到待办列表，由产品负责人结合下一迭代目标重新评估优先级和工作量，再决定是否纳入，不默认自动结转。重新评估时要更新剩余工作量估算，避免把过期估算直接带入新迭代。
这样处理的原因是下一迭代的容量要留给新的目标，历史遗留项如果悄悄占满容量，基线就失去意义。检查时可以直接看上一迭代未完成项的流向：有重新估算或优先级说明、并记录了去向，才算处理到位。
团队规模小、变更不频繁，规则可以简化到什么程度？
小团队可以把五要素压缩到一页纸：基线只写迭代目标和承诺项清单，分级只保留轻量与评审两级，审批时限写“受理后一个工作日内给出结论”，记录用固定几个字段，未完成工作按重新评估处理。要素齐全比文档篇幅更重要。
简化时不要省掉记录和未完成工作的口径，这两项决定规则能否在回顾时被检验。团队规模、变更频率变化后，再回头调整阈值和分级标准。
规则执行一段时间后，怎么判断阈值和审批时限需要调整？
在迭代回顾中统计本迭代的变更次数、分级分布、被拒绝的原因，以及变更对进度和成本的实际影响，再判断阈值是否过松或过紧。例如评审变更频繁被拒、但业务方仍持续提出，可能说明分级阈值偏低；评审变更很少触发，则可能阈值偏高、轻量变更承担了过多调整。
规则本身也要有修订记录，建议至少每季度或每若干迭代复核一次阈值、时限和分级标准，把调整依据写清楚，避免规则长期不更新而脱离团队实际节奏。
