迭代执行中收到新信息时，Sprint Backlog 的更新先要分清两类情况：验收口径、实现方式、任务拆分、依赖确认时间这类澄清类变化，只改条目细节；新增需求、需求取消、依赖导致工作量明显变化这类范围类变化，需要产品负责人和团队共同判断是否纳入本迭代、替换等量工作或移出。迭代结束时，未完成项要逐条重新评估去向，不默认结转到下一迭代。
要点总览（TL;DR）
- 先判断变化性质：验收标准细化、实现方案调整、任务拆分、依赖确认时间属于澄清类，只改条目细节；新增需求、需求取消、依赖导致工作量明显变化属于范围类，需要产品负责人和团队共同决策。
- 用三个问题做分类：是否改变迭代目标、是否改变承诺交付物、是否显著改变总工作量，任一为是即按范围类处理。
- 更新按登记、归类、评估、调整、同步五步执行，范围类变化必须留下决策结论和替换或移出安排，并同步受影响方。
- 迭代收尾时未完成项逐条评估剩余价值、剩余工作量和依赖状态，去向包括回到产品待办重新排序、拆分进入后续迭代、关闭或合并，不默认整体结转。
先判断：哪些更新只改细节，哪些会改变迭代范围
拿到一条新信息，先不要急着改条目。用三个问题做一次快速判断：这次变化是否改变迭代目标？是否改变本迭代承诺交付的成果？是否显著改变本迭代的总工作量？三个问题中任一答案为“是”，就按范围类变化处理；三个都为“否”，通常属于澄清类变化，改条目细节即可。
澄清类变化的典型情形包括：验收标准从“支持导出”细化为“支持按日期范围导出 CSV”；实现方案从方案 A 调整为方案 B，但交付物不变；把一个任务拆成三个子任务，总工作量基本不变；依赖方确认了接口联调的具体时间，原计划不变。这类变化影响的是“怎么做”和“做到什么程度算完成”，迭代目标和承诺范围保持稳定。
范围类变化的典型情形包括：业务方在迭代中途提出一个原计划外的新需求；已承诺的需求被取消或大幅缩减；外部依赖延期导致某项工作的工作量明显增加，或需要等待而无法在本迭代完成。这类变化会改变团队在本迭代能交付什么，必须进入范围变更判断，不能由某个人直接改动了事。
| 变化类型 | 判断问题 | 处理路径 | 决策人 |
|---|---|---|---|
| 澄清类：验收标准细化 | 交付物和总工作量是否不变？ | 更新条目描述与验收标准，通知测试与相关方 | 产品负责人确认口径，团队执行 |
| 澄清类：实现方案调整 | 迭代目标和交付成果是否不变？ | 更新任务说明与技术备注，评估是否影响剩余工作量 | 开发团队评估，迭代负责人记录 |
| 澄清类：任务拆分 | 拆分后总工作量是否基本一致？ | 在原条目下新增子任务，重新分配负责人 | 开发团队 |
| 澄清类：依赖确认时间 | 依赖时间是否仍在原计划窗口内？ | 补充依赖说明与确认时间，更新条目状态 | 迭代负责人跟踪 |
| 范围类：新增需求 | 是否改变承诺交付物或总工作量？ | 评估工作量，决定纳入并替换等量工作、放入产品待办或拒绝 | 产品负责人与团队共同决策 |
| 范围类：需求取消 | 是否释放出可重新分配的工作量？ | 移出条目，决定是否用其他待办项填补 | 产品负责人 |
| 范围类：依赖导致工作量明显变化 | 是否影响本迭代可完成的范围？ | 重新估算，调整范围或移出受影响条目 | 产品负责人与团队 |
分类的目的不是增加审批环节，而是让改动落在正确的层级上。澄清类变化如果被当成范围变更反复讨论，会拖慢执行；范围类变化如果被当成细节悄悄改掉，迭代承诺就失去意义，团队也无法解释为什么交付结果和计划不一致。
更新Sprint Backlog的操作步骤
一次完整的更新可以按“登记—归类—评估—调整—同步”五步走，每一步都有明确的输入和输出。下面按顺序说明，并给出变更记录应包含的字段。
第一步：登记新信息
输入是变化来源，可能是一条站会上的口头反馈、一封依赖方邮件、一次业务方沟通，或看板上某个任务状态异常。动作是把这条信息记录成一条可追踪的条目，写清来源、发现时间、涉及哪个 Sprint Backlog 条目、原始描述。输出是一条待处理的变化记录。完成标志是这条信息不再只存在于某个人的记忆或聊天记录里。
第二步：归类
输入是变化记录和当前 Sprint Backlog 条目状态。动作是用上一节的三个判断问题做归类，在记录中标注“澄清类”或“范围类”，并写明判断依据。输出是带分类结论的变化记录。完成标志是分类有明确理由，而不是凭感觉标注。
第三步：评估影响
输入是分类结果和条目现状。澄清类变化由开发团队评估是否影响剩余工作量、是否影响验收标准；范围类变化需要评估新增或减少的工作量、对迭代目标的影响、对依赖方的影响。输出是影响评估结论，包括剩余工作量变化、受影响的条目清单、需要谁参与决策。完成标志是评估结论能支撑下一步的调整动作。
第四步：调整条目字段
输入是影响评估结论。动作是修改 Sprint Backlog 条目的具体字段：描述、验收标准、剩余工作量、依赖关系、状态、负责人。范围类变化还要执行范围决策：纳入本迭代的，同时移出或缩减等量工作，保持总工作量可控；不纳入的，放入产品待办并说明原因；需要移出的，更新条目状态并通知相关方。输出是更新后的 Sprint Backlog 和一条完整的变更记录。完成标志是条目字段与实际理解一致，范围类变化有明确的替换或移出安排。
第五步：同步受影响方
输入是更新后的条目和变更记录。动作是在每日站会或专门的沟通中说明变化内容、决策结果和对各自工作的影响，确认依赖方已知悉时间调整。输出是受影响方的确认。完成标志是迭代目标表述同步更新，没有角色依据旧信息继续工作。
变更记录建议至少包含以下字段，便于事后追溯和迭代回顾使用：
- 变化编号与登记时间
- 信息来源与提出人
- 涉及的 Sprint Backlog 条目
- 变化类型（澄清类／范围类）与判断依据
- 影响评估：剩余工作量变化、受影响条目
- 决策结论与决策人
- 替换或移出的条目
- 同步对象与同步时间
在工具层面，这类更新需要能落到具体条目上。ONES Project 支持将需求和相关任务规划至迭代并分配负责人，提供看板、燃尽图等工具实时掌控当前进度，任务工时统计可用于估算任务持续时间。团队可以把变化后的条目字段、剩余工作量和依赖说明直接维护在工作项上，让站会讨论和看板状态指向同一份数据；具体字段配置以实际产品设置为准。
角色分工与各自交付物
更新能否落地，取决于每个角色是否清楚自己提出什么、评估什么、决定什么、同步什么。口头达成一致但无人记录，是迭代中最常见的失效方式。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 产品负责人 | 判断范围类变化的取舍与优先级，决定是否纳入本迭代、替换哪项工作或移出哪项工作 | 范围变更决策结论、优先级判断依据、与业务方的沟通结论 |
| Scrum Master 或迭代负责人 | 推动更新流程执行，跟踪阻塞与依赖，维护变更记录，组织站会同步 | 变更记录、阻塞跟踪清单、站会同步纪要 |
| 开发团队 | 评估工作量变化，完成任务拆分，确认技术依赖与实现方案 | 剩余工作量估算、子任务拆分结果、技术依赖确认说明 |
| 相关方（业务方、依赖方） | 及时提供新信息，确认依赖时间与交付条件，反馈对范围变化的意见 | 依赖确认时间、需求变更说明、对调整方案的确认 |
分工中有两个容易模糊的边界需要说清。第一，范围类变化的决策权在产品负责人，但决策需要团队提供工作量评估作为依据，产品负责人单方面拍板纳入新需求，容易造成迭代超载。第二，变更记录的维护责任在迭代负责人，但记录内容的准确性依赖提出人和开发团队如实填写，记录不是迭代负责人一个人的工作。
在 ONES 的敏捷研发管理场景中，迭代进度跟进可以借助敏捷看板在每日站会中对齐进度与风险、排除问题，团队还可通过燃尽图评估当前研发效率。这些可视化手段适合承载站会同步和阻塞跟踪；变更记录本身如果产品中没有专门的审批机制，可以用工作项备注、文档或团队约定的记录载体来补充，具体方式以团队实际配置为准。
示例：迭代中途出现新依赖与范围变化怎么处理
以下为演示情景，用于说明分类与更新过程，不代表真实项目数据。
某团队正在进行一个为期两周的迭代，迭代目标是完成订单查询页面的改版并上线灰度。迭代第 4 天，团队确认外部支付接口的联调时间从第 6 天推迟到第 10 天；同一天，业务方提出希望在本次迭代中增加一个订单导出按钮。
分类处理
支付接口延期：原计划第 6 天开始联调，现在推迟到第 10 天，而迭代第 10 天结束。这会影响“灰度上线”这一承诺交付物，属于范围类变化。订单导出按钮：属于原计划外的新增需求，需要评估工作量后由产品负责人决定，同样属于范围类变化。
条目字段调整
针对支付接口延期，团队把“支付联调”条目的依赖说明更新为“接口方确认第 10 天可联调”，剩余工作量按实际情况调整，状态标记为“阻塞”。产品负责人与团队评估后决定：本迭代灰度上线范围缩小为不包含支付环节的查询功能，支付联调移入下一迭代，迭代目标表述同步修改。针对订单导出按钮，开发团队估算约需 1.5 天，产品负责人判断其优先级低于当前迭代的查询性能优化，决定放入产品待办，不纳入本迭代，并向业务方说明原因。
变更记录示例
| 字段 | 记录内容 |
|---|---|
| 变化编号／时间 | CR-01／迭代第 4 天 |
| 来源与提出人 | 依赖方邮件；业务方口头提出 |
| 涉及条目 | 支付联调；订单查询页面改版 |
| 变化类型与依据 | 范围类：影响灰度上线交付物；新增需求改变总工作量 |
| 影响评估 | 支付联调阻塞至第 10 天；导出按钮约 1.5 天工作量 |
| 决策结论与决策人 | 灰度范围缩小、支付联调移入下一迭代；导出按钮放入产品待办。产品负责人与团队共同确认 |
| 替换或移出 | 移出支付联调；不纳入导出按钮 |
| 同步对象与时间 | 第 4 天站会同步全组，会后邮件通知业务方与依赖方 |
这个例子说明，两类变化可以在同一次更新中处理，关键是分别走各自的判断路径，并把决策结果写进同一条记录。站会同步时只讲结论和对各自工作的影响，细节留在记录里供查阅。
未完成项如何重新评估，而不是默认结转
迭代结束时，未完成项如果直接整体搬到下一个迭代，会让下一个迭代一开始就背负未经验证的工作量，范围逐渐膨胀，优先级也被历史包袱绑架。正确做法是逐条重新评估，再决定去向。
评估三个维度：剩余价值，这条工作对当前业务目标是否仍然重要；剩余工作量，距离完成还差多少，是否需要重新估算；依赖状态，阻塞是否已解除，依赖方是否给出新的时间。评估由产品负责人主持，开发团队提供工作量与依赖信息，迭代负责人记录结论。
| 评估结论 | 去向 | 记录信息 |
|---|---|---|
| 仍有价值且工作量可控 | 回到产品待办，按当前优先级重新排序，由下一次迭代规划决定是否纳入 | 剩余价值说明、重新估算的工作量、排序位置 |
| 价值仍在但工作量偏大 | 拆分为更小的条目，部分进入后续迭代 | 拆分方案、各子项工作量 |
| 依赖未解除或价值下降 | 暂缓或关闭，注明原因与重新评估条件 | 关闭原因、依赖状态、复查时间 |
| 与其他条目重复或已被替代 | 合并到相关条目或关闭 | 合并对象、替代关系 |
重新评估的结果要写进迭代回顾的输入材料，让团队看到哪些工作反复未完成、原因是什么。这比单纯统计完成率更有助于改进下一个迭代的规划质量。
完成检查：这次更新是否做到位
更新结束后，用下面这份清单逐项核对，全部通过才算闭环。
- 每条新信息都已登记，并标注了澄清类或范围类及判断依据。
- 范围类变化都有明确的决策结论和决策人，纳入本迭代的已安排替换或移出等量工作。
- Sprint Backlog 条目的描述、验收标准、剩余工作量、依赖关系、状态与实际理解一致。
- 迭代目标表述已随范围变化同步更新，没有保留过时的目标描述。
- 受影响的产品负责人、开发团队、测试人员和相关方都已收到变化通知并确认知悉。
- 变更记录包含来源、分类、影响评估、决策结论和同步时间，可供迭代回顾查阅。
- 迭代收尾时，每条未完成项都完成了剩余价值、剩余工作量和依赖状态的重新评估，并有明确去向。
- 未完成项的去向已反映在产品待办的排序或后续迭代规划中，没有未经评估的整体结转。
这份清单适合在每次范围类变化处理后快速过一遍，也适合在迭代结束前作为收尾检查。清单通过，说明这次更新在记录、决策、同步和收尾四个环节都留下了可追溯的结果。
常见问题
迭代中途业务方坚持要把新需求加进来，产品负责人应该怎么处理？
先让开发团队给出工作量估算，再对照本迭代的剩余容量做判断。可选路径有三条：纳入本迭代并移出或缩减等量工作，保持总工作量可控；放入产品待办，由下一次迭代规划决定；与业务方协商拆分，只纳入其中最小可交付的部分。
无论选哪条，决策结论、决策人和替换安排都要写进变更记录，并在站会上同步。产品负责人单方面拍板纳入而不做替换，容易造成迭代超载，也会让团队对承诺范围失去判断依据。
澄清类变化频繁出现，是否也需要每次都走完整流程？
不需要。澄清类变化的目标是让条目描述更准确，处理动作可以简化：由开发团队直接更新条目字段，迭代负责人在变更记录中留一行摘要即可，不必每次都组织范围讨论。
需要留意的是澄清类变化的累积效应。如果同一条目的验收标准反复细化、任务拆分后总工作量明显上升，说明它已经接近范围类变化，此时应重新用三个判断问题复核一次，避免细节调整掩盖了实际的范围扩张。
迭代结束时未完成项较多，全部重新评估会不会太耗时？
评估可以按条目价值分层处理。对剩余价值高、依赖已解除的条目，重点确认剩余工作量并放回产品待办排序；对长期阻塞或价值下降的条目，直接记录关闭原因和复查条件，不必展开详细估算。
耗时更多来自缺少日常记录：如果迭代中变更记录和阻塞跟踪是持续的，收尾评估主要是在已有信息上做判断；如果平时没有记录，收尾时才逐条回忆，成本自然高。把记录动作放到日常，是控制评估成本的有效方式。
团队规模较小、角色兼任时，这套分工怎么落地？
角色可以兼任，但职责边界仍要分清。例如产品负责人同时承担迭代负责人时，范围决策和变更记录维护由同一人完成，此时更需要把决策依据写清楚，让团队和其他相关方能复核。
关键是把“谁决策、谁记录、谁评估工作量”三件事落实到具体的人，而不是停留在角色名称上。团队人数少时，可以在站会上用几分钟完成登记和归类，把评估和记录放在会后处理，保持节奏紧凑。
变更记录应该记多细，才既够用又不成为负担？
记录以能支撑事后追溯和迭代回顾为准。至少包含变化来源、涉及条目、变化类型与判断依据、影响评估、决策结论与决策人、替换或移出安排、同步对象与时间。
澄清类变化可以只记摘要，范围类变化要记全字段。记录载体可以是工作项备注、团队文档或约定的表格，重点是团队能在回顾时查到当时为什么这样决定，而不是追求格式统一。
