Sprint Backlog变更：哪些属于澄清，哪些改变迭代范围

2026年11月4日

Sprint Backlog的变更可以按一条界线快速归类：是否改变本次迭代承诺的交付边界。补充说明、细化验收口径、明确实现方式，以及记录新发现的依赖与阻塞，属于澄清，迭代范围不变；新增或删除条目、替换为不等价的工作内容、验收标准实质调整导致交付内容变化，属于范围变更，需要与产品负责人重新协商并更新迭代目标。本文围绕迭代执行场景，说明两类变更的判断依据、处理动作，以及未完成项在迭代结束时如何重新评估。

Table of Contents

要点总览（TL;DR）

判断一条Sprint Backlog变更属于澄清还是范围变更，看它是否改变本次迭代承诺的交付边界：交付内容、验收口径、工作量承诺三者中任一项实质变化，就按范围变更处理。
补充验收细节、明确实现方式、细化任务拆解、记录新发现的依赖与阻塞，属于澄清，登记并同步即可，不需要走协商审批。
新增或删除条目、替换为不等价的工作内容、验收标准实质调整导致交付内容改变，属于范围变更，需要与产品负责人协商并更新迭代目标。
迭代中发现依赖或阻塞时，先判断是否影响已承诺交付：不影响则记录后继续，影响但工作量不变按澄清调整任务顺序，导致交付内容变化按范围变更协商。
未完成项在迭代结束时回到产品Backlog重新排序，按剩余价值、依赖状态、风险和优先级重新评估后再决定是否进入下一迭代，不默认自动结转。

一句话判断：澄清与范围变更的分界线

判断一条变更属于澄清还是范围变更，看它是否改变本次迭代承诺的交付边界。交付内容、验收口径、工作量承诺三者中任何一项发生实质变化，就进入范围变更；三者保持原样，只是把原本模糊的地方说清楚，就属于澄清。

这条规则可以拆成三个检查点：

交付内容：迭代结束时对外交付的东西是否增减或替换。条目数量变化、交付物被换成另一件事，属于范围变更。
验收口径：验收标准是在原有交付内容上写得更具体，还是把交付内容本身改成了另一件事。前者是澄清，后者是范围变更。
工作量承诺：团队承诺的投入是否实质增减。用一件等价工作量的事替换另一件，交付内容变了，仍按范围变更处理；只是把一件事拆成更细的任务，工作量不变，属于澄清。

一个可以直接使用的自检问题是：“如果这条变更成立，迭代评审时我们向利益相关方展示的交付物清单会不会不一样？”清单不变，按澄清处理；清单变了，按范围变更协商。

Sprint Backlog的范围边界：它承诺了什么

Sprint Backlog是本次迭代选中的产品Backlog条目，加上团队为完成这些条目所做的任务拆解，它与迭代目标共同构成团队在迭代期间的执行依据。它记录的是“这个迭代做什么、做到什么程度”，产品Backlog作为需求池管理全部需求，两者的层级和职责不同。

理解这条边界，需要区分承诺的对象。团队承诺的是交付内容与迭代目标，即哪些条目要在迭代结束时达到可评审的状态；具体任务怎么拆、先做哪一步、用哪种实现方式，属于执行细节，团队在迭代中自行调整。这一区分直接决定了变更归类：调整任务顺序、细化任务拆解，不触碰承诺对象，属于澄清；改动条目本身或迭代目标，触碰了承诺对象，属于范围变更。

在迭代规划阶段，产品负责人按优先级把需求规划进迭代，团队在计划会议上评审需求，对本次迭代要完成的需求与验收标准达成一致后再做任务拆解。这一步把“承诺什么”固定下来，后续判断变更时才有可比对的基准。

属于澄清的变更：补充信息、细化口径、记录依赖

澄清类变更的共同特征是把已有条目说得更清楚，交付内容和工作量承诺保持不变。迭代中常见的澄清包括以下几类：

补充验收细节：原验收标准写“支持批量导入”，澄清为“单次导入不超过5000行，失败行给出错误提示”。交付内容仍是批量导入，只是验收口径更具体。
明确实现方式：团队在讨论中确定接口复用已有服务、前端沿用现有组件，这类决定影响任务拆解，不影响对外交付物。
细化任务拆解：把一个开发任务拆成接口、页面、联调三个子任务，或补充测试用例设计任务，工作量归属不变。
记录新发现的依赖、阻塞与风险：发现某功能依赖外部系统联调窗口、某环境暂时不可用，把信息登记到对应条目上，供每日站会同步。

澄清类变更的处理重点是登记与同步，而非审批。把补充的验收细节写回条目描述，把依赖和阻塞记录在对应工作项上并标注影响的任务，在每日站会借助看板对齐进度与风险。登记的价值在于让团队和产品负责人看到同一份信息，避免验收时对口径产生分歧。同步对象包括负责该条目的开发、测试人员，以及需要知晓依赖状态的产品负责人。

改变迭代范围的变更：新增、删除与验收口径实质调整

范围变更的识别清单可以归纳为四类情形：

