迭代未完成工作重评的核心做法，是在迭代结束前把每项未完成工作逐条判断，而不是默认结转到下一迭代。先冻结当前迭代范围并盘点未完成项，由负责人补充剩余工作量、阻塞原因和完成条件，团队再按价值、紧迫度、依赖和风险决定去向：回到待办池、拆小后进入下一迭代、转交他人或关闭。重评结果要落到工作项状态、负责人和验收标准上，并在迭代回顾中检查判断是否准确。
要点总览（TL;DR）
- 重评安排在迭代结束前一到两天，先冻结当前迭代范围，再盘点未完成项，避免结束后补记导致判断失真。
- 参与角色包括迭代负责人、工作项负责人、产品负责人和测试或验收方；工作项负责人提供事实，产品负责人判断价值，迭代负责人对流程完整性负责。
- 每项未完成工作按剩余工作量、阻塞原因、完成条件、价值与紧迫度统一口径判断，未完成不等于延期，也不默认结转。
- 去向分四种：回待办池、拆小续做、转交、关闭，按价值、紧迫度、依赖和风险选择，并同步更新状态、负责人和目标迭代。
- 重评结束后用检查清单核对：每项有去向和负责人、剩余工作量与完成条件已更新、关闭项有依据、下一迭代范围与容量匹配，并在回顾中检验判断准确性。
重评前先定规则：谁参加、按什么口径判断
重评要开得有效，前提是团队对“什么时候评、谁来评、按什么标准评”有共同约定。规则可以先写成一页说明，在每个迭代末沿用，减少每次临时争论。
时点：放在迭代结束前，而不是结束后补记
重评应安排在迭代结束前的一到两天，此时团队对未完成项的原因还有清晰记忆，也能据此调整下一迭代的规划。若等到迭代结束后再补记录，工作项状态已经变化，剩余工作量和阻塞原因往往靠回忆填写，判断容易失真。重评开始前先冻结当前迭代范围，不再向本迭代加入新工作，保证盘点对象稳定。
参与角色与各自的位置
一次完整的重评通常需要四类角色在场：迭代负责人组织会议并汇总清单；工作项负责人逐项说明进展、剩余工作量和阻塞事实；产品负责人判断价值与优先级，对关闭或回池给出结论；测试或验收方确认完成条件是否清晰、可验收。角色可以兼任，但判断职责要分清，避免出现“大家都同意继续做”却没人对去向负责的情况。
统一判断口径
为避免逐项讨论时标准漂移，重评前约定四个口径，每项工作都按同一顺序回答：
- 剩余工作量：距离完成还差多少，用团队惯用的单位表达，如人天、故事点或任务数。
- 阻塞原因：当前卡在哪里，是依赖未就绪、需求不清、技术问题还是资源不足。
- 完成条件：满足什么标准才算完成，尽量写成可验收的描述。
- 价值与紧迫度：这项工作的业务价值是否仍然成立，时间上是否紧迫。
需要明确一点：未完成不等于延期，也不等于自动结转。未完成只是事实状态，去向要经过判断才能确定。把“默认顺延到下一迭代”当作处理方式，会让下一迭代的范围不断膨胀，也会掩盖真正需要解决的问题。
核心操作步骤：从盘点未完成项到确定去向
重评可以按五个步骤推进，每一步都有明确的输入、动作、输出和完成标志，便于组织者控制节奏，也便于事后检查是否执行到位。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 冻结范围并盘点 | 当前迭代的全部工作项 | 停止向本迭代加入新工作，筛出未完成项，形成清单 | 未完成工作项清单 | 清单覆盖本迭代所有未完成项，无遗漏 |
| 2. 逐项补充信息 | 未完成工作项清单 | 由工作项负责人填写剩余工作量、阻塞原因、完成条件 | 信息完整的重评底稿 | 每项三项信息均已填写，无空白 |
| 3. 判断去向 | 重评底稿 | 按价值、紧迫度、依赖、风险逐项讨论并给出结论 | 每项工作的去向结论 | 每项都有明确去向，无“再看看” |
| 4. 更新工作项 | 去向结论 | 修改状态、负责人、目标迭代，补充验收标准 | 更新后的工作项记录 | 状态与去向一致，负责人明确 |
| 5. 同步并记录 | 更新后的工作项与判断依据 | 向相关方同步结果，记录判断理由 | 重评记录与同步通知 | 相关方知悉，判断依据可追溯 |
第一步：冻结迭代范围，导出未完成工作项清单
迭代负责人先确认本迭代不再接收新工作，然后按完成状态筛选出未完成项。清单至少包含工作项标题、负责人、原计划完成时间、当前状态。清单是后续讨论的唯一依据，讨论中发现的遗漏项要补入清单再判断，避免口头处理。
第二步：逐项补充剩余工作量、阻塞原因与完成条件
这一步由工作项负责人完成，迭代负责人只做完整性检查。剩余工作量要具体到可比较的程度；阻塞原因写事实而非感受，例如“等待接口联调环境”比“进度受阻”更有用；完成条件写成验收方能核对的描述。信息不全的项不进入下一步判断，先补齐再讨论。
第三步：按价值、紧迫度、依赖、风险判断去向
团队逐项讨论，先确认价值是否仍然成立，再看时间紧迫度和外部依赖是否具备，最后评估继续投入的风险。判断顺序建议固定，避免有人从“已经做了很多”出发主张继续，而忽略价值已经变化。讨论结论当场记录，不留在会后补。
第四步：确定去向并更新工作项状态、负责人、目标迭代
去向确定后立即更新工作项：回待办池的移出当前迭代并保留优先级；拆小续做的建立子项并挂到下一迭代；转交的变更负责人并说明交接内容；关闭的填写关闭原因。状态、负责人、目标迭代三项要与去向结论一致，验收标准同步补充或修订。
第五步：同步相关方并记录判断依据
重评结束后，把结果同步给产品、测试和依赖方，重点说明哪些工作改变了计划、下一迭代将承接什么。判断依据随工作项或重评记录保存，供迭代回顾时核对。在工具层面，这类更新涉及工作项状态、负责人和目标迭代的维护。ONES Project 支持将需求和相关任务规划至迭代并分配负责人，团队可以据此把重评结论直接落到工作项上；迭代过程中的任务状态可通过敏捷看板管理，便于在重评时对照实际进展。
四种去向怎么选：回待办池、拆小续做、转交、关闭
去向判断是重评的关键决策点。四种去向对应不同的工作状态，选择时看条件而不是看习惯，尤其要避免把所有未完成项一律顺延。
| 去向 | 适用条件 | 动作 | 记录要求 |
|---|---|---|---|
| 回待办池 | 价值仍然成立，但当前不紧迫，或依赖尚未就绪 | 移出当前迭代，回到待办池并保留或调整优先级 | 记录回池原因与依赖项 |
| 拆小续做 | 工作量偏大，或完成条件不清，整体无法在下一迭代完成 | 拆分为可独立验收的子项，选择部分进入下一迭代 | 记录拆分结果与子项验收标准 |
| 转交 | 原负责人无法继续，或工作需要其他角色接手 | 变更负责人，明确交接内容与时间 | 记录转交原因与交接清单 |
| 关闭 | 需求失效、价值消失，或已被其他工作覆盖 | 关闭工作项，停止投入 | 记录关闭依据与确认人 |
回待办池：价值还在，时机不对
当工作本身仍有价值，但当前迭代或下一迭代并不紧迫，或者关键依赖短期无法就绪时，回到待办池是合理选择。回池不等于放弃，需要保留优先级信息，并在记录中写明依赖项，方便后续重新排期时快速判断。
拆小续做：整体太大，先做能验收的部分
工作量明显超出下一迭代容量，或完成条件模糊到无法验收时，直接顺延会把问题带到下一迭代。更有效的做法是拆分：把工作切成可独立验收的子项，只把其中真正需要优先完成的部分放入下一迭代，其余回到待办池。拆分后每个子项都要有清晰的完成条件。
转交：换人接手，交接要具体
原负责人休假、调岗或能力不匹配时，转交比勉强续做更稳妥。转交要写清已完成部分、剩余工作、相关文档位置和接手人，避免交接停留在口头。负责人变更后，工作项的剩余工作量和完成条件应由接手人重新确认。
关闭：价值不成立就停止投入
需求被取消、业务方向调整，或这项工作已被其他工作覆盖时，应关闭而不是继续挂着。关闭需要产品负责人确认，并记录判断依据，便于回顾时核对关闭决定是否合理。关闭项不应留在下一迭代范围中占用容量。
角色与交付物：谁判断、谁确认、谁记录
重评的责任要落到具体角色和具体产出上，否则容易出现清单有人列、结论没人定、更新没人做的情况。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 工作项负责人 | 提供剩余工作量、阻塞事实和完成条件 | 信息完整的重评底稿 |
| 迭代负责人 | 组织重评、汇总清单、跟踪去向落实 | 未完成项清单、重评会议结论 |
| 产品负责人 | 判断价值与优先级，确认关闭或回池 | 价值判断结论、关闭确认 |
| 测试或验收方 | 确认完成条件是否可验收 | 验收标准确认意见 |
| 记录人 | 维护工作项字段与重评记录 | 更新后的工作项、重评记录 |
迭代负责人对流程完整性负责，产品负责人对价值判断负责，工作项负责人对信息真实性负责。记录人可以由迭代负责人兼任，但要在会后检查每项工作的状态、负责人和目标迭代是否都已更新。重评结论同步后，下一迭代的规划才具备可靠输入。
示例：一个迭代末的重评记录长什么样
以下为演示场景，用于说明记录如何填写，不代表真实项目数据。假设某团队刚结束一个两周迭代，迭代目标为完成订单模块的三项功能，迭代末盘点出四项未完成工作。
| 工作项 | 负责人 | 剩余工作量 | 阻塞原因 | 完成条件 | 去向 | 判断理由 | 状态变更 |
|---|---|---|---|---|---|---|---|
| 订单导出功能 | 开发A | 2人天 | 等待导出模板确认 | 导出文件字段与模板一致，测试通过 | 拆小续做 | 模板确认后核心导出可先交付，批量导出另立子项 | 拆为两个子项，核心子项进入下一迭代 |
| 订单状态通知 | 开发B | 3人天 | 依赖消息服务升级 | 状态变更后通知在约定时间内送达 | 回待办池 | 价值成立，但消息服务升级未排期 | 移出当前迭代，回待办池，标注依赖 |
| 对账报表优化 | 开发C | 1人天 | 无 | 报表加载时间达到约定目标 | 转交 | 原负责人下周休假，由开发D接手 | 负责人变更为开发D，补充交接说明 |
| 旧版订单查询下线 | 开发A | 0.5人天 | 无 | 旧入口关闭且无调用 | 关闭 | 新版查询已覆盖全部场景，旧入口无调用 | 关闭，记录产品负责人确认 |
这份记录包含几个关键字段：工作项、负责人、剩余工作量、阻塞原因、完成条件、去向、判断理由和状态变更。判断理由是回顾时最有价值的部分，它让团队能检查当时的判断是否准确。示例中四项工作分别走向四种去向，说明重评的结果通常不是单一处理方式。记录完成后，下一迭代只承接拆小后的核心子项和转交后的对账报表优化，范围与团队容量相匹配。
完成检查：重评做没做到位的判断标准
重评结束后，可以用一份清单自查，确认流程执行完整、结论可追溯。以下条目逐项核对，全部满足才算本次重评到位。
- 每项未完成工作都有明确去向和负责人：清单中不存在“待定”“再看看”的项，四种去向之一已确定，负责人已更新。
- 剩余工作量与完成条件已更新：续做和转交的项，剩余工作量由当前负责人确认，完成条件可被验收方核对。
- 关闭项有判断依据记录：每个关闭项都写明关闭原因和确认人，避免后续争议。
- 下一迭代范围与容量匹配：进入下一迭代的工作总量不超过团队可用容量，回池和关闭项不占用下一迭代资源。
- 回顾中检查重评判断的准确性：在迭代回顾中回看上次重评的去向判断，哪些续做项按期完成、哪些回池项被重新提起，据此调整下次判断口径。
回顾环节可以借助迭代数据辅助判断。ONES 支持在迭代完成后通过燃尽图、工时日志等报表复盘进度与偏差，团队可以对照重评时的剩余工作量估算，检查判断是否偏乐观或偏保守；回顾形成的经验也可以通过 ONES Wiki 沉淀为团队知识库，供后续迭代沿用。检查清单不必每次重写，团队可以在几次重评后固化成本组通用的版本，把重点放在判断质量和去向落实上。
常见问题
迭代已经结束、下一迭代规划会都开完了，还能补做重评吗？
可以补，但要接受判断质量下降的事实。迭代结束后补做重评，工作项状态已经变化，剩余工作量和阻塞原因往往靠回忆填写，容易偏乐观。补做时建议先按当时的完成状态还原未完成项清单，再逐项核对当前实际进展，把已经变化的部分标注出来。补做的结论同样要落到工作项状态、负责人和目标迭代上，并在下一次迭代回顾中检查补做判断的准确性，避免形成“先规划、后补评”的固定习惯。
团队规模小、角色由一人兼任时，重评怎么保证判断不失真？
角色可以兼任，但判断职责要分开表达。例如迭代负责人同时承担产品负责人职责时，对关闭和回池的决定要写明判断依据，并在回顾中接受团队质询。工作项负责人提供剩余工作量和阻塞事实的环节不建议省略，哪怕只有一两个人，也要把事实写进记录，而不是在会上口头带过。小团队还可以把重评与下一迭代规划合并成一次会议，但盘点、补充信息、判断去向、更新工作项的顺序保持不变。
拆小续做和回待办池怎么区分，拆完的子项应该进下一迭代还是回池？
区分标准是下一迭代是否真的需要这部分工作。拆小续做适用于整体工作量偏大或完成条件不清、但其中一部分在下一迭代有明确交付需要的情况：拆出的子项要有独立验收标准，只把需要优先完成的部分放入下一迭代。回待办池适用于价值仍在但当前不紧迫、或关键依赖短期无法就绪的情况，此时拆分不是必须动作。拆完的子项如果下一迭代没有承接需要，同样应回到待办池，避免拆分成为变相顺延的手段。
重评记录需要长期保存吗，保留哪些内容才有用？
建议保留，重点保存判断理由而非仅保存结论。回顾时最有价值的信息是当时为什么这样判断：剩余工作量估了多少、阻塞原因是什么、关闭依据由谁确认。这些内容可以随工作项记录保存，也可以汇总成一份重评记录。保留周期可与团队回顾节奏匹配，至少覆盖下一次迭代回顾，便于对照续做项是否按期完成、回池项是否被重新提起。记录格式不必复杂，字段稳定、可追溯即可。
重评结论和下一迭代容量冲突时，先调整哪个？
先确认容量口径，再调整承接范围。重评得出的续做项总量如果超过团队可用容量，说明去向判断需要再筛一轮：按价值和紧迫度排序，把靠后的项改为回待办池，而不是压缩估算或默认加班。容量本身也要用团队惯用单位表达，与剩余工作量的单位保持一致，避免一边用人天、一边用故事点比较。调整后的下一迭代范围应在规划时再次核对，确保回池和关闭项不占用资源。
