迭代结束时，未完成工作如果直接自动结转到下一迭代，迭代范围会一轮轮膨胀，估算也会逐渐失真。更稳妥的做法是：先冻结原状态，在回顾会前逐项重评剩余工作量、目标相关性和处置方式，只有通过重评的工作才进入下一迭代候选。本文给出可直接执行的触发规则、五步操作、四类处置判断、角色分工和完成检查清单。
要点总览（TL;DR）
- 迭代结束时先冻结未完成项状态并打标，由迭代负责人或 Scrum Master 在回顾会前发起重评，范围限定为本迭代承诺未完成的工作项及残留子项。
- 逐项重评按五步执行：核对完成定义排除假未完成、执行人重估剩余工作量并说明差异、判断目标相关性、给出处置结论、更新剩余工作量与责任人等字段。
- 处置结论分拆小、回池、延后、关闭四类，判断依据落到目标、依赖、估算三个可核对的事实上；回池项需重新排序，延后项需设复查时点。
- 重评结论表记录工作项、原估算、新估算、处置结论、理由与责任人；存在无结论或无责任人的未完成项时，不开启下一迭代规划。
重评前先定规则：哪些工作必须重评、由谁发起
重评要解决的是“哪些未完成项值得继续做、以什么方式继续”，因此第一步是把范围和责任定清楚，避免迭代一结束就批量拖入下一迭代。规则建议在迭代开始时就写入团队约定，迭代结束时直接执行。
冻结动作：先停住，再判断
迭代结束当天，把本迭代所有未完成工作项保持在原状态，并统一打上“待重评”标记。冻结期间不修改状态、不调整迭代归属、不追加新工作。冻结的目的是让重评基于迭代结束时的真实状态进行，防止个别成员提前把工作项挪到下一迭代，导致重评时看不到原始范围。
重评范围：承诺未完成项及其残留子项
重评范围限定为本迭代承诺但未完成的工作项，包括需求拆分后残留的子任务。判断标准是“是否在本迭代计划中承诺完成”，而非“是否有人碰过”。迭代中途临时插入、未纳入承诺范围的工作，单独记录来源，不混入本次重评清单，避免范围口径混乱。
发起人与时点
由迭代负责人或 Scrum Master 在迭代回顾会前发起，提前一到两个工作日把待重评清单发给相关人员。产品负责人参与目标相关性判断，执行人准备剩余工作量重估。发起时明确三件事：清单范围、每项的当前责任人、重评结论的提交时点。
| 规则要素 | 约定内容 | 完成标志 |
|---|---|---|
| 冻结时点 | 迭代结束当天，未完成项保持原状态并打标 | 清单中每项均有“待重评”标记 |
| 重评范围 | 本迭代承诺未完成的工作项及残留子项 | 清单与迭代计划可逐项对应 |
| 发起角色 | 迭代负责人或 Scrum Master | 回顾会前完成清单分发 |
| 参与角色 | 执行人、产品负责人 | 重估数据与目标判断均已提交 |
逐项重评的操作步骤：从剩余工作量到处置结论
重评按工作项逐条进行，每步都有明确的输入、动作和输出。五步走完，一项工作才算完成重评。
第一步：核对完成定义，排除假未完成
输入是工作项当前状态和团队约定的完成定义。动作是逐项核对验收标准是否达成、代码是否合入、测试是否通过。输出是“确实未完成”或“实际已完成但状态未更新”的判断。对于后者，直接更新状态并移出重评清单，不进入后续步骤。这一步能过滤掉相当一部分因流程滞后造成的假未完成，避免把已完成的工作重新估算一遍。
第二步：重估剩余工作量
输入是原估算和当前实际进展。动作由执行人给出新的剩余工作量估算，并写明与原估算差异的原因，例如需求理解偏差、依赖阻塞、技术方案调整。输出是新的剩余工作量数值和差异说明。重估只针对“还剩多少”，不重新评估已完成部分，避免把历史工作量重复计入。
第三步：判断目标相关性
输入是工作项对应的产品目标和当前优先级。动作由产品负责人确认该工作是否仍服务当前产品目标，是否已被其他方案替代，或目标本身已经调整。输出是“目标有效”“目标失效”“被替代”三类判断之一。这一步决定后续处置方向，判断依据要写清楚，不能只写“暂缓”或“再看”。
第四步：给出处置结论
根据前三步的结果，从拆小、回池、延后、关闭四类结论中选择一类，并写明理由。四类的具体判断标准在下一节展开。输出是每项工作唯一的一条处置结论，不允许出现“待定”或空白。
第五步：更新工作项字段
输入是重评结论。动作是更新工作项的剩余工作量、处置结论、责任人、下次评估时点四个字段。输出是字段完整、可供下一迭代规划直接使用的工作项记录。回池项同步退回需求池，延后项设置复查日期，关闭项记录关闭理由并归档。
在工具层面，ONES Project 支持需求、任务、缺陷和迭代管理，团队可以用子任务拆分需求并跟踪状态，用任务工时统计辅助估算任务持续时间。重评时，执行人可以在工作项上更新剩余工时，迭代负责人依据更新后的数据整理下一迭代候选范围，回顾会上再结合燃尽图、工时日志等报表复盘进度偏差。是否支持用自定义字段记录处置结论和复查时点，建议在选型或配置阶段实际核验。
四类处置结论怎么选：拆小、回池、延后与关闭
四类结论的区别在于工作项“还值不值得做”和“现在能不能做”。判断时把依据落到目标、依赖、估算三个可核对的事实上，结论自然清晰。
| 处置结论 | 适用情形 | 判断依据 | 后续动作 |
|---|---|---|---|
| 拆小 | 目标仍有效，剩余工作量大，单迭代难以完成 | 估算明显超过单迭代容量，且可拆出独立可交付部分 | 拆成可在单迭代完成的小项，重新估算并排入候选 |
| 回池 | 目标仍有效，但优先级下降 | 产品负责人确认当前优先级低于其他需求 | 退回需求池，重新参与排序 |
| 延后 | 目标有效，但外部依赖未满足 | 依赖方、接口、审批等条件有明确未完成事实 | 设定复查时点和复查责任人 |
| 关闭 | 目标失效、被替代或价值不再成立 | 产品目标已调整，或已有其他方案覆盖 | 记录关闭理由，归档不再跟踪 |
拆小的关键是拆出的子项能独立验收，而不是把原工作按工时平均切分。回池不等于降低优先级后继续占用迭代容量，退回后要重新参与排序，可能排到更后面的迭代。延后必须带复查时点，否则会变成事实上的遗忘。关闭需要产品负责人确认，并写清是目标失效还是被替代，便于后续追溯决策依据。
四类结论中，回池和关闭容易混淆：回池是“还要做，只是现在不排”，关闭是“不再做”。判断时问一句“如果资源充足，这项工作还要不要做”，答案是要则回池，不要则关闭。
角色与交付物：谁判断、谁确认、留下什么记录
重评涉及三类角色，各自职责边界清晰，避免出现“大家都觉得该重评，但没人给结论”的情况。
| 角色 | 职责 | 产出 |
|---|---|---|
| 执行人 | 核对完成定义，重估剩余工作量，说明差异原因 | 新估算值与差异说明 |
| 迭代负责人 / Scrum Master | 发起重评，组织逐项过审，汇总结论，维护工作项状态 | 重评结论表、更新后的工作项 |
| 产品负责人 | 确认目标相关性，决定回池项的优先级 | 目标有效性判断、回池排序意见 |
记录物是一份重评结论表，建议包含以下字段：工作项编号与名称、原估算、新估算、差异原因、目标相关性判断、处置结论、理由、责任人、下次评估时点。表格按工作项逐行填写，一行对应一项，结论列不允许留空。这份表既是下一迭代规划的依据，也是回顾会上讨论范围偏差的输入。
在 ONES 中，产品负责人可以按需求优先级把待办列表中的需求规划到对应迭代，迭代计划会上与团队共同评审；重评结论表可以作为迭代规划的输入材料，与工作项状态、子任务拆分结果一起使用。重评结论的沉淀方式，可以结合团队现有的文档或工作项字段来设计。
一个完整示例：三条未完成工作项的重评过程
以下为演示情景，用于说明流程如何落地。某迭代结束时有三条未完成工作项，分别对应不同情形。
示例背景
迭代目标为完成订单模块的三项改造。迭代结束时：工作项 A“订单导出功能”开发完成但测试未通过；工作项 B“订单批量审核”因依赖的权限服务接口延期而未开始；工作项 C“订单页面旧版样式调整”在迭代中途被新的设计规范替代。
逐项重评
工作项 A：核对完成定义，测试未通过，确属未完成。执行人重估剩余工作量为 2 人天，原估算 5 人天，差异原因是测试阶段发现边界条件遗漏。目标仍有效，剩余工作量可在单迭代完成，处置结论为“拆小”——拆出边界条件修复和回归测试两个子项。更新剩余工作量、责任人，下次评估时点为下一迭代中期检查。
工作项 B：核对完成定义，工作未开始，确属未完成。执行人重估剩余工作量维持 3 人天。目标有效，但依赖的权限服务接口预计两周后才能提供，处置结论为“延后”，复查时点设为两周后，复查责任人为迭代负责人。
工作项 C：核对完成定义，确属未完成。产品负责人确认新设计规范已覆盖原样式调整范围，原目标失效，处置结论为“关闭”，关闭理由记录为“被新设计规范替代”，工作项归档。
重评结论表填写结果
| 工作项 | 原估算 | 新估算 | 处置结论 | 理由 | 责任人 |
|---|---|---|---|---|---|
| A 订单导出功能 | 5 人天 | 2 人天 | 拆小 | 测试发现边界条件遗漏，拆为修复与回归两个子项 | 执行人甲 |
| B 订单批量审核 | 3 人天 | 3 人天 | 延后 | 权限服务接口延期，两周后复查 | 迭代负责人 |
| C 旧版样式调整 | 2 人天 | — | 关闭 | 被新设计规范替代，目标失效 | 产品负责人 |
下一迭代候选范围的变化
重评前，三条未完成项合计 10 人天，若直接结转，下一迭代将凭空多出 10 人天工作量。重评后，只有工作项 A 拆出的两个子项进入下一迭代候选，合计 2 人天；工作项 B 延后待复查，不占用下一迭代容量；工作项 C 关闭，不再跟踪。下一迭代候选范围因此缩小到可承诺的规模，估算也有执行人给出的新数据支撑。
完成检查：重评做对了没有
重评结束后，用以下清单逐项核对，全部通过才进入下一迭代规划。
- 每个未完成项都有明确的处置结论和理由，无“待定”或空白。
- 剩余工作量由执行人重新估算，未直接沿用旧值；有差异的项写明了差异原因。
- 回池项已退回需求池并重新参与排序，不是简单降低优先级后继续占用迭代。
- 延后项已设定复查时点和复查责任人。
- 关闭项已记录关闭理由，并经产品负责人确认。
- 下一迭代候选范围只包含通过重评的工作项，范围总量与团队容量匹配。
- 重评结论表字段完整，工作项、原估算、新估算、处置结论、理由、责任人逐项可查。
阻断条件是：只要存在无处置结论或无责任人的未完成项，就不得开启下一迭代规划。先补齐结论再规划，避免把未决问题带进新迭代，造成范围再次失控。
常见问题
迭代中途临时插入、未纳入承诺范围的工作，要不要一起重评？
建议单独记录来源，不混入本次重评清单。重评范围以“是否在本迭代计划中承诺完成”为准，临时插入的工作没有承诺基线，混进来会让范围口径变乱，也无法与迭代计划逐项对应。可以另设一份插入项记录，在回顾会上讨论插入频率和对原计划的影响，再决定后续如何纳入规划。
执行人和产品负责人对目标相关性判断不一致时怎么处理？
目标相关性由产品负责人确认，执行人提供的是剩余工作量和差异原因。如果执行人认为工作已无价值，可以把判断依据写进重评结论表，由产品负责人复核。双方仍不一致时，先按“延后”处理并设定复查时点，避免在迭代切换节点上反复拉扯；复查时带上新的目标信息再定回池还是关闭。
延后项设了复查时点，复查时又没条件做，怎么办？
复查时点到期后重新走一次简化重评：确认依赖是否已满足、目标是否仍有效，再给出新的处置结论。可以继续延后，但要更新复查时点和责任人，并在结论表里记录本次复查的结果。连续多次延后且依赖仍无明确进展的项，建议提交产品负责人判断是否转为回池或关闭，避免长期挂在延后状态里无人跟进。
团队规模小、角色兼任时，重评的角色分工怎么落地？
角色可以兼任，职责不能省。小团队里迭代负责人可能同时是执行人，此时仍要分别完成两件事：作为执行人给出剩余工作量重估和差异原因，作为迭代负责人汇总结论并维护工作项状态。产品负责人的目标相关性确认如果也由同一人承担，建议在结论表里写明判断依据，便于回顾会上其他人核对，减少一人判断带来的盲区。
重评结论表一定要单独建文档吗？
不一定。结论表的核心是字段完整、逐项可查：工作项、原估算、新估算、处置结论、理由、责任人、下次评估时点。可以放在独立文档里，也可以借助工作项字段和视图来承载。选择哪种方式，取决于团队是否需要在迭代规划会上快速筛选“已通过重评”的候选工作项，以及回顾会是否需要按结论类型统计范围偏差。
