迭代结束时，未完成工作不能默认自动结转到下一迭代，需要逐项重新评估。这份检查清单面向迭代负责人、开发测试成员和产品负责人，按准备、逐项评估、结论确认、记录归档四个阶段组织，每项给出可判断的通过标准、证据和负责人，并把缺少原因说明、缺少剩余工作量、未经确认即结转列为阻断项。文中也说明如何借助 ONES 的工作项状态与文档协作留存重评记录。
要点总览（TL;DR）
- 重评在迭代评审或回顾前后启动，下一迭代计划会之前必须形成结论，由迭代负责人组织，开发、测试、产品负责人共同参与。
- 准备阶段先核对未完成清单完整性、原迭代目标可查、剩余工作量口径统一、会议排期四项，全部通过再进入逐项评估。
- 每个未完成工作项都要写明原因、重新估算、从结转/拆分/退回待办/关闭中选定结论，并确定优先级、目标迭代与依赖风险。
- 重评记录至少包含工作项标识与原迭代、原因、剩余工作量、结论与目标迭代、优先级、依赖风险、责任人、确认人、重评日期。
- 缺少原因说明、缺少剩余工作量、未经确认即结转、结论与目标迭代不一致属于阻断项，全部未完成项有结论且经确认才算整轮完成。
谁在什么时点使用这份重评清单
这份清单解决的是“什么时候该启动重评、由谁组织、覆盖哪些工作项”。它适用于单个迭代收尾阶段，不替代版本规划或需求池梳理。使用前先确认本次迭代已经进入评审或回顾环节，否则清单中的准备项缺少输入。
触发时点通常有两个：一是迭代评审或回顾前后，团队已经能看到本迭代的实际完成情况；二是下一迭代计划会之前，重评结论要作为排期输入。两个时点可以合并为一次会议，但重评结论必须在下一迭代计划确定前形成。
| 角色 | 在重评中的职责 | 主要参与环节 |
|---|---|---|
| 迭代负责人 | 组织重评、导出未完成清单、主持逐项评估、汇总结论 | 准备、逐项评估、结论确认 |
| 开发成员 | 说明未完成原因、重新估算剩余工作量、识别技术依赖 | 逐项评估 |
| 测试成员 | 说明缺陷类工作项的验证状态与遗留风险 | 逐项评估 |
| 产品负责人 | 判断优先级、确认目标迭代、决定拆分或关闭 | 逐项评估、结论确认 |
适用范围包括本迭代未完成的用户故事、任务和缺陷。已经完成但未验收的工作项，按验收流程处理，不进入本清单；跨迭代的长期事项如果本迭代没有实质推进，也应列入重评，避免长期挂在迭代中无人处理。
重评前的准备检查项
准备阶段的目标是让逐项评估有完整、口径一致的输入。以下检查项全部通过后，才进入逐项评估；任何一项未通过，先补齐再开会，避免会上反复找数据。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 未完成工作项清单是否完整导出 | 清单覆盖本迭代全部未完成用户故事、任务、缺陷，数量与迭代看板一致 | 导出的工作项列表或看板截图 | 迭代负责人 |
| 原迭代目标与验收标准是否可查 | 每个工作项都能关联到原迭代目标或其验收标准 | 迭代目标说明、工作项描述中的验收标准 | 产品负责人 |
| 剩余工作量口径是否统一 | 团队约定统一用剩余工时或完成度百分比之一，并在清单中标注口径 | 口径说明记录 | 迭代负责人 |
| 重评会议时间与参与人是否确定 | 会议已排期，开发、测试、产品负责人均确认参加 | 会议邀请或排期记录 | 迭代负责人 |
准备阶段常见的问题是清单只导出“进行中”状态，遗漏了被搁置或退回待办但原本属于本迭代的工作项。导出时按迭代范围筛选，再逐条核对状态，比按状态筛选更可靠。剩余工作量口径一旦确定，整轮重评保持一致，便于后续比较和汇总。
逐项重评的检查项与通过标准
逐项评估是清单的核心。每个未完成工作项都要独立走完以下检查，五项全部有明确答案才算该项评估通过。评估由迭代负责人主持，开发成员说明原因和估算，产品负责人确认优先级与去向。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 未完成原因是否写明 | 原因具体到可归类的层面，如需求变更、依赖未就绪、估算偏差、资源调整、技术阻塞，而非“没做完” | 工作项备注或重评记录中的原因字段 | 开发成员 |
| 剩余工作量或完成度是否重新估算 | 给出新的剩余工时或完成度，与原估算的差异有简要说明 | 重评记录中的估算字段 | 开发成员 |
| 结论是否明确选择 | 从结转、拆分、退回待办、关闭中选定一项，不出现“待定” | 重评记录中的结论字段 | 产品负责人 |
| 优先级与目标迭代是否确定 | 结论为结转或拆分时，标明优先级和目标迭代；结论为关闭时说明关闭理由 | 重评记录中的优先级与目标迭代字段 | 产品负责人 |
| 依赖、阻塞与风险是否记录 | 存在外部依赖或技术风险的，写明依赖对象、影响范围和应对方式；无依赖的标注“无” | 重评记录中的依赖与风险字段 | 开发成员、测试成员 |
四种结论的适用条件需要区分清楚。结转指工作内容基本不变、只是顺延到下一迭代；拆分指原工作项过大或部分内容已不适用，需要拆成更小的项分别安排；退回待办指当前不具备推进条件，放回待办池等待重新排序；关闭指工作项已无价值或已被其他方式覆盖。结论选择直接影响下一迭代的容量安排，因此不能由单个角色独自决定。
重新估算时，建议同时记录原估算和新估算。两者差异较大的工作项，往往说明原估算方法或需求理解存在问题，这类信息对后续迭代的估算改进有直接价值。
重评记录应包含的字段
重评记录是结论的载体，也是后续追溯的依据。以下字段构成最小字段集，团队可以在此基础上增加字段，但不宜删减必填项。
| 字段 | 必填/选填 | 填写说明 |
|---|---|---|
| 工作项标识与原迭代 | 必填 | 工作项编号、标题，以及所属原迭代名称 |
| 未完成原因 | 必填 | 按约定类别填写，并附一句具体说明 |
| 剩余工作量或完成度 | 必填 | 按统一口径填写，注明单位 |
| 重评结论与目标迭代 | 必填 | 四选一结论；结转或拆分时填写目标迭代 |
| 优先级 | 必填 | 与团队现有优先级体系一致 |
| 依赖与风险 | 必填 | 无依赖时填“无”，不留空 |
| 责任人 | 必填 | 承接后续推进的成员 |
| 确认人 | 必填 | 对结论负责的角色，通常为产品负责人或迭代负责人 |
| 重评日期 | 必填 | 实际完成重评的日期 |
字段填写要避免两种倾向：一是原因字段写成笼统描述，无法支撑后续分析；二是依赖与风险字段留空，导致下一迭代再次因同一依赖受阻。记录字段与逐项评估的检查项一一对应，评估完成后直接落表，不需要二次整理。
结论确认与证据留存
重评结论需要经过确认才生效。确认方式建议采用“责任人提出、确认人复核”的两步流程：责任人在记录中填写结论，确认人核对原因、估算和结论是否一致，确认后在记录中签署。涉及关闭或退回待办的工作项，由产品负责人确认；涉及结转和拆分的，由迭代负责人与产品负责人共同确认。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 结论是否经确认人复核 | 每条记录都有确认人签署，签署时间不晚于下一迭代计划会 | 记录中的确认人字段与签署时间 | 确认人 |
| 记录存放位置是否统一 | 全部重评记录存放在团队约定的同一位置，成员可查 | 记录存放位置说明 | 迭代负责人 |
| 记录是否可追溯 | 通过工作项标识能回溯到原工作项和原迭代 | 工作项与记录的关联关系 | 迭代负责人 |
| 是否与下一迭代计划衔接 | 结转和拆分的工作项已进入下一迭代候选范围，优先级与容量匹配 | 下一迭代计划草案 | 产品负责人 |
记录存放位置要兼顾可查和可写。使用 ONES 时，可以在工作项中更新状态与剩余工作量，把重评结论、原因和依赖写入工作项字段或关联文档，让记录与原工作项保持关联；下一迭代计划时直接按目标迭代筛选，减少手工搬运。确认环节则通过文档评审或工作项流转记录留下签署痕迹，便于事后追溯。
与下一迭代计划的衔接是确认阶段的最后一步。结转项进入候选范围后，要核对下一迭代的总容量是否仍然合理；如果结转项加上新增需求超出容量，应在计划会上调整优先级，而不是把全部结转项默认放入。
阻断项与完成条件
以下情况必须停止结转，先处理再继续，否则重评结论不可信，下一迭代会重复出现同类问题。
| 阻断项 | 判定标准 | 处理方式 |
|---|---|---|
| 缺少原因说明 | 未完成原因字段为空或只有笼统描述 | 退回责任人补充后再确认 |
| 缺少剩余工作量 | 未按统一口径填写剩余工时或完成度 | 重新估算后更新记录 |
| 未经确认即结转 | 记录中没有确认人签署，工作项已进入下一迭代 | 暂停该工作项排期，补确认后再纳入 |
| 结论与目标迭代不一致 | 结论为结转但未填目标迭代，或目标迭代与优先级安排冲突 | 由产品负责人重新确认去向 |
整轮重评视为完成的条件是：本迭代全部未完成工作项均有明确结论，每条结论都有确认人签署，阻断项全部清零，且结转与拆分项已进入下一迭代候选范围。满足这些条件后，迭代负责人可以在回顾会上宣布重评结束，并把记录归档到团队约定的位置。
清单本身也需要定期检视。如果连续多个迭代出现同一类阻断项，例如反复缺少剩余工作量，说明估算习惯或记录模板需要调整，此时应修改清单或团队约定，而不是每次靠会后补救。
常见问题
迭代里长期挂着的跨迭代事项，也要进重评清单吗？
要。判断标准是它在本迭代有没有实质推进，而不是它是否被标记为本迭代的工作项。长期挂在迭代中、本迭代没有实质推进的事项，如果跳过重评，会持续占用迭代视图却无人处理。重评时按普通未完成项走完五项检查，结论通常落在退回待办或拆分，让它回到待办池重新排序，而不是继续挂在原迭代里。
重评会议和迭代回顾会可以合并开吗？
可以合并，但重评结论必须在下一迭代计划确定前形成。合并时建议在回顾会中留出专门时段做逐项评估，避免回顾讨论占满时间后草草给出结论。如果团队未完成项较多，逐项评估耗时较长，可以拆成两次：回顾会先完成准备项核对和原因说明，另排一次短会集中确认结论与目标迭代。两种安排都要保证确认人签署时间不晚于下一迭代计划会。
剩余工作量用剩余工时还是完成度百分比，怎么选？
两种口径都可以，关键是整轮重评统一使用一种，并在清单中标注口径。剩余工时适合团队已有稳定估算习惯、工作项粒度较细的情况；完成度百分比适合工作项粒度较大、难以拆分到小时的情况。同一轮重评混用两种口径，会导致结转项的容量汇总失真，下一迭代排期时无法直接比较。口径一旦确定，本轮所有未完成项按同一口径填写。
结论为结转的工作项，下一迭代容量装不下怎么办？
在下一迭代计划会上调整优先级，而不是把全部结转项默认放入。确认阶段核对结转项与新增需求的总量是否超出下一迭代容量，超出时由产品负责人按优先级取舍，部分结转项顺延到更后面的迭代或退回待办。这一步是重评与计划衔接的关键，跳过它会让重评结论停留在纸面，下一迭代一开始就处于超载状态。
连续几个迭代都出现同一类阻断项，该怎么处理？
先判断是清单问题还是执行习惯问题。如果反复缺少剩余工作量，可能是估算口径不清晰或记录模板字段过多，此时调整模板或团队约定；如果是未经确认即结转，说明确认环节没有卡在流程上，需要把确认人签署设为进入下一迭代的前置条件。清单本身应定期检视，连续出现同类阻断项时修改清单或约定，比每次会后补救更有效。
