迭代回顾记录把回顾会上的事实、讨论和后续动作固定在同一张表里，避免会议结束后只剩零散印象。本文提供一份可直接复制填写的空白表，并逐项说明字段口径、必填与选填的划分，再用一份完整示例展示如何从讨论落到行动项，最后给出按团队情况调整和长期维护的方法。
要点总览（TL;DR）
- 空白迭代回顾记录表按六个区块组织：迭代基本信息、目标与交付完成情况、讨论分类、行动项、未完成工作重新评估、上轮行动项回看，可直接复制到文档或表格工具填写。
- 必填字段决定记录能否支撑后续跟踪：迭代名称与起止日期、迭代目标、参与人、记录人、目标达成情况、已完成交付、三类讨论条目、行动项四要素、未完成事项及重评结论；关键数据与偏差可按团队统计能力取舍。
- 讨论条目按“现象 + 影响”写，行动项写成含动词和对象的具体动作，并配负责人、截止日期和验证方式，让每条结论都能在下轮回顾时核对。
- 未完成工作逐条写明原因并给出取消、拆分、重新排期或转入下轮候选的重评结论，由处理人和时间确认去向，不默认结转到下一迭代。
- 模板按迭代节奏裁剪篇幅，行动项进入待办跟踪并在下轮回顾前回看，记录按迭代名称和日期归档，每季度检查一次长期空置字段。
可复制空白迭代回顾记录表
下表按五个区块组织：基本信息、目标与交付完成情况、讨论分类、行动项、未完成工作重新评估。可以直接复制到文档或表格工具中，按行填写。表格中的提示文字在正式使用时替换为实际内容。
| 区块 | 字段 | 填写内容 |
|---|---|---|
| 一、迭代基本信息 | 迭代名称 | （如：2025 年第 8 迭代） |
| 起止日期 | （开始日期 — 结束日期） | |
| 迭代目标 | （一句话写清本迭代要达成的结果） | |
| 参与人 | （回顾会参与者及角色） | |
| 记录人 / 记录日期 | （姓名 / 日期） | |
| 二、目标与交付完成情况 | 目标达成情况 | （达成 / 部分达成 / 未达成，附事实说明） |
| 已完成交付 | （逐条列出已交付内容及可核对的结果） | |
| 关键数据 | （如交付数量、缺陷数、上线次数等可核对数字） | |
| 与计划的偏差 | （偏差内容及影响） | |
| 三、讨论分类 | 做得好 | （现象 + 影响，逐条） |
| 待改进 | （现象 + 影响，逐条） | |
| 问题与原因 | （问题描述 + 已识别的原因） | |
| 四、行动项 | 编号 | （A1、A2……） |
| 行动内容 | （可执行的具体动作） | |
| 负责人 | （姓名） | |
| 截止时间 | （日期） | |
| 验证方式 | （如何确认完成，如产出物、检查点、下轮回顾核对） | |
| 五、未完成工作重新评估 | 未完成事项 | （逐条列出） |
| 未完成原因 | （阻塞、估算偏差、优先级变化等） | |
| 重评结论 | （取消 / 拆分 / 重新排期 / 转入下轮候选，附理由） | |
| 处理人 / 时间 | （姓名 / 日期） | |
| 六、上轮行动项回看 | 上轮行动项落实情况 | （逐条标注已完成 / 未完成及原因） |
表格中的“上轮行动项回看”放在末尾，便于在讨论开始前先核对上一轮的承诺，再进入本轮讨论。首次使用时可留空，从第二轮起填写。
每个字段记录什么、怎么填
字段说明的目标是让不同记录人写出可比较、可追溯的内容。以下按区块解释填写口径，与上表字段一一对应。
基本信息字段
迭代名称与起止日期用于归档和检索，建议与团队排期系统中的命名保持一致。迭代目标写一句话，描述本迭代要达成的业务或交付结果，避免写成任务清单。参与人记录实际到会者及角色，便于日后追溯谁参与了哪次讨论。记录人和记录日期保证记录可追责。
目标与交付完成情况
这一区用可核对的事实描述，不用主观评价。目标达成情况先给结论，再附一句事实依据，例如“部分达成：核心流程已上线，报表导出延至下轮”。已完成交付逐条列出，每条尽量带可验证的结果，如“订单查询接口上线，压测通过”。关键数据只填团队实际统计的口径，没有统计的项留空，不估算。与计划的偏差写清偏差内容和影响范围。
讨论条目
做得好、待改进、问题与原因三类条目都按“现象 + 影响”写。现象是观察到的事实，影响是对交付、协作或质量的具体作用。例如“每日站会控制在 10 分钟内（现象），阻塞问题当天暴露（影响）”。问题与原因一栏在问题描述后写出已识别的原因；原因尚不明确时写“待查”，并可在行动项中安排排查。
行动项
行动项写成可执行动作，包含动词和对象，例如“为发布流程补充回滚检查清单”，避免“提升质量意识”这类无法验证的表述。每条行动项指定一名负责人，截止时间写到具体日期，验证方式说明如何确认完成，可以是产出物、检查点或在下次回顾时核对。行动项数量控制在团队一轮能承接的范围内。
未完成工作重新评估
未完成事项逐条列出，写明原因，再给出重评结论：取消、拆分、重新排期或转入下轮候选，并附理由。重评结论需要处理人和时间，确保每项未完成工作都有明确去向，不默认结转到下一迭代。
必填与选填的划分
必填字段决定这份记录能否支撑后续跟踪和回看；缺失后记录会退化为会议纪要，无法核对承诺。选填字段按团队情况取舍。
| 字段 | 必填 / 选填 | 缺失后果或适用场景 |
|---|---|---|
| 迭代名称、起止日期 | 必填 | 缺失后无法归档和跨迭代检索 |
| 迭代目标 | 必填 | 缺失后无法判断完成情况，讨论失去参照 |
| 参与人 | 必填 | 缺失后难以追溯讨论来源和行动项归属 |
| 记录人 / 记录日期 | 必填 | 缺失后记录无法追责和确认时效 |
| 目标达成情况 | 必填 | 缺失后回顾缺少事实基础 |
| 已完成交付 | 必填 | 缺失后无法与目标对照 |
| 关键数据 | 选填 | 团队尚无稳定统计口径时可暂缺，有数据时补充 |
| 与计划的偏差 | 选填 | 迭代平稳、无明显偏差时可简写或留空 |
| 做得好 / 待改进 / 问题与原因 | 必填（至少各一条或注明“无”） | 缺失后讨论结论无法沉淀，行动项缺少来源 |
| 行动项内容、负责人、截止时间、验证方式 | 必填 | 任一缺失都会导致行动项无法跟踪或验证 |
| 未完成事项及重评结论 | 必填（无未完成工作时注明“无”） | 缺失后未完成工作去向不明，容易默认结转 |
| 上轮行动项回看 | 首轮选填，之后必填 | 缺失后行动项闭环断裂 |
团队规模较小时，参与人可简写为角色；迭代周期较短（如一周）时，关键数据和偏差可合并为一段简述。迭代形式为持续交付、没有固定周期时，可把“迭代名称”改为“回顾周期”，起止日期改为回顾覆盖的时间段，其余字段口径不变。
一份填好的迭代回顾记录示例
以下为演示情景，用于展示各字段的实际写法，数据为示例，不代表真实项目。
| 区块 | 字段 | 填写内容 |
|---|---|---|
| 一、迭代基本信息 | 迭代名称 | 2025 年第 8 迭代 |
| 起止日期 | 2025-04-07 — 2025-04-18 | |
| 迭代目标 | 完成订单查询改版并上线，支撑客服查询效率提升 | |
| 参与人 | 产品经理、后端 2 人、前端 1 人、测试 1 人 | |
| 记录人 / 记录日期 | 测试负责人 / 2025-04-18 | |
| 二、目标与交付完成情况 | 目标达成情况 | 部分达成：查询主流程已上线，批量导出未完成 |
| 已完成交付 | 订单查询接口改版上线；查询页面前端联调完成；回归测试通过 | |
| 关键数据 | 上线 1 次；回归缺陷 6 个，均已修复 | |
| 与计划的偏差 | 批量导出延后，原因是导出依赖的报表服务接口未就绪 | |
| 三、讨论分类 | 做得好 | 联调提前一天启动（现象），上线当天未出现阻塞（影响） |
| 待改进 | 需求变更在迭代中期才同步到测试（现象），测试用例返工两次（影响） | |
| 问题与原因 | 批量导出未完成；原因是报表服务接口排期晚于本迭代，且未在规划时识别依赖 | |
| 四、行动项 | 编号 | A1 |
| 行动内容 | 在迭代规划会上增加依赖识别环节，列出外部接口依赖及就绪时间 | |
| 负责人 | 产品经理 | |
| 截止时间 | 2025-04-25 | |
| 验证方式 | 下轮规划会记录中出现依赖清单，并在下轮回顾核对 | |
| 五、未完成工作重新评估 | 未完成事项 | 批量导出功能 |
| 未完成原因 | 依赖的报表服务接口未就绪 | |
| 重评结论 | 拆分：导出功能拆为“单页导出”和“批量导出”，单页导出转入下轮候选，批量导出待接口就绪后重新排期 | |
| 处理人 / 时间 | 产品经理 / 2025-04-18 | |
| 六、上轮行动项回看 | 上轮行动项落实情况 | A1（补充回滚检查清单）已完成，清单已加入发布流程文档 |
示例中，讨论区的“待改进”条目直接对应行动项 A1，问题与原因对应未完成工作的重评结论，形成从现象到动作的完整链条。填写时保持这种对应关系，记录才便于下轮核对。
模板的调整与长期维护
模板的价值在于持续使用，而非一次填得完整。以下建议按团队实际情况取舍。
按迭代节奏调整字段与篇幅
两周迭代可保留全部区块；一周迭代可把关键数据与偏差合并为一段，讨论条目控制在每类三条以内。持续交付团队可按月回顾，把“迭代名称”改为回顾周期。字段增减以能否支撑行动项跟踪为准，删减后需在团队内说明口径。
行动项的跟踪与下轮回看
行动项在回顾结束后进入团队的待办跟踪，负责人按截止时间推进。下轮回顾开始前，记录人先核对上轮行动项的落实情况，把结果填入“上轮行动项回看”，未完成的写明原因并决定是否延续。行动项长期未完成时，应在回顾中讨论是否拆分或调整负责人。
记录的归档与检索方式
每次回顾记录按迭代名称和日期命名，集中存放在团队共享的文档空间中，便于按时间检索。记录中的行动项与未完成工作重评，可以在工作项管理工具中建立对应条目，让负责人、截止时间和状态与文档保持一致。ONES 的迭代与工作项管理可以承接这部分内容：回顾记录作为文档留存，行动项和重评后的工作项在迭代中跟踪，下轮回顾时直接核对状态，减少在文档与任务之间来回对照的成本。
避免模板僵化
每季度检查一次模板：统计哪些字段长期为空、哪些讨论条目反复出现同类问题。长期为空的选填字段可以删除，反复出现的问题可考虑固化为检查清单。调整时保留必填字段和行动项四要素，确保记录仍可跟踪。模板版本变更时在团队内同步一次，避免不同记录人使用不同口径。
常见问题
回顾会上讨论很热烈，但记录写出来像会议纪要，怎么改？
问题通常出在讨论条目只写了观点，没有落到可核对的事实和后续动作。填写时给每条讨论加两个要素：现象是观察到的事实，影响是对交付、协作或质量的具体作用；讨论结束后，把需要改变的事项转成行动项，写明负责人、截止时间和验证方式。记录里保留“讨论条目—行动项—未完成工作重评”的对应关系，下轮回顾就能逐条核对，而不是重读一遍会议过程。
团队没有稳定的数据统计，关键数据一栏怎么处理？
关键数据属于选填字段，团队尚无稳定统计口径时可以留空，不用估算数字填充。有部分数据时只填实际统计到的项，例如上线次数、回归缺陷数，并保持口径一致，便于跨迭代比较。等统计方式稳定后再逐步补充，避免为了填满表格而编造或推算数据。
行动项经常写了但没人跟进，模板能起什么作用？
模板的作用是把行动项固定成可跟踪的条目：每条有编号、负责人、截止日期和验证方式，回顾结束后进入团队待办跟踪。下轮回顾开始前，记录人先核对上轮行动项的落实情况，把结果填入“上轮行动项回看”，未完成的写明原因并决定是否延续、拆分或更换负责人。行动项长期未完成时，应在回顾中讨论原因，而不是简单顺延截止时间。
迭代周期很短或采用持续交付，模板需要怎么改？
一周迭代可以把关键数据与偏差合并为一段简述，讨论条目每类控制在三条以内。持续交付、没有固定周期的团队，可把“迭代名称”改为“回顾周期”，起止日期改为回顾覆盖的时间段，其余字段口径不变。调整后需在团队内说明口径，保证不同记录人写出的内容仍可比较和检索。
回顾记录应该存放在哪里，才能方便下轮核对？
建议按迭代名称和日期命名，集中存放在团队共享的文档空间中，便于按时间检索。行动项和重评后的工作项可以在工作项管理工具中建立对应条目，让负责人、截止时间和状态与文档保持一致，下轮回顾时直接核对状态。ONES 的迭代与工作项管理可以承接这部分内容，回顾记录作为文档留存，行动项在迭代中跟踪。
