迭代范围调整规则示例，重点在于展示一份能直接对照填写的记录：变更请求怎么写、影响评估看哪些字段、决策结论如何落到范围记录里。下面用一个演示情景走完“请求—评估—决策—留痕”四步，角色、日期和任务名称均为虚构，用于说明填写格式，不代表真实客户案例或实测效果。
要点总览（TL;DR）
- 迭代范围调整按“变更请求—影响评估—决策结论—记录留痕”四步走，任何新增、删减或替换都先登记为请求，再进入评估。
- 评估以当前迭代剩余容量和既定交付目标为基准，由产品负责人与团队共同判断接受、延后或替换，结论写回范围记录并同步迭代目标说明。
- 示例中第5天收到紧急对账提醒需求，团队选择替换：移出低优先级的导出Excel任务，纳入提醒需求，并记录移出原因与决策人。
- 规则可迁移到其他迭代：新增看容量、删减说原因、替换记清移出项去向；未完成工作重新评估，不默认自动结转。
- 迭代目标整体失效或涉及跨迭代依赖、对外承诺时，不套用单次替换示例，应先重新规划或确认外部影响。
示例要演示的规则目标
这个示例要回答一个具体问题：迭代进行到中段，突然来了一个计划外需求，团队应该怎样记录这次范围变化，才能让当次决策有依据、事后复盘有据可查。示例设定一个两周迭代，团队角色包括产品负责人、开发负责人和测试负责人，迭代目标是在第10个工作日交付订单查询功能的可用版本。
要演示的规则有三条。第一，任何新增、删减或替换范围都先作为变更请求进入评估，不直接改迭代内容。第二，评估以当前迭代剩余容量和既定交付目标为基准，由产品负责人与团队共同给出结论。第三，结论必须写回迭代范围记录，并同步修改迭代目标说明，使记录与团队认知保持一致。
需要说明的是，示例中的任务名称、工时数字和日期都是为演示填写方式而设定的，读者应把它当作格式参照，替换为自己团队的真实信息后再使用。
完整示例：第5天的一次范围替换
以下是一份填好的范围调整记录，按请求、评估、决策、留痕四段组织。示例情景：迭代第5天，业务方提出一个紧急的对账差异提醒需求。
第一段：变更请求
| 字段 | 填写内容 |
|---|---|
| 请求标题 | 新增对账差异实时提醒 |
| 提出人 / 来源 | 业务运营负责人，通过需求沟通群提出 |
| 提出时间 | 迭代第5天上午 |
| 紧急程度 | 高：财务月结前需要上线，否则差异需人工逐笔核对 |
| 原始描述 | 对账完成后，若存在差异金额，向负责人在站内发出提醒，并附差异笔数 |
| 期望完成时间 | 本迭代结束前 |
第二段：影响评估
| 评估字段 | 填写内容 |
|---|---|
| 剩余容量 | 迭代剩余6个工作日，团队可用工时约合原计划的55%，已排任务占用大部分剩余时间 |
| 受影响工作项 | 订单查询功能的导出模块开发、对账报表联调 |
| 对迭代目标的影响 | 若直接追加，订单查询功能按期交付存在风险 |
| 可替换候选 | 原计划中的“对账结果导出Excel”为低优先级，业务方确认可延后 |
| 评估结论 | 建议采用替换方式：移出导出Excel任务，纳入差异提醒需求 |
第三段：决策结论
产品负责人与开发、测试负责人共同确认：接受该需求，方式为替换。原“对账结果导出Excel”移出本迭代，进入下一迭代候选列表并标注移出原因；新增“对账差异实时提醒”纳入本迭代，由原负责导出模块的开发人员承接。决策在第5天下午完成，参与人及结论一并记录。
第四段：记录留痕与目标同步
范围记录中更新三处内容：迭代工作项清单移除导出任务、加入提醒需求；迭代目标说明由“交付订单查询功能可用版本”调整为“交付订单查询功能可用版本，并包含对账差异提醒”；变更记录条目写明请求、评估结论、决策人和时间。这样下一次站会或回顾会查看迭代时，能直接看到范围为何变化。
逐项解释：每个字段为什么这样填
请求来源与紧急程度要写到可判断的程度。“业务运营负责人提出”说明请求方身份，“财务月结前需要上线”给出时间约束，团队据此判断是否值得挤占当前容量。只写“很急”无法支撑后续评估。
剩余容量与影响面需要落到具体工作项。示例中写剩余工时占比和受影响的任务名称，目的是让评估有可核对的对象，而非凭感觉判断“做得完”或“做不完”。影响面写清哪些任务被牵动，决策时才能比较追加与替换的代价。
三种结论各有适用情形。接受适用于剩余容量充足、且不影响迭代目标的情况；延后适用于需求真实但不紧急、可进入下一迭代候选的情况；替换适用于需求紧急但容量不足，需要以移出低优先级任务为代价的情况。示例选择替换，正是因为直接追加会威胁既定交付目标。
留痕字段服务于后续复盘。记录请求原文、评估结论、决策人和时间，回顾时才能区分“范围被动扩大”与“主动取舍”，也便于统计一个迭代内范围变更的次数和原因。
可迁移规律：换一个迭代也能照着填
四步顺序可以固定下来：先登记请求，再做影响评估，然后给出决策结论，最后更新范围记录与迭代目标。无论需求来自业务方、线上问题还是团队内部发现，都走同一顺序，避免“先改再看”造成的记录缺失。
不同调整类型的处理重点不同。新增需要重点评估剩余容量是否支撑；删减需要说明删减原因及对迭代目标的影响；替换需要同时记录移出项和纳入项，并明确移出项的去向。三类调整都应在记录中体现“为什么是现在做这个决定”。
未完成工作需要重新评估，不默认自动结转到下一迭代。迭代结束时，对未完成项逐项判断：仍然必要则重新排入下一迭代候选并重新估算，不再必要则关闭或退回需求池。这样下一迭代的范围是基于新判断形成的，而非简单继承。
规则落地到协作工具时，重点是让记录与工作项状态保持同步。以 ONES 为例，产品负责人可根据需求优先级将产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审；迭代过程中团队通过敏捷看板管理任务状态。范围调整发生后，把移出与纳入的工作项在迭代中更新，把决策结论写入对应工作项或变更记录，团队围绕项目计划、工作项和迭代安排协同时就能看到最新范围。迭代结束后，可结合燃尽图、工时日志等报表在回顾会上复盘范围变化带来的进度偏差。
适用边界：哪些情况不套用这个示例
当迭代目标发生根本变化时，例如业务方向调整导致原目标整体失效，处理方式已超出单次范围替换的范畴。此时应重新规划迭代甚至终止当前迭代，重新确认目标后再排范围，而不是在原有记录上逐条替换。
涉及跨迭代依赖或对外承诺时，范围调整还需要与依赖方和承诺对象沟通。示例中的替换只影响本迭代内部任务，若移出的任务被其他团队依赖，或纳入的需求涉及对外交付时间，应先确认外部影响，再按四步流程记录，并在记录中注明已沟通的对象。
本示例聚焦一次迭代内的范围调整记录。敏捷框架概念本身的系统讲解属于敏捷项目管理主题，产品待办列表的需求池管理方法属于需求池管理主题，本文不展开。读者在实际使用时，可结合团队约定的迭代规则调整字段名称和审批参与人，保持四步顺序和留痕要求即可。
常见问题
迭代中途来了紧急需求，团队容量又不够，应该直接追加还是替换？
先做影响评估再决定。把剩余可用工时、受影响的工作项和对迭代目标的影响写清楚，如果直接追加会威胁既定交付目标，替换通常是更稳妥的选择：移出一项低优先级任务，明确它的去向（下一迭代候选或退回需求池），再把新需求纳入。示例中移出的是“对账结果导出Excel”，因为业务方确认可以延后。若剩余容量确实充足且不影响目标，接受追加也可以，但同样要留下评估记录。
被移出的任务和迭代结束时没做完的任务，处理方式一样吗？
两者都要重新评估，但触发点不同。被移出的任务在决策时就已经明确了去向，记录里要写清移出原因和计划去处。迭代结束时未完成的工作项需要逐项判断：仍然必要的重新排入下一迭代候选并重新估算，不再必要的关闭或退回需求池。两种情况都不默认自动结转，下一迭代的范围应基于新的判断形成。
范围调整记录应该由谁填写、谁确认？
常见做法是由提出请求或承接评估的人填写请求与评估部分，产品负责人与开发、测试负责人共同确认决策结论，再把结论写回范围记录。示例中决策在第5天下午完成，参与人和结论一并记录。团队规模较小时可以简化参与人，但请求原文、评估依据、决策人和时间这几项建议保留，否则回顾时难以还原当时的判断过程。
范围调整记录放在协作工具里，怎么保证和实际工作项一致？
关键是让记录与工作项状态同步更新，避免记录写了一套、看板显示另一套。以 ONES 为例，产品负责人可根据需求优先级将产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审；迭代过程中团队通过敏捷看板管理任务状态。范围调整发生后，把移出与纳入的工作项在迭代中更新，决策结论写入对应工作项或变更记录，团队围绕项目计划、工作项和迭代安排协同时就能看到最新范围。迭代结束后，可结合燃尽图、工时日志等报表在回顾会上复盘范围变化带来的进度偏差。
如果移出的任务被其他团队依赖，还能按这个示例直接替换吗？
不能直接照搬。涉及跨迭代依赖或对外承诺时，替换前要先与依赖方和承诺对象沟通，确认外部影响后再走四步流程，并在记录中注明已沟通的对象和结论。示例中的替换只影响本迭代内部任务，所以流程相对简单。若迭代目标因业务方向调整整体失效，处理方式已超出单次替换的范畴，应重新规划迭代甚至终止当前迭代，重新确认目标后再排范围。
