迭代未完成项如何重新评估并放回Sprint Backlog

迭代执行中出现新依赖、阻塞或范围变化时，处理顺序是先判断变化性质，再更新Sprint Backlog；迭代结束时，未完成项逐项重新评估，不默认结转到下一迭代。本文给出澄清与范围变更的分类口径、更新步骤、未完成项评估字段与判定规则，并说明各角色留下的记录，帮助迭代负责人和产品负责人把变化处理成可追溯的决策。

要点总览（TL;DR）

• 迭代中出现新信息时先分类：验收条件细化、依赖说明补充属于澄清，不改动迭代承诺；新增需求、目标或交付时间变化属于范围变更，需要产品负责人确认取舍。
• 更新Sprint Backlog按登记来源、评估影响、确认结论、更新条目字段、同步相关角色五步执行，每步留下可查看的记录。
• 迭代结束时未完成项逐项评估剩余工作量、阻塞状态、目标相关性、依赖变化和风险，结论为放回产品待办、拆小进入下一迭代或关闭放弃。
• 产品负责人确认验收口径与处置结论，迭代负责人组织评估并维护Sprint Backlog最终状态，开发与测试提供技术评估和验证状态。
• 结算后用检查清单核对：变更分类有记录、未完成项无默认结转、评估字段完整、处置结果已同步。

先分清澄清与范围变更

新信息进入迭代时，第一步是判断它改变的是“对已有承诺的理解”，还是“承诺本身”。澄清类变化让团队更准确地完成已承诺的事项，迭代目标和交付范围保持不变；范围变更则改变要交付的内容、目标或时间，必须经过确认和取舍。判断口径不统一，团队就容易把新增需求当作澄清顺手接进来，也会把正常的验收条件细化误当成变更反复开会。

下表给出两类变化的典型情形与处置动作，可作为迭代中的快速对照。

判断维度	澄清类变化	范围变更
典型情形	验收条件细化、依赖说明补充、实现约束明确、接口字段口径确认	新增需求、迭代目标调整、交付时间变化、交付范围扩大或削减
对迭代承诺的影响	不改变已承诺交付的内容与目标	改变交付内容、目标或时间，需要重新取舍
处理动作	补充到对应工作项的描述、验收条件或依赖说明中，同步相关角色	登记变更来源与影响，评估工作量与风险，由产品负责人确认取舍
确认人	产品负责人确认验收口径，迭代负责人确认实现约束可执行	产品负责人决定是否纳入及替换哪些内容，迭代负责人评估团队容量
记录要求	在工作项中留下补充说明及确认时间	留下变更记录：来源、影响、取舍结论、确认人

判断不清时，按“先按变更处理”的保守口径升级：由迭代负责人收集变化来源、影响的工作项和初步工作量判断，提交产品负责人确认；涉及跨团队依赖的，同时知会依赖方负责人。升级的目的是在当日内形成结论，避免事项悬置到迭代后期才暴露。若变化只是措辞或文档格式调整，不影响验收判断和实现方式，可由迭代负责人直接判定为澄清并记录。

迭代执行中更新Sprint Backlog的操作步骤

变化性质确认后，更新Sprint Backlog需要留下完整链路：谁提出的、影响哪些条目、如何确认、条目改成了什么状态。以下步骤适用于迭代执行期间，每一步都给出输入、动作与输出。

1. 登记变化来源。输入是提出方、提出时间、原始描述和关联工作项；动作是在迭代的变更记录中登记一条记录，标注初步分类（澄清或范围变更）；输出是带编号的变更条目。完成标志是记录中能看到来源与关联项。
2. 评估影响范围。输入是变更条目和当前Sprint Backlog；动作是列出受影响的工作项、依赖方、预计工作量变化和对迭代目标的影响；输出是影响清单。完成标志是受影响条目均有明确结论：不受影响、需补充说明或需调整范围。
3. 确认处置结论。输入是影响清单；动作是澄清类由产品负责人确认验收口径后直接补充，范围变更由产品负责人与迭代负责人共同确认取舍，明确纳入什么、移出什么；输出是确认结论与确认人。完成标志是结论写入变更记录，且没有“待定”项进入执行。
4. 更新条目字段。输入是确认结论；动作是修改对应工作项的描述、验收条件、依赖说明、负责人、工作量或状态，新增内容建立新的工作项并关联原变更记录；输出是更新后的Sprint Backlog。完成标志是条目字段与确认结论一致。
5. 同步相关角色。输入是更新后的Sprint Backlog；动作是在每日站会或迭代沟通中说明变化及影响，知会测试、依赖方等角色；输出是知悉确认。完成标志是相关角色能说清自己受影响的任务及新的完成时间。

