迭代执行到中期，剩余工作量下降慢、关键项迟迟未启动，往往意味着进度已经偏离目标。此时先别急着砍需求，而要判断偏离属于估算偏差、阻塞未解除还是范围超出容量，再按“保目标、调范围”的顺序处置。本文聚焦单个迭代内的范围调整，给出从诊断、取证到调整和恢复验证的完整路径。
要点总览（TL;DR）
- 发现进度偏离时，先用燃尽趋势、关键项状态和阻塞停留时长把原因归为估算偏差、阻塞未解除或范围超容量，再决定是否动范围。
- 调整顺序固定为：先解除或升级阻塞，再按迭代目标压缩或移出非核心项，最后对移出项重新评估后安排到后续迭代。
- 移出的工作项要重新确认优先级、剩余工作量和依赖关系，记录移出原因与目标迭代，避免原样带入下一迭代造成超载。
- 调整后看剩余工作量趋势和关键项完成情况验证恢复；迭代结束复盘偏离原因，把结论落到估算基准与容量约定上。
偏离目标时先判断是哪一类问题
发现进度偏离，第一步是把现象归到具体类型，因为三类原因对应的动作完全不同：估算偏差要修正剩余工作量的判断，阻塞未解除要推动外部依赖，范围超容量才需要真正动范围。判断错了，调整范围只会掩盖问题。
日常跟进中常见的症状有三类：燃尽图连续几个跟进日走平或下降明显慢于计划线；迭代内优先级最高的关键项仍停留在未开始状态；某个阻塞项在看板上停留超过两三天，负责人和解除条件都不明确。把这些症状与可能原因对照，可以快速形成初步假设。
| 症状 | 可能原因 | 是否需调范围 |
|---|---|---|
| 剩余工作量下降慢，但任务都在推进 | 估算偏差，原估算偏乐观 | 暂不调，先修正剩余估算 |
| 关键项未启动，团队在等外部输入 | 阻塞未解除 | 暂不调，先解除或升级阻塞 |
| 多数任务同时进行，完成率低 | 范围超出迭代容量 | 需要压缩或移出非核心项 |
| 阻塞项停留多日且无责任方 | 阻塞未解除，且升级机制缺失 | 先升级，再评估是否调范围 |
需要说明本文的边界：这里只讨论单个迭代内的范围调整动作，不展开敏捷框架的原则讲解，也不涉及产品待办列表的需求池管理。范围调整是迭代内的应急手段，不是重新做迭代规划。
用证据排除原因，避免误调范围
初步假设不能直接当结论。调整范围会影响已承诺的交付，动手前要用迭代内已有的数据验证原因，排查顺序建议从阻塞开始，再看估算，最后看容量。
阻塞类原因的证据包括：看板上该工作项的状态停留时长、阻塞记录中写明的责任方与解除条件、相关沟通记录。如果阻塞项的责任方尚未确认或解除条件未写清，就不能把它归为估算问题——此时工作量没有变化，只是被卡住了。阻塞未解除前调整范围，等于用缩减承诺掩盖依赖问题。
估算类原因的证据包括：已完成任务的實際工时与原估算的偏差、剩余任务是否已重新估算、完成定义是否被临时放宽。如果已完成项普遍超出估算，而剩余项估算尚未更新，燃尽趋势失真就来自估算而非范围。
容量类原因的证据包括：迭代内工作项总数与团队可用人天的对比、并行进行中的任务数量、是否存在迭代中途插入的需求。并行任务过多、插入需求未替换原有承诺，通常是范围超容量的直接信号。
| 原因假设 | 验证证据 | 排查顺序 |
|---|---|---|
| 阻塞未解除 | 状态停留时长、阻塞记录中的责任方与解除条件 | 第一 |
| 估算偏差 | 已完成项工时偏差、剩余项是否重新估算 | 第二 |
| 范围超容量 | 工作项总量与可用人天对比、并行任务数、中途插入需求 | 第三 |
证据不足时不要急于下结论。例如阻塞项刚记录一天、剩余估算尚未复核，可以先观察一个跟进周期，在下一次每日跟进中再看趋势。一个周期的观察成本远低于一次错误的范围调整。
按偏离程度调整范围的具体步骤
确认需要动范围后，处置按固定顺序推进：先处理阻塞，再压缩范围，最后安排移出项。顺序颠倒会让调整失去依据。
第一步，解除或升级阻塞。对每个阻塞项明确责任方、解除条件和期望时间；团队内部无法推动的，按预设的升级条件提交给产品负责人或相关管理角色。升级要有停止点：约定一个时间点，到期仍未解除就进入范围调整，避免阻塞无限期拖住迭代。
第二步，按目标优先级压缩或移出非核心项。以迭代目标为基准，把工作项分为“目标必需”和“可延后”两类。优先保留能构成最小可交付结果的核心项，把可延后项移出本迭代。压缩时注意保留完成定义，不通过放宽验收标准来“完成”工作项。
第三步，对移出项重新评估，不做默认结转。移出的工作项要重新确认优先级、剩余工作量和依赖关系，再决定放入哪个后续迭代。重新评估至少记录：移出原因、当前完成比例、剩余工作量、新的目标迭代。默认把未完成项原样带入下一迭代，会让下一迭代一开始就超载。
整个调整过程需要与产品负责人及相关角色确认，并记录变更原因。在 ONES 中，迭代内的需求与任务可以通过看板管理状态，产品负责人按优先级将需求规划至迭代并分配负责人；范围调整时，工作项的状态流转和变更记录留在同一处，复盘时能追溯哪些项被移出、为什么移出。ONES Project 还支持自定义需求状态与工作流，团队可以按自己的调整流程设置状态，让“待重新评估”“已移出”这类中间状态可见。
变更记录建议包含以下要点：
- 调整日期与触发原因（对应哪类偏离）；
- 移出或压缩的工作项清单及原优先级；
- 保留的最小可交付目标；
- 移出项的重新评估结论与目标迭代；
- 确认人及确认时间。
调整后如何验证恢复并防止复发
范围调整完成不等于问题解决，要用数据确认迭代回到可交付轨道。验证看两个指标：剩余工作量趋势是否恢复稳定下降，关键项是否按新计划推进并接近完成定义。如果调整后趋势仍走平，说明原因判断可能仍有遗漏，需要回到证据排查。
迭代结束后的复盘是把一次偏离转化为改进的环节。复盘时对照燃尽图、工时记录和变更记录，回答三个问题：原估算与实际的偏差有多大、阻塞从出现到解除用了多久、范围超容量是否与中途插入需求有关。结论要落到具体约定上，例如调整同类任务的估算基准、在迭代容量中预留阻塞缓冲、明确中途插入需求必须替换等量原有承诺。ONES 的迭代回顾场景支持用燃尽图、工时日志等报表复盘进度与成本偏差，复盘结论可以通过 ONES Wiki 沉淀为团队知识库，供后续迭代参考。
最后设置下一次跟进的检查点：在调整后的第一个跟进日确认剩余工作量是否按新计划下降，在迭代后期确认关键项进入验收。触发条件可以写成规则，例如“剩余工作量连续两个跟进日未下降”或“任一阻塞项停留超过约定天数”，触发后立即回到本文第一步重新判断，而不是等到迭代结束才发现无法交付。
常见问题
迭代中期发现偏离，但阻塞项刚记录一天，应该马上调整范围吗？
不建议马上调整。阻塞项刚出现时，先确认责任方和解除条件是否明确，再观察一个跟进周期。如果下一次每日跟进时阻塞仍在、剩余工作量趋势继续走平，再进入范围调整。一个周期的观察成本通常低于一次错误的范围缩减。
移出本迭代的工作项，可以直接放进下一个迭代吗？
需要重新评估后再安排。移出项要重新确认优先级、当前完成比例、剩余工作量和依赖关系，再决定放入哪个后续迭代。原样带入会让下一迭代一开始就超载，也容易掩盖原估算的问题。重新评估的结论应和移出原因一起记录，便于复盘追溯。
范围调整需要哪些角色确认，变更记录记什么？
调整需与产品负责人及相关角色确认。变更记录至少包含：调整日期与触发原因、移出或压缩的工作项清单及原优先级、保留的最小可交付目标、移出项的重新评估结论与目标迭代、确认人与确认时间。记录完整，复盘时才能判断偏离是偶发还是估算与容量约定需要修正。
调整后剩余工作量趋势仍未恢复下降，怎么办？
说明原因判断可能仍有遗漏，应回到证据排查：重新检查是否还有未识别的阻塞、剩余估算是否已更新、是否有中途插入的需求未被替换。排查后仍无法恢复的，再评估是否需要进一步压缩范围或升级给相关管理角色，而不是等到迭代结束才发现无法交付。
ONES 在范围调整过程中能提供哪些支撑？
ONES 敏捷研发管理方案覆盖迭代进度跟进，团队可在迭代中通过敏捷看板管理任务状态，并用燃尽图评估进度；ONES Project 支持将需求和相关任务规划至迭代并分配负责人，也支持自定义需求状态与工作流，便于把“待重新评估”“已移出”等中间状态显性化。迭代结束后，可用燃尽图、工时日志等报表复盘偏差，并通过 ONES Wiki 沉淀复盘结论。
