迭代结束时，未完成的工作需要逐条重新评估，而不是默认顺延到下一轮。未完成工作重评记录就是承载这一判断的表格：把工作项身份、未完成事实、重评结论和处置确认四组信息固定在同一行里，让继续、拆分还是关闭都有据可查。下面给出一张可直接复制的空白表、逐字段填写口径、必填与选填划分，以及一条完整填写示例。
要点总览（TL;DR）
- 未完成工作重评记录按工作项逐条填写，核心信息分四组：工作项身份、未完成事实、重评结论、处置与确认。
- 必填字段包括编号、名称、负责人、原计划完成时间、当前状态、原因分类、是否继续、下一步动作、决策人和确认日期；目标迭代在选“是”或“拆分”时必填。
- 模板由表头、明细表和汇总区三部分组成，可直接复制到文档或表格工具中使用，并附有一条完整填写示例。
- 模板维护按先减选填、再合并原因分类的顺序裁剪，字段变更保留旧记录口径，保证跨迭代可比。
- 重评结论需要回写工作项时，可在工作项管理工具中更新状态、优先级和目标迭代，让记录与系统状态保持一致。
可复制空白重评记录表
这张表分三部分：表头记录本次重评的会议背景，明细区按工作项逐行填写，表下汇总区统计本迭代未完成项的整体处置结果。复制到文档或表格工具后，保留列名即可使用。
表头信息区
| 字段 | 填写内容 |
|---|---|
| 迭代名称 | |
| 重评会议日期 | |
| 主持人 | |
| 参与角色 |
明细表
| 工作项编号 | 工作项名称 | 类型 | 负责人 | 原计划完成时间 | 当前状态 | 未完成原因分类 | 原因说明 | 是否继续 | 重评后优先级 | 目标迭代 | 剩余工作量估算 | 下一步动作 | 决策人 | 确认日期 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
表下汇总区
| 汇总项 | 数量 | 备注 |
|---|---|---|
| 本迭代未完成项总数 | ||
| 继续项数 | ||
| 拆分或关闭项数 | ||
| 需升级决策项数 |
每个字段记录什么、怎么填
同一列在不同人手里填出不同含义，是重评记录失效的常见原因。下面按四组信息说明每个字段的取值口径，团队可以据此统一填法。
身份类字段
工作项编号与名称沿用原工作项，不另起新编号。重评记录的价值在于能和原计划、原讨论对上，一旦换号，后续追溯就要靠人工比对。类型填原工作项的类型，如需求、开发任务、缺陷、测试任务，便于汇总时区分不同性质的工作。
事实类字段
原计划完成时间取原承诺值，即该工作项在迭代计划中约定的完成日期，而不是重评当天或调整后的日期。当前状态取重评时点的真实状态，例如“开发中”“待测试”“阻塞”。原因分类从固定选项中选择，建议取值包括：需求变更、估算偏差、依赖阻塞、资源不足、优先级调整、外部等待。原因说明用一两句话补充具体情形，例如“等待第三方接口联调排期”，避免只写“有困难”。
结论类字段
是否继续用“是”“否”“拆分”三选一，不写“看情况”。目标迭代填具体迭代名，例如“2024 年第 12 迭代”，不写“下个迭代”，因为下个迭代在不同时间点指向不同对象，历史记录会因此失去可比性。重评后优先级按团队既有优先级体系填写，与目标迭代一起构成下一轮排期的输入。
处置类字段
下一步动作写成可执行动词开头的短句，例如“补充接口文档后提交测试”“与供应商确认交付日期”，让接手人知道具体做什么。决策人填角色或姓名，明确谁对这条结论负责。确认日期填该条记录在会议上确认的日期，与表头会议日期可以不同，用于处理会后续确认的情况。
哪些字段必填、哪些可以留空
必填字段的判断标准是：缺了它，这条记录就无法支撑后续决策或无法追溯。选填字段则服务于更细的管理需要，轻量场景下可以暂缺。下表给出对照。
| 字段 | 填写要求 | 说明 |
|---|---|---|
| 工作项编号 | 必填 | 追溯的唯一锚点 |
| 工作项名称 | 必填 | 便于非系统环境阅读 |
| 负责人 | 必填 | 后续动作的承接人 |
| 原计划完成时间 | 必填 | 判断偏差程度的基础 |
| 当前状态 | 必填 | 重评的事实起点 |
| 未完成原因分类 | 必填 | 汇总分析的主要维度 |
| 是否继续 | 必填 | 重评的核心结论 |
| 下一步动作 | 必填 | 结论落地为行动 |
| 决策人 | 必填 | 责任归属 |
| 确认日期 | 必填 | 记录时效 |
| 类型 | 选填 | 需要按工作性质分类统计时填写 |
| 原因说明 | 选填 | 原因分类不足以说明情形时补充 |
| 重评后优先级 | 选填 | 仅做去留判断、不参与下轮排期时可暂缺 |
| 剩余工作量估算 | 选填 | 需要据此安排下轮容量时填写 |
| 目标迭代 | 条件必填 | 选“是”或“拆分”时必填 |
| 拆分说明 | 条件必填 | 选“拆分”时必填，写明拆成哪几项 |
| 关闭原因 | 条件必填 | 选“否”时必填，说明为何不再推进 |
留空处理有一条统一规则：不允许用空白代替“无”。确实不适用的字段填“无”；尚未确定的内容填“待定”，并在下一步动作中注明待定的责任人和确认时点。这样汇总时不会把“没填”误读为“没有”。
一条完整填写示例
以下示例为演示情景，用于说明各字段之间的对应关系，不对应真实团队数据。
| 字段 | 填写内容 |
|---|---|
| 工作项编号 | DEV-2317 |
| 工作项名称 | 订单导出功能开发 |
| 类型 | 开发任务 |
| 负责人 | 张明 |
| 原计划完成时间 | 2024-06-14 |
| 当前状态 | 开发中，核心逻辑完成，导出模板未联调 |
| 未完成原因分类 | 依赖阻塞 |
| 原因说明 | 导出模板依赖设计侧最终稿，设计稿延迟三天交付 |
| 是否继续 | 是 |
| 重评后优先级 | 高 |
| 目标迭代 | 2024 年第 13 迭代 |
| 剩余工作量估算 | 2 人天 |
| 下一步动作 | 确认设计终稿后完成模板联调并提交测试 |
| 决策人 | 产品负责人 李婷 |
| 确认日期 | 2024-06-17 |
这条记录在下一次迭代计划会上的用法是：计划会排期时直接读取“目标迭代”为第 13 迭代、“是否继续”为“是”的行，按“重评后优先级”和“剩余工作量估算”参与容量分配；“下一步动作”作为该工作项在新迭代中的起始任务；“原因说明”则进入本迭代未完成原因汇总，供复盘时判断依赖阻塞是否集中出现。整条记录与原工作项编号对应，任何人回查都能还原当时的判断依据。
模板的调整与长期维护
模板用久了会出现两种偏差：字段越加越多，填写负担让人敷衍；或者长期不更新，记录与实际决策脱节。维护的重点是控制字段增减的节奏，并保住历史记录的可比性。
按团队规模与迭代节奏裁剪
裁剪按固定顺序进行：先减选填字段，再合并原因分类。团队人数少、迭代周期短时，可以先去掉类型和重评后优先级，把原因分类从六项合并为“内部原因”“外部依赖”两类；必填字段保持不动，因为它们是追溯和决策的底线。裁剪后的模板应在表头注明适用版本，避免新旧记录混用同一口径。
新增字段的准入条件
新增一列前先回答：这个字段对应哪一个决策动作或哪一次追溯需求。例如增加“关联需求编号”，是因为复盘时需要判断未完成是否集中在某几个需求上；如果找不到对应的使用场景，就不加。新增字段初期设为选填，经过两三个迭代确认有人实际填写和使用后，再考虑转为必填。
版本管理与定期回看
每次字段变更记录变更日期与变更人，旧记录保留原字段口径，不回溯改写。这样跨迭代对比时，能区分“数据变化”和“口径变化”。定期回看可以借助汇总区：如果某一原因分类连续多个迭代占比偏高，说明问题集中在同一环节，应调整的是计划或协作方式，而不只是模板；如果汇总区长期无人填写，则说明模板过重，需要按上面的顺序裁剪。
当重评结论需要回写到工作项并进入下一轮排期时，可以在工作项管理工具中完成这一动作。以 ONES 为例，重评后的状态、优先级和目标迭代可以直接更新在工作项字段上，迭代视图按目标迭代汇总继续项，计划会据此分配容量；原因分类作为字段保留在工作项上，复盘时按迭代筛选即可看到分布。这样表格记录与系统状态保持一致，减少二次录入。
常见问题
未完成工作重评记录和迭代复盘记录有什么区别？
重评记录聚焦单个工作项的处置判断：这条工作为什么没完成、接下来继续还是关闭、进入哪个迭代、由谁负责。复盘记录面向整个迭代的过程分析，关注计划、协作和流程上的共性问题。两者可以衔接使用：重评记录的原因分类和汇总区数据，正好作为复盘时分析未完成分布的输入。
迭代周期很短、未完成项很少时，还需要逐条填完整模板吗？
可以按 S5 的裁剪顺序先减选填字段，例如去掉类型和重评后优先级，把原因分类合并为“内部原因”“外部依赖”两类。必填字段建议保留，尤其是工作项编号、是否继续、下一步动作和决策人，它们决定记录能否支撑下一轮排期和事后追溯。裁剪后的模板应在表头注明适用版本，避免与旧记录混用口径。
重评结论确定后，怎样保证下一轮计划会真的用上这些记录？
关键是把结论落到可读取的字段上：目标迭代填具体迭代名，是否继续用“是”“否”“拆分”三选一，剩余工作量估算给出数量。计划会排期时直接筛选目标迭代为下一轮、是否继续为“是”的行，按优先级和剩余工作量参与容量分配。如果团队使用工作项管理工具，可以把这些结论更新到工作项字段上，迭代视图按目标迭代汇总，减少从表格二次录入的环节。
原因分类应该设几项，选项之间怎么避免重叠？
建议从六项起步：需求变更、估算偏差、依赖阻塞、资源不足、优先级调整、外部等待。每项对应一种可区分的触发条件，填写时选最接近主因的一项，具体情形写进原因说明。如果同一工作项同时受多个因素影响，以直接导致未完成的那个因素为准。运行几个迭代后回看汇总区，若某两项长期同时出现且难以区分，再考虑合并。
历史记录里的字段口径变了，还能和新记录一起对比吗？
可以对比，前提是旧记录保留原字段口径、不回溯改写，并在变更时记录变更日期与变更人。分析跨迭代数据时，先确认两段记录使用的模板版本，把口径变化单独标注出来，再判断数据本身的走势。这样能区分“未完成原因真的集中了”和“只是分类方式变了”两种情况。