在工具承载上，ONES 支持团队成员围绕迭代要完成的需求处理自己拆解的任务，并通过敏捷看板管理任务状态；每日站立会议中可以借助看板对齐迭代进度与风险。这些能力适合承载上述第4、5步的状态更新与同步动作。变更记录本身建议在迭代的工作项或文档中单独维护，确保评估结论与条目状态可以对照查看。

未完成项重新评估的字段与判定规则

迭代结束时，未完成项不自动进入下一迭代。默认结转会把上一迭代的假设原样带入新迭代，掩盖阻塞未解除、优先级已变化等问题。正确做法是在迭代回顾或结算会议上逐项评估，评估时点为迭代结束后的一个工作日内，参与角色包括产品负责人、迭代负责人，必要时邀请开发与测试代表说明阻塞原因。

评估按下表字段逐项填写，字段缺失的条目不得进入处置环节。

评估字段	填写内容	用途
剩余工作量	按团队估算口径重新估算的剩余工时或故事点，注明估算人	判断是否还能在下一迭代容量内完成
阻塞状态	已解除、部分解除、未解除，注明阻塞原因与责任方	决定是否具备继续推进的条件
目标相关性	仍服务当前迭代目标、服务下一迭代目标、暂不服务任何目标	判断是否值得占用下一迭代容量
依赖变化	依赖方是否变更、交付时间是否变化、是否出现新依赖	识别重新排期的前置条件
风险	技术风险、需求不确定性、外部协调风险及影响程度	决定是否需要拆分或先做验证
处置结论	放回产品待办、拆小进入下一迭代、关闭放弃	形成可执行的下一步

判定规则可以归纳为三条。阻塞未解除且短期内无法解除的，放回产品待办并注明解除条件；剩余工作量明显超出下一迭代可分配容量，或风险较高的，拆分为更小的条目，只把可验证的部分放入下一迭代；目标相关性已消失、需求被替代或投入产出不成立的，关闭放弃并记录原因。每条结论都要写明判定依据和确认人，与评估字段一起保存在迭代记录中，供后续回顾和审计使用。

角色分工与交付物

变更处理和未完成项评估涉及多个角色，职责不清会出现“都知道了但没人确认”的情况。下表按角色列出在澄清、变更确认和未完成项评估中的动作与产出归属。

角色	澄清类变化	范围变更	未完成项评估	交付物归属
产品负责人	确认验收条件与优先级口径	决定是否纳入、替换或推迟哪些内容	判断目标相关性，确认处置结论	变更确认结论、处置结论
迭代负责人	确认实现约束可执行，更新条目	评估团队容量与影响，组织确认	组织逐项评估，汇总评估表	Sprint Backlog更新记录、评估表
开发团队	补充实现约束与技术说明	提供工作量与风险评估	填写剩余工作量、阻塞状态、风险	技术评估意见
测试	补充验收用例与测试条件	评估测试范围与回归影响	说明未完成项的验证状态	测试影响说明

记录归属遵循“谁确认谁留痕”：产品负责人的确认结论写入变更记录或评估表，迭代负责人维护Sprint Backlog的最终状态，开发与测试的评估意见附在对应工作项下。ONES 支持产品负责人根据需求优先级将产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同评审需求；这一规划动作同样适用于评估后将条目重新安排到下一迭代或放回待办列表的场景。

示例：一次依赖阻塞引发的重新评估

以下为演示情景，用于说明规则如何落地。某团队在迭代进行到第6天时发现，订单查询功能依赖的第三方接口尚未提供测试环境，相关两个开发任务和一项联调任务无法继续。

判断过程。迭代负责人先登记变化：来源为开发人员，关联三个工作项。团队核对后确认，接口字段口径没有变化，变化在于环境就绪时间推迟，属于依赖说明补充，不改变迭代目标中已承诺的其他功能。因此按澄清类处理：在产品负责人确认验收口径不变后，把新的环境就绪时间和联调前置条件补充到相关工作项的依赖说明中，并知会测试调整验证顺序。

