迭代中出现新依赖、阻塞或范围变化时，未完成项不宜直接顺延到下一个迭代。团队需要先确认它实际完成到什么程度，判断变化属于澄清、阻塞还是范围调整，再重新估算剩余工作与依赖，决定留在当前迭代、退回产品Backlog、拆分还是关闭，最后把结论写回Sprint Backlog。本文按这条路径给出判断表、五步操作、角色分工、示例和完成检查，适用于迭代执行中的重新评估场景。
要点总览（TL;DR）
- 未完成项不默认结转：先确认实际完成程度，再判断变化性质，重新估算剩余工作与依赖，决定去向后回填Sprint Backlog。
- 变化分三类：澄清只更新验收标准与说明，阻塞记录原因与解除条件，范围变化须由产品负责人确认并调整迭代承诺。
- 五步操作依次为确认状态、判断原因、重新估算、决定去向、回填记录，每步都有输入、输出和完成标志。
- 产品负责人决策范围与优先级，开发人员负责剩余估算，迭代负责人组织评估并跟踪阻塞，记录人保证结论落到条目上。
- 评估收尾用检查清单核对：每条有明确去向、估算与依赖已更新、结论已同步给受影响角色。
先分清三类变化：澄清、阻塞与范围变化
重新评估的第一步是判断变化性质，因为它决定Sprint Backlog是原地更新，还是需要走范围变更确认。三类变化的区别在于：工作内容是否改变、迭代承诺是否改变。澄清和阻塞通常不改变迭代承诺，范围变化则会改变团队在本迭代内承诺交付的内容。
| 类型 | 典型表现 | 是否改变迭代范围 | 处理路径 | 确认角色 |
|---|---|---|---|---|
| 澄清类变化 | 验收标准补充、字段定义明确、交互细节确定；原估算基本成立 | 否 | 原地更新条目描述与验收标准，剩余估算按需微调 | 产品负责人确认验收口径，开发人员确认工作量影响 |
| 阻塞类变化 | 外部接口未就绪、测试环境不可用、第三方依赖延迟；工作内容不变但开始时间或完成时间受影响 | 否，但影响本迭代可完成量 | 记录阻塞原因与解除条件，调整条目时间安排，评估是否需要移出本迭代 | Scrum Master或迭代负责人跟踪阻塞，产品负责人确认调整后的取舍 |
| 范围变化 | 新增需求、原需求扩大或缩小、优先级调整导致本迭代承诺变化 | 是 | 提交产品负责人决策，明确替换、延后或移出本迭代的条目，更新迭代目标 | 产品负责人决策，团队评估影响 |
判断时容易混淆的是“阻塞导致的范围变化”：一个条目因外部依赖延迟无法在本迭代完成，如果团队决定用另一个需求替换它，这就同时包含阻塞和范围变化，需要按范围变化的路径由产品负责人确认，而不能只在条目上备注一句“延期”。另一类常见情况是把澄清当成范围变化：验收标准写得更细，但交付物和估算没有实质变化，这类只需更新条目说明，不必触发范围变更。
三类变化的处理路径不同，但共同要求是留下判断依据。判断表可以作为评估会的讨论底稿，会上逐条标注类型、影响和拟处理方式，避免会后凭记忆修改Sprint Backlog。
未完成项重新评估的五步操作
五步操作按“确认状态—判断原因—重新估算—决定去向—回填记录”的顺序推进，每一步都有明确输入、动作、输出和完成标志。评估可以由迭代负责人组织，在迭代结束前或发现重大变化时召开，参与人包括产品负责人、相关开发人员和记录人。
第一步：确认完成状态与剩余工作
输入是任务记录、代码或文档交付物、测试结果。动作是逐条核对条目实际完成到什么程度：哪些子任务已完成、哪些产出物已提交、哪些验收项尚未通过。输出是一句可核验的状态描述，例如“接口联调完成，异常分支未覆盖”。完成标志是该条目不再用“进行中”这类笼统状态表示，剩余工作可以被具体列出。
第二步：判断未完成原因
输入是第一步的状态描述和迭代中的变更记录。动作是把原因归入估算偏差、阻塞或范围变化三类：估算偏差指原估算明显偏低或遗漏了工作项；阻塞指外部条件未满足；范围变化指需求内容或优先级发生调整。输出是原因判断及对应证据，例如依赖方的排期邮件、澄清后的验收标准。完成标志是每条未完成项都能对应到一类原因，且判断有记录可查。
第三步：重新估算剩余工作量与依赖
输入是原因判断和当前团队可用时间。动作是由实际执行该条目的开发人员给出剩余工作量估算，列出仍未解除的依赖及其预计解除时间；如果条目过大或包含多个可独立交付的部分，拆分为更小的条目。输出是新的剩余估算、依赖清单和拆分结果。完成标志是估算由执行者确认，依赖有明确的责任方和预计时间，拆分后的条目各自可独立验收。
第四步：决定去向
输入是重新估算结果和迭代剩余容量。动作是在四种去向中选择：留在当前迭代、退回产品Backlog、拆为新条目、关闭。留在当前迭代适用于剩余工作可在迭代内完成且依赖可解除的情况；退回产品Backlog适用于本迭代已无法完成或优先级下降的情况；拆为新条目适用于原条目包含多个交付物、需要分别安排的情况；关闭适用于需求已取消或已被其他条目覆盖的情况。输出是每条未完成项的去向结论。完成标志是结论明确到具体条目，没有“待定”状态。
第五步：回填Sprint Backlog
输入是去向结论和重新估算结果。动作是更新Sprint Backlog条目，写明新的剩余估算、负责人、依赖说明、完成标志和变更原因；退回产品Backlog的条目同步更新其优先级和说明；拆分的条目建立与原条目的关联。输出是更新后的Sprint Backlog。完成标志是条目字段完整、相关角色可查看，且迭代目标或范围如有调整已同步更新。
在回填环节，团队通常需要在工作项上同时维护状态、负责人、估算和依赖说明。使用ONES Project时，需求和相关任务可以规划至迭代并分配负责人，需求支持自定义状态与多种属性，团队可以把重新评估后的结论写入对应字段，让Sprint Backlog成为后续跟踪的依据。具体字段配置以实际环境为准。
角色分工与交付物
重新评估如果只由一个人完成，容易把技术判断、价值判断和记录混在一起。明确分工后，每个角色在评估会上带什么、交什么，可以直接对照下表执行。
| 角色 | 职责 | 评估会交付物 |
|---|---|---|
| 产品负责人 | 判断条目价值与优先级，决定是否退回产品Backlog，确认范围变化 | 去向决策、优先级调整说明、范围变更确认记录 |
| Scrum Master或迭代负责人 | 组织评估会，跟踪阻塞解除，维护评估流程和Sprint Backlog完整性 | 评估会议程与结论、阻塞清单及跟踪人、更新后的Sprint Backlog |
| 开发人员 | 提供剩余工作估算、技术依赖判断和拆分建议 | 剩余估算、依赖说明、拆分后的条目 |
| 记录人 | 更新条目状态、说明和关联关系，同步结论 | 条目变更记录、同步通知 |
分工的关键是决策权与记录权分离：产品负责人对范围和优先级做决定，开发人员对技术估算负责，记录人保证结论落到条目上。迭代负责人可以在评估会上逐条确认“谁决策、谁估算、谁记录”，减少会后反复。评估会本身不需要很长，重点是每条未完成项都经过判断并有结论。
示例：一次迭代中段的重新评估
以下为演示情景，用于说明评估前后条目字段的变化，不代表真实项目数据。
某迭代进行到中段，团队发现“订单查询接口改造”依赖的外部认证服务排期推迟两周，同时产品负责人澄清了该条目的验收标准：需要覆盖超时重试场景。团队在每日同步中发现这一情况后，由迭代负责人组织了一次短会，按五步操作处理。
第一步确认状态：接口改造的代码已完成，联调因认证服务未就绪而暂停，超时重试场景尚未开发。第二步判断原因：认证服务延迟属于阻塞，验收标准补充属于澄清，两者叠加导致条目无法按原计划完成。第三步重新估算：开发人员评估剩余工作为联调验证和超时重试开发，依赖认证服务的测试环境，预计解除时间在迭代结束后。第四步决定去向：由于依赖解除时间晚于迭代结束，产品负责人决定将该条目退回产品Backlog并保留优先级，本迭代不再承诺完成；超时重试部分拆为新条目，待认证服务就绪后安排。第五步回填：更新原条目状态和说明，建立新条目与原条目的关联，记录阻塞原因和决策结论。
| 字段 | 评估前 | 评估后 |
|---|---|---|
| 状态 | 进行中 | 已退回产品Backlog |
| 剩余估算 | 原估算3人天 | 联调验证2人天，超时重试开发1人天（拆为新条目） |
| 依赖说明 | 无 | 依赖外部认证服务测试环境，预计迭代结束后可用 |
| 负责人 | 原负责人 | 原负责人保留，新条目另行指派 |
| 完成标志 | 接口改造完成 | 联调通过且超时重试场景验收通过 |
| 变更原因 | 无 | 外部依赖延迟，验收标准补充 |
评估结论同步给产品负责人、测试人员和依赖方接口人：产品负责人确认退回和拆分决定，测试人员了解新条目的验收范围，依赖方接口人收到环境就绪时间的跟踪要求。同步后，Sprint Backlog中不再保留无法完成的承诺，团队可以按调整后的范围继续推进。
完成检查：重新评估是否做到位
评估会结束前，可以逐项核对以下检查项。全部通过，说明本次重新评估可以结束；有未通过项，应明确补做责任人和时间。
- 每条未完成项都有明确去向，没有默认结转或“待定”状态。
- 剩余工作量和依赖已更新，估算由实际执行者确认。
- 范围变化经过产品负责人确认，迭代目标或承诺范围已相应调整。
- Sprint Backlog条目包含负责人、完成标志和依赖说明，变更原因可查。
- 拆分或退回的条目与原条目建立了关联，避免重复跟踪或遗漏。
- 评估结论已同步给受影响的产品、开发、测试和依赖方角色。
- 阻塞项有跟踪人和预计解除时间，并纳入后续每日同步。
检查清单的作用是防止评估停留在讨论层面。团队可以把清单作为评估会的收尾环节，由迭代负责人逐项确认，记录人同步更新条目。下一次迭代规划时，退回产品Backlog的条目会重新参与优先级排序，而不是自动回到迭代中。
常见问题
迭代中验收标准被补充细化，需要走范围变更吗？
通常不需要。验收标准写得更细、字段定义更明确，只要交付物和剩余工作量没有实质变化，就属于澄清类变化，原地更新条目描述与验收标准即可。判断依据是工作内容是否改变：如果补充的验收项需要新增开发或测试工作，剩余估算应同步调整，并在评估会上说明工作量影响；如果只是把原有要求写清楚，不必触发范围变更。
阻塞项在迭代结束前解除了，还能留在当前迭代吗？
可以，前提是剩余工作能在迭代剩余时间内完成，且估算由实际执行者确认。阻塞解除后应重新核对剩余工作量和可用时间，再决定是否留在当前迭代。如果解除时间接近迭代结束、剩余工作无法完成，仍应按退回产品Backlog或拆分的路径处理，避免把无法兑现的条目留在迭代承诺里。
退回产品Backlog的条目，下个迭代会自动回到Sprint Backlog吗？
不会自动回到迭代中。退回产品Backlog的条目需要重新参与优先级排序，由产品负责人在下一次迭代规划时与团队共同评审，再决定是否纳入。这样处理可以避免未完成项不经评估就顺延，也能让优先级在两次规划之间根据新信息重新比较。
评估会需要全员参加吗，多长时间合适？
不需要全员参加。参与人通常包括产品负责人、涉及条目的开发人员、迭代负责人和记录人，其他成员可以会后查看结论。会议时长取决于未完成项数量，重点是逐条完成性质判断和去向决策，而不是逐项复述任务细节。条目较多时可以先由开发人员准备状态描述和剩余估算，会上直接讨论分歧点。
重新评估的结论记录在哪些字段里，后续怎么跟踪？
至少记录状态、剩余估算、负责人、依赖说明、完成标志和变更原因，拆分或退回的条目与原条目建立关联。使用ONES Project时，需求和相关任务可以规划至迭代并分配负责人，需求支持自定义状态与多种属性，团队可以把评估结论写入对应字段，让Sprint Backlog成为后续跟踪依据；具体字段配置以实际环境为准。