情形	判断要点	处理动作
新增条目	迭代内加入原计划外的需求，无论大小	与产品负责人协商，评估是否替换出等价工作量的条目
删除已承诺条目	已进入Sprint Backlog的条目被移出	确认迭代目标是否仍可达成，更新Sprint Backlog
替换为不等价的工作内容	交付物换成另一件事，工作量或价值不对等	按范围变更协商，同步调整迭代目标
验收标准实质变化	验收口径的调整改变了交付内容本身	重新确认交付边界，必要时走协商流程

这四类情形都会让迭代评审时展示的交付物清单发生变化，因此需要产品负责人参与决策。处理流程通常是：提出变更的人说明变更内容与原因，团队评估对迭代目标的影响，产品负责人决定接受、拒绝或替换，接受后更新迭代目标与Sprint Backlog，并在团队内同步。

需要留意“等价替换”的边界。用一件工作量相近的事替换另一件，交付内容已经改变，仍属于范围变更，只是协商时更容易达成一致。工作量相等不等于范围不变，判断依据始终是交付边界。

迭代中发现新依赖或阻塞时怎么处理

依赖和阻塞出现时，先归类再处置，顺序如下：

判断是否影响已承诺交付：这条依赖或阻塞是否会导致某个已承诺条目无法在迭代结束时达到可评审状态。不影响，记录后继续执行。
影响交付但工作量不变：例如联调窗口推迟两天，但通过调整任务顺序仍可在迭代内完成。按澄清记录依赖信息，调整任务顺序，在站会上同步新的排期。
导致交付内容变化：例如外部接口本迭代无法提供，原定功能只能交付部分能力或换成替代方案。按范围变更与产品负责人协商，明确本迭代实际交付什么，更新迭代目标。
阻塞无法在迭代内解除：把该条目从本次迭代的承诺中移出，按范围变更处理，同时评估迭代目标是否需要调整；条目回到产品Backlog等待重新排期，阻塞原因记录清楚，避免下次规划时重复踩坑。

这个顺序的关键是先回答“交付边界是否变化”，再决定走澄清还是协商。迭代中借助看板可视化任务状态和阻塞情况，能让依赖问题在每日站会上被及时看到，减少临近评审才发现交付缺口的情况。

未完成项如何重新评估，而不是默认结转

迭代结束时，未完成项应回到产品Backlog重新排序，由产品负责人结合当前信息决定去向，默认顺延到下一迭代会让需求池的优先级失真。重新评估可以围绕四个维度展开：

剩余价值：这条需求对用户和业务的价值是否因时间推移而变化，是否已被其他交付覆盖。
依赖状态：阻塞它的外部依赖是否已解除，解除时间是否可预期。
风险：未完成的原因是否指向技术风险或需求本身的不确定性，继续投入前是否需要先做验证。
优先级：与产品Backlog中其他待办相比，它现在排在第几位。

评估完成后，再决定它是否进入下一迭代、以什么粒度进入。与范围变更记录的关系在于：迭代中已按范围变更协商移出的条目，其移出原因和协商结论应保留在条目上，重新评估时直接作为输入，避免重复讨论。迭代回顾会上结合燃尽图、工时日志等数据复盘进度偏差，也能为未完成项的归因提供依据。

在工具层面，这类收尾动作可以这样承接：未完成的工作项从当前迭代移回需求池，保留原迭代、移出原因和阻塞记录，产品负责人在需求池中重新排序后再规划进下一迭代。ONES的迭代规划与看板跟踪覆盖了从需求进入迭代、任务拆解到状态跟踪的过程，未完成项的回收与重排仍需团队按上述维度人工判断，工具负责让判断依据可查。

常见误解与具体例子

误判一：把新增小需求当作澄清直接塞进迭代。“就加一个导出按钮，半天的事”——这类说法把工作量小等同于范围不变。只要它是原计划外的交付内容，迭代评审时的交付物清单就变了，应按范围变更与产品负责人协商，常见做法是替换出等价工作量的其他条目，或放入下一迭代。

误判二：把验收细节补充误判为范围变更。测试人员提出“导入失败时希望提示具体行号”，交付内容仍是批量导入，只是验收口径更具体，属于澄清。若每次细化验收都走协商流程，团队会把精力耗在流程上，反而拖慢迭代。

完整例子：某迭代承诺交付“订单列表支持按状态筛选”。执行到第三天，团队发现筛选所依赖的订单状态字段由另一个系统提供，对方本迭代只能提供部分状态值。团队先判断：按现有状态值，筛选功能可以交付，但“全部状态可选”的验收口径无法满足。这里的处理分两步：依赖信息按澄清记录在条目上，站会同步；验收口径从“全部状态可选”调整为“支持已提供的状态值，其余状态下迭代补齐”，交付内容实质缩小，按范围变更与产品负责人协商，确认迭代目标相应调整。若后续发现对方系统整体延期、筛选功能无法交付，则该条目移出本迭代，回到产品Backlog重新评估。

这个例子说明，同一个依赖事件可能同时产生澄清记录和范围变更，关键是分别判断：信息补充走登记，交付边界变化走协商。