迭代执行中，Sprint Backlog（迭代待办清单）会随着新信息不断更新，但更新不等于范围变化。判断一次变更属于澄清还是改变迭代范围，关键看“本次迭代要交付什么”是否发生变化：在已承诺的迭代目标和交付内容内补充细节、明确依赖、细化任务，属于澄清；新增、删除、替换交付项或调整迭代目标，则改变了迭代范围。本文围绕这条分界线，说明执行期的更新机制、两类变更的识别与处理，以及未完成项为何需要重新评估。
要点总览（TL;DR）
- 判断一次Sprint Backlog变更属于澄清还是范围变更，看本次迭代承诺交付的内容是否变化：交付内容不变、只补充细节和依赖属于澄清；新增、删除、替换交付项或调整迭代目标属于范围变更。
- 澄清通常表现为补充验收条件、细化任务拆解、记录新发现的依赖与阻塞、修正描述歧义，由团队确认并留痕，必要时同步产品负责人。
- 范围变更需要产品负责人显式决策，识别信号包括需要额外人力、影响其他条目交付、改变对外承诺或迭代目标无法自洽。
- 迭代结束时未完成项应逐项重新评估价值、拆分必要性和阻塞状态，回到产品待办清单重新排序，不默认自动结转到下一迭代。
- 迭代目标是判断范围是否变化的锚点；工作量增加本身不构成范围变更，关键是交付内容与目标是否改变。
一句话判断：澄清与范围变更的分界线
把一次变更归入澄清还是范围变更，只需回答一个问题：这次调整之后，本次迭代承诺交付的内容是否发生了变化。交付内容不变，只是把同一件事说得更清楚、做得更具体，属于澄清；交付内容增加、减少或被替换，属于范围变更。工作量大小、文档改动多少、讨论时间长短都不构成判断依据。
澄清是在迭代目标与承诺范围之内发生的细化。它可能表现为把一条需求的描述写得更准确，补充验收条件和边界场景，把一项任务拆成若干子任务，记录新发现的依赖、阻塞或前置条件，或者修正原有描述中的歧义与错误。这些动作让团队对“怎么做、做到什么程度算完成”形成更一致的理解，交付清单本身没有增减。
范围变更则触及交付内容本身，典型表现包括：新增一条原计划外的交付项；删除一条已经承诺的条目；用另一项内容替换原有交付项；调整迭代目标本身；或者实质性提高验收标准，使原有工作量与交付预期不再成立。范围变更需要产品负责人参与决策，因为它改变的是对外承诺和资源安排。
几种边界情形需要单独说明。等价替换指用工作量与交付价值大致相当的内容替换原条目，判断时仍要看替换是否经过显式决策：如果替换改变了交付物本身，即使工作量相近，也属于范围变更；如果只是实现方式调整、交付物不变，则属于澄清。拆分条目通常属于澄清，前提是拆分后的子项合起来仍对应原来的交付内容；如果拆分过程中冒出了原承诺之外的新交付物，超出部分按范围变更处理。发现隐藏工作量是最容易误判的情形：实现同一交付物时发现比预估更复杂，需要更多任务和工时，这属于澄清与重新估算，交付内容未变；但如果隐藏工作量导致原条目无法在迭代内完成，需要引入替代交付项或调整目标，就升级为范围变更。
Sprint Backlog在执行中如何随新信息更新
Sprint Backlog是团队对本次迭代的承诺载体，通常由迭代目标、选入的待办条目、任务拆解和验收条件组成。迭代目标说明这一轮要达成什么结果，选入条目说明交付哪些内容，任务拆解说明由谁在什么时间完成哪些具体工作，验收条件说明做到什么程度算完成。这四部分共同构成判断变更性质的参照系。
执行期的日常更新集中在执行细节层面：任务状态从待办推进到进行中、已完成；剩余工作量随进展重新估算；实现过程中发现需要补充的子任务被加入；新出现的依赖、阻塞和前置条件被记录到对应条目下。这些更新让看板和进度信息保持真实，也是每日同步会议的主要输入。
更新发生在几个固定环节。每日同步中，团队对齐进度、暴露阻塞并调整任务安排；与产品负责人的日常沟通中，澄清需求细节、确认验收口径；迭代评审中，对照验收条件确认交付结果。不同环节处理的问题不同，日常同步解决执行协调，与产品负责人的沟通解决需求理解，评审解决交付确认。
角色分工上，团队负责更新执行细节：任务拆解、状态、剩余工作量、依赖记录，这些属于团队自主管理的范畴。产品负责人负责范围与优先级：是否接纳新条目、是否删除已承诺内容、是否调整迭代目标。把这两类权限混在一起，容易出现团队自行扩大交付内容、或产品负责人在未与团队确认影响的情况下直接加需求的情况。
哪些变更属于澄清：典型情形与处理方式
澄清类变更的共同特征是不改变交付内容，只让原有内容更明确、更可执行。以下情形在执行期很常见，可以对照识别。
- 补充验收条件与边界场景。原条目只写了主流程，执行中发现异常分支、权限差异、数据边界需要明确。补充这些条件让“完成”有可核验的标准，交付物本身不变。
- 细化任务拆解与实现方案。把一条较大的任务拆成设计、开发、测试等子任务，或调整技术实现路径。拆解粒度变化和方案调整都属于执行层细化。
- 记录新发现的依赖、阻塞与前置条件。例如发现某功能依赖另一个系统的接口、需要等待环境准备、需要先完成数据迁移。把这些信息写进条目，让风险可见，交付承诺不变。
- 修正描述歧义与错误信息。原描述存在表述不清、字段写错、范围理解不一致的问题，澄清后团队理解统一。修正的是表达，不是交付内容。
澄清的处理方式以团队内确认为主：由提出者把补充内容写入对应条目，保留修改痕迹，涉及验收口径变化时同步产品负责人确认。留痕的意义在于让后来者能看到当时的判断依据，避免同一问题反复讨论，也为迭代回顾提供事实材料。澄清不需要走审批流程，但需要让相关角色知情，尤其是验收条件的补充，应当由产品负责人或需求提出方确认。
在工具层面，ONES Project 支持在迭代规划阶段对选入需求进行子任务拆分，便于后续处理和跟踪；迭代过程中团队可通过敏捷看板管理任务状态，并在每日站立会议中对齐进度与风险。这些能力承载的是澄清动作的记录与可见性，澄清与范围变更如何划分，仍由团队按上述口径判断。
哪些变更会改变迭代范围：识别信号与决策流程
范围变更的核心是交付内容发生变化。以下情形应当按范围变更处理：新增原计划外的交付项；删除已经承诺的条目；用另一项内容替换原有交付内容；调整迭代目标；实质性提高验收标准，使原有安排无法覆盖。判断时看的是交付清单和目标，不看改动的工作量大小。
几个识别信号可以帮助团队尽早发现范围变更，而不是等到迭代末期才暴露：
- 完成该变更需要额外人力，超出团队当前容量；
- 该变更会影响其他已承诺条目的交付，形成取舍关系；
- 该变更改变了对外的交付承诺，例如影响发布计划、上下游依赖方或客户预期；
- 该变更无法在现有迭代目标下自洽解释，需要修改目标表述。
决策流程应当显式进行。提出方说明变更内容与原因，提交产品负责人评估价值与优先级；产品负责人与团队确认影响，包括需要挤占哪些条目、是否影响迭代目标；双方明确取舍后形成决定，并记录变更原因、影响范围和替代安排。记录的目的不是增加流程负担，而是让后续的进度判断、对外沟通和迭代回顾有据可查。范围变更本身不代表流程失败，迭代中信息变化是常态，关键在于决策是显式的、影响是被评估过的。
| 判断维度 | 澄清 | 范围变更 |
|---|---|---|
| 交付内容 | 不变 | 新增、删除或替换 |
| 迭代目标 | 不变 | 可能调整 |
| 验收标准 | 补充细化，口径一致 | 实质性提高，改变完成预期 |
| 决策角色 | 团队确认，必要时同步产品负责人 | 产品负责人决策，团队确认影响 |
| 记录重点 | 补充内容与确认人 | 变更原因、影响与替代安排 |
未完成项如何重新评估，而不是默认结转
迭代结束时，未完成的条目需要逐项重新评估，而不是自动进入下一迭代。自动结转的问题在于，它假设优先级和容量都没有变化，而这两点在两次迭代之间往往已经改变。
重新评估按以下步骤进行：
- 逐项确认价值。该条目在当前时点是否仍然值得做，需求是否已被其他方式满足，业务优先级是否下降。
- 检查是否需拆分。未完成往往说明条目过大或验收条件不清，评估是否需要拆成更小的交付单元。
- 确认阻塞是否解除。导致未完成的外部依赖、环境问题、决策等待是否已经解决，未解决则不宜直接排入下一迭代。
- 回到产品待办清单重新排序。由产品负责人结合最新优先级决定哪些条目进入下一迭代，团队重新核算容量后确认可承接的数量。
迭代回顾是记录未完成原因的场景。团队可以借助燃尽图、工时日志等数据复盘进度偏差，讨论估算偏差、阻塞处理、协作方式上的改进点，把结论转化为下一迭代的具体调整。未完成原因的记录同时是后续估算的输入：同类条目反复超估或低估，说明拆解方式或验收条件需要调整。
与产品待办清单、迭代目标的关系及常见误解
Sprint Backlog与产品待办清单（Product Backlog）承担不同职能。产品待办清单是全局需求池，收纳所有已知需求、缺陷和改进项，按优先级排序，由产品负责人维护；Sprint Backlog是本次迭代的承诺，是从产品待办清单中选入并拆解后的子集。前者回答“可能做什么”，后者回答“这一轮承诺交付什么”。范围变更的判断以Sprint Backlog为对象，需求池的增删排序属于产品待办清单的日常管理。
迭代目标是判断范围是否变化的锚点。目标描述了本轮迭代要达成的结果，交付项是实现目标的手段。当变更发生时，先看目标是否仍然成立：目标不变、交付项在目标内细化，属于澄清；目标需要改写，或交付项变化导致目标无法按原表述达成，属于范围变更。
几个常见误解值得澄清。工作量增加不等于范围变更，实现同一交付物时发现更复杂，属于重新估算和任务细化；澄清不需要记录的看法也不准确，验收条件和依赖的补充应当留痕，否则后续确认和回顾缺少依据；未完成项自动顺延同样不成立，优先级和容量需要重新核算。还有一种误解是把范围变化视为流程失败，实际上迭代中信息更新是正常现象，显式决策、评估影响、留下记录，比维持表面不变更有价值。
一个具体例子：迭代中途发现新依赖
以下为演示情景。某团队在迭代进行到第三天时发现，一条已承诺的“订单状态同步”需求依赖外部支付系统的接口，而该接口尚未就绪。
第一步判断变更性质。如果团队只是把这一依赖记录到条目下，调整任务顺序，先完成不依赖该接口的部分，同时与外部系统负责人确认接口时间，这属于澄清：交付内容仍是订单状态同步，迭代目标不变，变化的是执行安排和风险可见性。如果接口短期内无法就绪，团队决定新增一条“手工对账流程”作为替代交付项，以保证本轮仍有可用结果，这就属于范围变更：交付内容发生了替换，需要产品负责人决策。
第二步处理与记录。澄清情形下，团队在条目中补充依赖说明、影响范围和预计解除时间，在每日同步中持续跟踪，必要时同步产品负责人。范围变更情形下，提出方说明替代方案的原因与影响，产品负责人评估后确认是否替换、原条目如何处置，记录中写明变更原因、受影响的条目和替代安排。
第三步看结果。若迭代目标未受影响，按调整后的安排继续执行，迭代评审时对照验收条件确认交付。若原条目最终未完成，在迭代结束时逐项评估：接口是否已就绪、需求是否仍有价值、是否需要拆分，再由产品负责人决定是否重新排入下一迭代。整个过程的关键在于，每一步变化都被显式判断和记录，而不是在执行中悄悄改变承诺。
常见问题
迭代中工作量比预估增加很多，这算澄清还是范围变更？
工作量增加本身不构成范围变更。如果实现的是同一交付物，只是发现比预估更复杂，需要补充任务拆解、重新估算剩余工时，这属于澄清与重新估算，交付内容没有变化。
但如果隐藏工作量导致原条目无法在迭代内完成，团队需要引入替代交付项或调整迭代目标来应对，这时交付内容发生了变化，应按范围变更处理，由产品负责人决策并记录影响。
澄清类变更需要走审批流程吗？
澄清通常不需要审批流程，由团队在迭代内确认并留痕即可。具体做法是把补充的验收条件、依赖说明或任务拆解写入对应条目，保留修改记录，让相关角色知情。
涉及验收口径变化时，应当同步产品负责人或需求提出方确认，避免团队自行改变“完成”的标准。留痕的价值在于后续确认和迭代回顾时有据可查，而不是增加审批环节。
迭代结束时未完成项可以直接放到下一迭代继续做吗？
不建议默认直接结转。两次迭代之间，需求优先级和团队容量往往已经变化，自动顺延会假设这两点不变。
更稳妥的做法是逐项重新评估：该条目是否仍有价值、是否需要拆分、阻塞是否已解除，然后回到产品待办清单由产品负责人重新排序，团队核算容量后确认下一迭代能承接哪些内容。未完成原因可在迭代回顾中记录，作为后续估算的输入。
等价替换为什么有时算澄清、有时算范围变更？
关键看替换是否改变了交付物本身以及是否经过显式决策。如果只是实现方式调整、最终交付物不变，属于澄清；如果用另一项内容替换原交付项，即使工作量相近，交付内容已经变化，属于范围变更。
判断时不要只看工作量是否相当，而要看替换后“本次迭代交付什么”是否与原来一致，以及替换决定是否由产品负责人显式做出并记录。
范围变更记录应该写哪些内容，才不至于流于形式？
记录至少应包含变更原因、受影响的条目、对迭代目标和其他交付项的影响，以及替代安排。这样后续进度判断、对外沟通和迭代回顾才有依据。
记录的目的不是增加流程负担，而是让决策显式化。范围变更本身不代表流程失败，迭代中信息变化是常态，关键是影响被评估过、取舍被明确过。