未完成项评估。迭代结束时，三个工作项仍未完成。团队逐项填写评估字段：剩余工作量合计约5人日；阻塞状态为未解除，责任方为外部接口团队；目标相关性为仍服务下一迭代目标；依赖变化为接口环境预计下个迭代第3天就绪；风险为联调时间被压缩。处置结论为：联调任务拆分为“接口契约验证”和“端到端联调”两个条目，前者在下一迭代第1天可开始，放入下一迭代；两个开发任务中已完成部分保留在原条目，剩余部分放回产品待办，待环境就绪后重新排期。

留下的记录。变更记录中保存了依赖说明补充的内容与确认人；评估表中保存了三个条目的字段填写与处置结论；Sprint Backlog中相关条目状态更新为已移出或已拆分，并关联原变更记录。下一迭代计划会议前，迭代负责人核对放回待办的条目是否具备重新排期条件，产品负责人确认优先级顺序。

完成检查：评估是否到位

迭代结算后，可用以下清单核对变更处理与未完成项评估是否合规。每项都应有可查看的记录，而不是口头确认。

• 本次迭代出现的每一条新信息都有分类记录，标注为澄清或范围变更，并写明判断依据。
• 范围变更均有产品负责人的确认结论，明确纳入、替换或推迟的内容，没有未经确认就进入执行的事项。
• 所有未完成项均逐项填写评估字段，不存在直接结转到下一迭代的条目。
• 每条未完成项的处置结论为放回产品待办、拆小进入下一迭代或关闭放弃之一，并写明判定依据和确认人。
• 评估表、变更记录与Sprint Backlog中的条目状态一致，拆分或移出的条目能追溯到原条目。
• 处置结果已同步给产品负责人、开发、测试及受影响的依赖方，下一迭代计划会议可以直接基于更新后的待办列表进行排期。

检查中发现缺项的，应在下一迭代计划会议前补齐；连续多个迭代出现同类阻塞的，可在回顾中把阻塞原因转化为依赖管理或环境准备的改进项，减少未完成项的产生。

常见问题

迭代中途发现依赖方交付延期，应该算澄清还是范围变更？

先看延期是否改变已承诺交付的内容、目标或时间。若交付内容和迭代目标不变，只是依赖就绪时间推迟，属于依赖说明补充，按澄清处理：把新的就绪时间和前置条件写入相关工作项的依赖说明，同步测试调整验证顺序。若延期导致原定交付时间无法满足，或需要削减、替换交付内容，则属于范围变更，由产品负责人确认取舍后再调整Sprint Backlog。

未完成项评估应该在什么时间完成，由谁组织？

建议在迭代结束后的一个工作日内完成，由迭代负责人组织，产品负责人参与确认处置结论，必要时邀请开发与测试代表说明阻塞原因和验证状态。评估拖到下一迭代计划会议当天，容易在容量压力下退化为默认结转，逐项评估就失去意义。

剩余工作量重新估算和原估算差距很大时怎么处理？

以重新估算的结果为准，并在评估记录中注明估算人和差距原因。差距明显说明原估算假设已不成立，此时应结合风险字段判断是否需要拆分：把可验证的部分拆成更小的条目放入下一迭代，其余部分放回产品待办重新排期。原估算保留在历史记录中，便于回顾时分析估算偏差的来源。

放回产品待办的条目还需要重新排优先级吗？

需要。放回产品待办意味着该条目重新参与整体优先级排序，产品负责人应结合当前业务价值和依赖就绪情况确认它在待办列表中的位置，而不是沿用原迭代中的顺序。ONES 支持产品负责人根据需求优先级将产品待办列表中的需求规划至对应迭代，这一动作同样适用于评估后重新安排条目的场景。

团队连续几个迭代都出现同类阻塞，评估环节能做什么？

评估环节本身解决单个条目的处置，同类阻塞反复出现则要在迭代回顾中处理根因：把阻塞原因归类，转化为依赖管理、环境准备或外部协调方面的改进项，指定负责人和完成时间，并在后续迭代的评估表中跟踪改进项是否生效。这样未完成项评估的结果才能反过来减少下一迭代的未完成项。