迭代回顾会议议程通常包含六个环节：开场与会议约定、数据与事实回顾、收集感受与观察、聚焦问题并归因、形成改进行动、收尾确认与跟进。要让这套议程真正可执行，模板需要同时提供三样东西：带时间盒和引导问题的议程表、按“事实—问题—行动”记录的现场记录表、以及跟踪行动项到关闭的会后跟进表。下面给出可直接复制填写的空白表格、逐环节字段说明、必填与选填划分、一份完整填写示例，以及模板随团队变化调整的方法。
要点总览（TL;DR）
- 迭代回顾议程通常包含六个环节：开场与会议约定、数据与事实回顾、收集感受与观察、聚焦问题并归因、形成改进行动、收尾确认与跟进。
- 模板需要三张表配套使用：带时间盒和引导问题的议程表、按“事实—问题—行动”记录的现场记录表、跟踪行动项到关闭的会后跟进表。
- 必填字段包括环节名称、时间盒、事实记录、行动项、负责人和截止时间；感受词云、投票结果、外部依赖备注等可按团队情况选填。
- 未完成的迭代工作应在收尾环节重新评估优先级和拆分方式，不默认结转到下一迭代。
- 模板调整依据会议是否按时结束、行动项是否关闭、记录是否被后续复盘使用，时间盒可按迭代周期和团队规模压缩或调整。
可直接复制的迭代回顾会议议程空白模板
先拿到表格，再讨论怎么填。以下三张表可以整体复制到文档或表格工具中，会议前填好议程表，会议中填记录表，会议结束前填跟进表。三张表的字段在后续章节的说明和示例中保持一致。
表一：六环节议程空白表
| 环节 | 时间盒 | 引导问题 | 产出物 | 主持人 |
|---|---|---|---|---|
| 1. 开场与会议约定 | （填写，如5分钟） | （填写本次会议目标与规则） | 会议目标、发言规则 | （填写） |
| 2. 数据与事实回顾 | （填写） | （填写与迭代数据相关的问题） | 事实清单 | （填写） |
| 3. 收集感受与观察 | （填写） | （填写） | 成员观察记录 | （填写） |
| 4. 聚焦问题并归因 | （填写） | （填写） | 2–3个重点问题及原因 | （填写） |
| 5. 形成改进行动 | （填写） | （填写） | 行动项清单 | （填写） |
| 6. 收尾确认与跟进 | （填写） | （填写） | 确认后的行动项与检查时点 | （填写） |
表二：现场记录空白表
| 事实（发生了什么） | 问题（暴露了什么） | 行动（准备怎么改） |
|---|---|---|
| （填写） | （填写） | （填写） |
| （填写） | （填写） | （填写） |
| （填写） | （填写） | （填写） |
表三：会后跟进空白表
| 行动项 | 负责人 | 截止时间 | 验证方式 | 状态 |
|---|---|---|---|---|
| （填写） | （填写） | （填写） | （填写） | 未开始/进行中/已完成 |
| （填写） | （填写） | （填写） | （填写） | （填写） |
| （填写） | （填写） | （填写） | （填写） | （填写） |
议程各环节的字段说明与引导问题
表格本身只是骨架，主持人需要知道每个环节填什么、问什么。以下按六个环节逐一说明，引导问题可以直接照读，也可以根据团队习惯改写措辞。
开场与会议约定
这一环节确定会议的目标、时长和发言规则，让参与者知道本次回顾要解决什么问题。主持人应说明会议总时长和各环节时间盒，声明讨论对事不对人，鼓励补充不同视角。引导问题示例：“本次回顾我们最想弄清楚的一件事是什么？”“有没有需要提前说明、会影响今天讨论的情况？”产出物是写在议程表上的会议目标和发言规则。
数据与事实回顾
用迭代中已经发生的事实建立共同认知，避免讨论停留在印象层面。需要覆盖迭代目标达成情况、已完成与未完成事项、缺陷数量与分布、阻塞和外部依赖。引导问题示例：“本迭代承诺的目标完成了多少？”“哪些事项没有完成，原因分别是什么？”“缺陷集中在哪些模块或阶段？”产出物是一份事实清单，直接填入现场记录表的“事实”列。
收集感受与观察
让每位成员补充数据之外的个人观察，包括协作摩擦、外部依赖带来的影响、流程中卡住的地方。主持人可以按轮次请每人说一条，避免少数人主导。引导问题示例：“这个迭代里哪件事让你觉得最费劲？”“有没有哪个环节比预期顺利，原因是什么？”产出物是成员观察记录，同样归入“事实”列或单独备注。
聚焦问题并归因
从前面收集的事实和观察中收敛出2–3个重点问题，讨论其成因，而不是把所有问题都摊开。常用做法是让参与者对候选问题投票，或按主题聚类后保留票数靠前的几项。引导问题示例：“如果只能改一件事，哪一件影响最大？”“这个问题背后的原因是什么，是流程、分工还是外部条件？”产出物是写入记录表“问题”列的重点问题及原因判断。
形成改进行动
针对每个重点问题形成具体行动，行动要能验证、有明确负责人和截止时间。避免“加强沟通”这类无法检验的表述，改写为可观察的动作。引导问题示例：“下周我们能做的一个具体改变是什么？”“怎么判断这个行动有效？”产出物是行动项清单，填入记录表“行动”列，并同步到会后跟进表。
收尾确认与跟进
主持人复述全部行动项，逐条确认负责人和截止时间，约定下次检查的时点。对未完成的迭代工作，在这一环节明确重新评估优先级和拆分方式，而不是默认结转到下一迭代。引导问题示例：“这些行动项大家都认可吗？”“下次回顾前，我们在什么时间点检查进展？”产出物是确认后的跟进表和检查时点。
哪些字段必填、哪些可以按团队情况选填
模板过重会拖慢会议，记录缺失又会让跟进落空。划分标准是：缺少后无法追踪行动或无法还原讨论的字段设为必填，用于丰富视角但不影响闭环的字段设为选填。
| 字段 | 必填/选填 | 说明 |
|---|---|---|
| 环节名称 | 必填 | 保证议程结构完整，便于复用 |
| 时间盒 | 必填 | 控制会议节奏，防止某一环节超时 |
| 事实记录 | 必填 | 讨论的共同依据，会后复盘也依赖它 |
| 行动项 | 必填 | 回顾的核心产出 |
| 负责人 | 必填 | 没有负责人的行动项无法推进 |
| 截止时间 | 必填 | 与验证方式配合形成闭环 |
| 感受词云 | 选填 | 适合需要快速收集情绪的团队 |
| 投票结果 | 选填 | 聚焦问题环节使用投票时记录票数 |
| 外部依赖备注 | 选填 | 依赖方较多的团队建议保留 |
| 会议纪要附件链接 | 选填 | 有完整纪要时附上链接即可 |
按团队成熟度调整的原则：刚开始做回顾的团队保留全部必填字段，选填项尽量精简，把精力放在形成可执行的行动上；运行一段时间后，如果行动项闭环稳定，可以增加投票、词云等选填项丰富讨论视角；如果会议经常超时，优先压缩选填项和收集感受环节的时长，必填字段不删。
一份填好的迭代回顾会议记录示例
以下示例为演示情景，用于展示字段填写后的样子，不代表真实项目数据。背景设定：某团队完成一个两周迭代，迭代目标为上线订单查询功能，团队6人，回顾会议时长60分钟。
议程表填写结果
| 环节 | 时间盒 | 引导问题 | 产出物 | 主持人 |
|---|---|---|---|---|
| 开场与会议约定 | 5分钟 | 本次回顾最想弄清测试环节为什么积压？ | 会议目标、对事不对人的规则 | 迭代负责人 |
| 数据与事实回顾 | 10分钟 | 目标完成了多少？哪些没完成？ | 事实清单 | 迭代负责人 |
| 收集感受与观察 | 10分钟 | 哪件事最费劲？ | 成员观察记录 | 迭代负责人 |
| 聚焦问题并归因 | 15分钟 | 只能改一件事，改哪件？ | 2个重点问题及原因 | 迭代负责人 |
| 形成改进行动 | 15分钟 | 下周能做的具体改变是什么？ | 3条行动项 | 迭代负责人 |
| 收尾确认与跟进 | 5分钟 | 行动项都认可吗？何时检查？ | 跟进表、检查时点 | 迭代负责人 |
现场记录填写结果
| 事实 | 问题 | 行动 |
|---|---|---|
| 迭代目标为订单查询功能上线，主流程已完成；导出功能未完成，因接口联调延迟3天 | 外部接口依赖缺少提前确认机制 | 下个迭代启动前，由后端负责人列出全部外部接口依赖并确认联调时间 |
| 缺陷12个，其中8个集中在查询条件组合场景 | 测试用例对组合场景覆盖不足 | 测试负责人补充组合场景用例清单，在提测前完成评审 |
| 提测后等待测试环境2天 | 测试环境准备没有纳入迭代计划 | 迭代计划中增加环境准备事项，明确责任人和完成时间 |
未完成工作的重新评估写法：导出功能不默认结转到下一迭代，而是在收尾环节记录“导出功能重新评估：拆分为查询结果导出和批量导出两个事项，下个迭代只纳入查询结果导出，批量导出待接口稳定后再排期”。这条记录进入跟进表，由迭代负责人确认。
会后跟进表填写结果
| 行动项 | 负责人 | 截止时间 | 验证方式 | 状态 |
|---|---|---|---|---|
| 列出全部外部接口依赖并确认联调时间 | 后端负责人 | 下个迭代启动前 | 依赖清单在迭代计划会上过一遍 | 未开始 |
| 补充查询条件组合场景用例并评审 | 测试负责人 | 下个迭代提测前 | 用例清单通过评审 | 未开始 |
| 迭代计划中增加环境准备事项 | 迭代负责人 | 下次迭代计划会 | 计划文档中包含该事项 | 未开始 |
| 导出功能拆分并重新排期 | 迭代负责人 | 下次迭代计划会 | 需求拆分记录可查 | 未开始 |
议程模板的调整与长期维护方法
模板需要在多次迭代中逐步校准，调整的依据是会议是否按时结束、行动项是否真正关闭、记录是否被后续复盘使用。
按迭代周期与团队规模调整时间盒
两周迭代、6–8人的团队可参考示例中的60分钟分配。一周迭代可压缩到30–40分钟，重点保留事实回顾和行动形成两个环节；人数超过10人时，收集感受环节改为书面提交或分组讨论，避免逐人发言占满时间。调整时间盒后同步更新议程表，保持表格与实际执行一致。
行动项闭环检查与字段增删规则
每次回顾开始前，先检查上次跟进表的行动项状态，未关闭的说明原因。连续两次回顾都出现同类问题，说明行动设计不够具体，应回到“形成改进行动”环节改写。字段增删遵循一条规则：新增字段必须说明它在哪个环节填写、由谁维护；连续三次回顾都没有人填写的选填字段可以删除。
记录归档与跨迭代对比
每次回顾的记录表与跟进表按迭代归档，命名包含迭代编号和日期。每隔若干迭代做一次横向对比，观察重点问题是否重复出现、行动项关闭率是否稳定。跨迭代对比能帮助团队判断改进是否生效，也为季度复盘提供材料。
在协作工具中承载议程与行动项跟进
当回顾记录分散在多个文档中，行动项容易在迭代切换时丢失。可以把议程表、记录表和跟进表放进同一个协作空间：会前在文档中填好议程，会中直接在记录表补充事实与问题，会后把行动项转为可分配、可设截止时间的工作项，由负责人更新状态，下次回顾前按状态筛选检查。ONES 的文档与工作项可以在同一项目中关联，适合把回顾记录和行动项放在一起跟踪；具体配置方式按团队现有项目结构安排即可。
常见问题
迭代回顾会议开多长时间比较合适？
常见做法是两周迭代配60分钟左右，六个环节按5、10、10、15、15、5分钟分配。一周迭代可以压缩到30–40分钟，重点保留事实回顾和形成行动两个环节。人数超过10人时，收集感受环节改为书面提交或分组讨论，避免逐人发言占满时间。时间盒确定后写进议程表，会议中按表控场。
回顾会上讨论的问题很多，怎么收敛到可执行的行动？
在“聚焦问题并归因”环节做一次收敛：让参与者对候选问题投票，或按主题聚类后保留票数靠前的2–3项。只对这几项讨论成因并形成行动，其余问题记入记录表备查。行动要写成可观察、可验证的动作，例如把“加强沟通”改写为“提测前由测试负责人组织一次用例评审”，并指定负责人和截止时间。
上次回顾的行动项没有完成，这次会议怎么处理？
在本次回顾开始前先检查上次跟进表，逐条确认状态。未关闭的行动项说明原因：是行动设计不够具体、负责人时间不足，还是外部条件变化。原因属于行动设计问题的，在“形成改进行动”环节重新改写；属于外部条件变化的，重新评估是否继续保留。连续两次回顾出现同类问题，说明改进没有落地，应优先处理这一项。
迭代中没有完成的工作，回顾会上应该怎么记录？
在收尾确认环节明确记录重新评估的结果，包括未完成事项的原因、是否拆分、下个迭代纳入哪一部分。例如把“导出功能”拆分为查询结果导出和批量导出，下个迭代只纳入前者，后者待接口稳定后再排期。这条记录进入会后跟进表，由迭代负责人确认，避免未完成工作被默认带入下一迭代而缺少重新评估。
回顾记录放在文档里还是放进项目管理工具？
两种方式都能用，区别在于行动项是否需要持续跟踪。记录只用于存档时，文档足够；行动项需要分配负责人、设置截止时间并在下次回顾前检查状态时，放进项目管理工具更便于闭环。也可以两者结合：议程和记录放在协作文档中，行动项转为工作项跟踪。ONES 的文档与工作项可以在同一项目中关联，适合把回顾记录和行动项放在一起管理，具体配置按团队现有项目结构安排。
