迭代结束时，未完成的工作直接顺延到下一个迭代，容易把旧问题带进新计划，也会让团队看不清真实的交付能力。本文围绕迭代运行中的重评动作，说明如何判定未完成、由谁参与、按什么步骤逐项决定去向，并给出角色分工、示例记录和完成检查清单，帮助迭代负责人和产品负责人在评审前把每一项未完成工作处理清楚。
要点总览（TL;DR）
- 判定未完成看三个条件：验收标准未满足、剩余工作量大于零、依赖未就绪；满足任一即进入重评，由执行人提供事实、产品负责人核对结论。
- 重评按五步推进：汇总未完成项、判断价值是否成立、按四类处置归类、重新估算并核对新迭代容量、更新状态并留下记录。
- 四类处置分别是本迭代收尾、拆小后重排、退回待办和终止；产品负责人确认价值与去向，迭代负责人组织重评并维护状态，执行人提供剩余工作量与阻塞原因。
- 重评结束后用检查清单核对：每项有去向和责任人、剩余工作量重新估算、新迭代范围与容量匹配、原因进入回顾议题、工作项状态已同步。
重评前先定口径：什么算未完成、由谁判定
重评的第一步是统一判定口径。同一项工作，执行人认为“基本做完”，产品负责人可能认为“验收未通过”，口径不一致会让后续处置反复。建议在迭代评审前，由迭代负责人组织一次初判，把候选未完成项列出来，评审会上再逐项确认。
判定未完成可以看三个条件，满足任意一个即进入重评范围：验收标准未满足，包括功能缺失、缺陷未修复、文档或测试未完成；剩余工作量大于零，即执行人评估仍需投入时间才能达到可验收状态；依赖未就绪，例如上游接口、第三方资质或外部数据未到位，导致本迭代内无法继续推进。
| 判定条件 | 判定依据 | 初判人 | 确认时点 |
|---|---|---|---|
| 验收标准未满足 | 对照原验收标准逐条核对，存在未通过项 | 任务执行人提出，产品负责人核对 | 迭代评审前初判，评审会确认 |
| 剩余工作量大于零 | 执行人给出剩余工作内容与预估投入 | 任务执行人 | 迭代评审前初判，评审会确认 |
| 依赖未就绪 | 依赖方交付时间晚于本迭代结束时间 | 迭代负责人核对依赖状态 | 迭代评审前初判，评审会确认 |
判定角色上，产品负责人对“是否仍有价值、是否值得继续投入”负责，迭代负责人对“是否真的未完成、剩余量多少”负责，任务执行人提供事实依据。三者对同一项的判断不一致时，以验收标准的逐条核对结果为准，避免用主观完成度代替验收结论。
核心操作步骤：逐项重评并决定去向
重评按固定顺序推进，每一项都走完五步再进入下一项，避免批量处理时遗漏判断依据。整个重评的输入是迭代末的工作项清单和原验收标准，输出是每项的去向结论与更新后的待办列表。
第一步：汇总未完成项，附原验收标准与剩余工作量
迭代负责人从迭代工作项中筛出未达到完成状态的项目，逐项附上原验收标准、当前完成情况、剩余工作内容和执行人给出的剩余工作量估算。完成标志是形成一张清单，每项都能看到“差什么、还差多少”。缺少剩余工作量的项目先退回执行人补充，不进入后续判断。
第二步：判断价值是否仍成立、需求是否变化
产品负责人逐项确认：这项工作的业务价值是否仍然存在，需求是否在迭代期间发生变化，是否存在更优先的事项替代它。判断依据包括需求变更记录、用户反馈和当前版本目标。完成标志是每项都有“价值仍成立”“价值需调整”“价值已消失”之一的结论，并写明理由。
第三步：按四类处置归类
根据前两步的结论，把每项归入以下四类之一。分类规则建议团队提前约定，减少临场争议。
| 处置类别 | 适用情形 | 处理动作 |
|---|---|---|
| 本迭代收尾 | 剩余工作量小，本迭代结束前可完成并验收 | 保留在原迭代，明确收尾责任人与完成时点 |
| 拆小后重排 | 价值仍成立，但整体规模超出下一迭代容量 | 按验收标准拆成可独立验收的子项，重排优先级 |
| 退回待办 | 价值仍成立，但当前优先级下降或依赖未就绪 | 退回产品待办列表，保留原验收标准与重评记录 |
| 终止 | 价值已消失、需求被替代或投入产出不合理 | 关闭工作项，写明终止理由与决策人 |
第四步：重新估算并确认新迭代容量
对进入下一迭代的项目，执行人重新估算剩余工作量，不直接沿用旧估算。迭代负责人把这些估算与下一迭代已规划的工作合并，核对总容量是否可容纳。完成标志是下一迭代范围确定，且总工作量不超过团队可用容量；超出时按优先级削减，而不是压缩估算。
第五步：更新工作项状态与说明，留下重评记录
每项工作按结论更新状态和说明，记录原验收标准、剩余工作量、处置结论、责任人和后续时点。重评记录集中保存，作为迭代回顾的输入。完成标志是所有未完成项状态与结论一致，清单中不存在“待定”项。
在工具层面，重评涉及工作项状态更新、剩余工作量记录和待办列表维护。ONES 支持经典 Scrum 场景，为需求管理、迭代规划、进度跟踪和迭代复盘提供支撑；产品负责人可将产品待办列表中的需求规划至对应迭代，团队在迭代计划会上对齐验收标准后用子任务拆分需求。重评后的去向可以直接体现在工作项状态和迭代范围调整中，ONES Project 提供需求池、迭代规划、任务工时统计与估算任务持续时间的能力，便于把剩余工作量和下一迭代容量放在同一处核对。是否重评、如何处置仍由产品负责人和团队判断，系统记录服务于决策留痕。
角色分工与交付物：谁在哪个环节签字
重评要避免“大家都参与、没人负责”的局面。每个角色承担明确的判断或记录职责，并在对应环节留下确认痕迹。
| 角色 | 主要职责 | 确认环节 | 产出 |
|---|---|---|---|
| 产品负责人 | 判断价值是否成立、确定优先级，确认退回待办或终止 | 第二步价值判断、第三步处置归类 | 价值结论与处置决定 |
| 迭代负责人 | 组织重评、汇总未完成项、核对下一迭代容量、维护工作项状态 | 第一步汇总、第四步容量核对、第五步状态更新 | 未完成项清单、新迭代范围说明 |
| 任务执行人 | 提供剩余工作内容与估算、说明阻塞原因 | 第一步补充剩余工作量、第四步重新估算 | 剩余工作量估算与阻塞说明 |
重评结束后形成三份交付物：重评记录，逐项包含原验收标准、剩余工作量、处置结论、责任人与后续时点；更新后的待办列表，反映退回和拆小后的条目及优先级；新迭代范围说明，写明纳入下一迭代的项目与容量依据。三份交付物由迭代负责人整理，产品负责人确认，作为迭代评审和回顾的输入。
示例：一个未完成需求的重评过程
以下为演示情景，用于说明重评记录如何填写，不代表真实项目数据。
背景：某迭代计划完成“订单导出支持按时间范围筛选”需求，验收标准包括筛选条件可用、导出文件字段完整、异常提示明确三项。迭代结束时，筛选条件与字段完整性已通过验收，异常提示在超时场景下缺失，执行人评估还需约一天工作量。
逐项核对：对照三条验收标准，前两条通过，第三条未满足，判定为未完成；剩余工作量为补齐超时异常提示并补充对应测试用例；依赖方面无外部阻塞。产品负责人确认该需求对应的客户场景仍在本版本范围内，价值成立。
处置结论：剩余工作量可在下一迭代初期完成，但下一迭代已排入两项高优先级需求，整体容量偏紧。团队决定将异常提示部分拆为独立子项，纳入下一迭代，原需求主体标记为部分交付并注明未覆盖场景。理由是拆分后子项可独立验收，不影响主体功能的发布节奏。
记录内容：工作项名称与原验收标准；未通过项为超时异常提示；剩余工作量约一天；处置结论为拆小后重排；责任人为原执行人；后续时点为下一迭代第一周内完成并验收；原因记为“迭代内测试时间不足，异常场景覆盖不完整”，该原因进入回顾议题。
完成检查：重评是否做到位
重评结束后，迭代负责人可用以下清单逐项核对。全部通过再关闭本迭代的重评动作；存在未通过项时，补齐后再进入下一迭代规划。
- 每个未完成项都有明确去向，四类处置之一，且写明责任人，清单中无“待定”项。
- 剩余工作量由执行人重新估算，未直接沿用迭代初的旧估算，估算依据可追溯。
- 下一迭代范围与团队可用容量匹配，纳入项目总量未超出容量；超出部分已按优先级削减或退回待办。
- 重评原因已整理为回顾议题，每类原因对应至少一项改进动作，并指定跟进人。
- 工作项状态与说明已同步更新，重评记录、待办列表和新迭代范围说明三份交付物齐全且内容一致。
这张清单同时适用于单个迭代的收尾检查和跨迭代的抽查。团队可以把检查结果与燃尽图、工时数据对照，判断重评结论是否与迭代实际进度相符，并在回顾会上讨论偏差原因，让下一轮重评的判断更准确。
常见问题
迭代结束时剩余工作量很小，还需要走完整重评吗？
可以简化，但判定环节不能省。剩余工作量小、本迭代结束前能完成并验收的项目，归入“本迭代收尾”，明确收尾责任人与完成时点即可。需要保留的是原验收标准核对结果和剩余工作量估算，这两项是判断“能否收尾”的依据。如果收尾时点跨过迭代结束时间，就按拆小后重排或退回待办处理，避免用“快做完了”替代验收结论。
产品负责人和迭代负责人对某项是否未完成判断不一致，怎么处理？
回到验收标准逐条核对，用核对结果作为判定依据，不用主观完成度投票。执行人先列出每条验收标准的当前状态，产品负责人确认哪些项未通过，迭代负责人核对剩余工作量与依赖状态。若分歧出在验收标准本身表述不清，应在本次重评中补充明确，并把这条标准作为回顾议题，避免下一迭代重复争议。
拆小后重排的项目，下一迭代容量装不下怎么办？
按优先级削减范围，保留估算的真实性。迭代负责人把拆小后的子项与下一迭代已规划工作合并核对总容量，超出时由产品负责人按优先级决定哪些子项进入下一迭代、哪些退回待办。不建议通过压缩估算或让团队加班来“装下”，否则下一轮重评会再次出现同类未完成项，容量数据也失去参考价值。
重评记录需要记到什么程度，回顾会上怎么用？
每项至少记录原验收标准、未通过项、剩余工作量、处置结论、责任人和后续时点，终止项另记终止理由与决策人。回顾会上按原因归类查看这些记录，例如测试时间不足、依赖延迟、需求变更，每类原因对应至少一项改进动作并指定跟进人。记录的作用是让下一轮重评有据可查，而不是增加填写负担，字段可按团队实际精简。
用工具管理迭代时，重评结论如何落到工作项上？
把处置结论体现在工作项状态和迭代范围上：收尾项保留在原迭代并注明完成时点，拆小项建立子项并纳入下一迭代，退回项移回产品待办列表并保留原验收标准，终止项关闭并写明理由。ONES 支持经典 Scrum 场景，产品负责人可将产品待办列表中的需求规划至对应迭代，团队在迭代计划会上对齐验收标准后用子任务拆分需求；ONES Project 提供需求池、迭代规划、任务工时统计与估算任务持续时间的能力，便于把剩余工作量和下一迭代容量放在同一处核对。是否重评、如何处置仍由产品负责人和团队判断。
