迭代回顾要产生实际改进，可以按五步推进：会前准备迭代目标、完成情况、范围变更和阻碍记录；会中先对齐事实，再讨论原因；从多个问题中收敛出少数关键问题；把结论写成有负责人、完成时间和验证方式的改进项；在下一次迭代中跟进检查。本文给出可直接套用的输入清单、会议议程、改进项模板和完成检查表，适合Scrum Master、迭代负责人或团队骨干组织一次两小时左右的回顾会。
要点总览（TL;DR）
- 会前至少一个工作日汇总迭代目标、完成情况、范围变更、阻碍记录和上轮改进项进展，由迭代负责人发出，参与者提前阅读。
- 会议按事实对齐、个人观察、原因讨论、问题收敛、改进项设计、收尾确认推进，用时间盒控制节奏，先对齐事实再讨论原因。
- 每次回顾只保留2至3项改进，每项写明动作、负责人、完成时间和验证方式，负责人为具体个人。
- 迭代中未完成的工作逐项重新评估，由产品负责人决定继续、拆分、调整优先级或取消，不默认结转到下个迭代。
- 下次回顾会固定核对上轮改进项的完成情况和验证结论，出现关键数据缺失或改进项无负责人时应阻断结论输出。
迭代回顾前要准备哪些输入
回顾会讨论的是刚结束的这个迭代，会前输入决定了讨论能否落在事实上。准备工作的完成标志是：会前至少一个工作日，各项数据已汇总到同一份材料中，参与者在会前能读到。缺少数据时，会议容易变成印象之争，主持人应推迟讨论原因类议题，先补齐事实。
需要准备的材料分为四类。第一类是迭代目标与承诺范围：本迭代开始时承诺了哪些工作项、对应的验收标准是什么。第二类是完成情况：哪些工作项已完成、哪些部分完成、哪些未开始，完成的工作是否经过验收。第三类是范围调整记录：迭代中新增、删除或变更的工作项，以及变更的提出人和时间。第四类是阻碍记录：迭代中出现的阻塞、等待、返工和环境问题，包括发生时间和持续时长。
| 数据项 | 具体内容 | 提供人 | 截止时间 |
|---|---|---|---|
| 迭代目标与承诺范围 | 迭代目标描述、承诺工作项清单及验收标准 | 产品负责人 | 回顾会前2个工作日 |
| 完成情况 | 各工作项状态、验收结果、部分完成项的实际进度 | 迭代负责人或项目管理员 | 回顾会前1个工作日 |
| 范围调整记录 | 新增、删除、变更的工作项及提出人、时间、原因 | 产品负责人与迭代负责人共同确认 | 回顾会前1个工作日 |
| 阻碍记录 | 阻塞事项、等待时长、返工情况、环境或依赖问题 | 团队成员各自提交，迭代负责人汇总 | 回顾会前1个工作日 |
| 上次改进项跟进结果 | 上轮改进项的动作完成情况与验证结论 | 各改进项负责人 | 回顾会前1个工作日 |
角色上做两项分工：数据准备人负责汇总上述材料并提前发出，通常由迭代负责人承担；会议主持人负责设计议程、控制节奏和处理跑偏，可以由迭代负责人兼任，也可以在团队中轮换，但应与数据准备人明确区分职责，避免主持人一边翻数据一边引导讨论。参与角色一般包括产品负责人、开发团队成员、测试人员和必要的跨团队代表；与本次迭代无关的人员可以不参加，以控制讨论范围。
会议时长建议控制在90至120分钟。超过两小时的回顾会，后半段注意力明显下降，讨论质量随之降低。若迭代周期较短、工作项较少，60至90分钟即可。会前应把材料发给参与者，并要求每人带着至少一条观察参会，减少现场回忆的时间。
回顾会怎么开：从事实对齐到问题聚焦
会议现场的核心顺序是先对齐事实、再讨论原因、最后收敛问题。跳过事实直接谈感受，讨论会围绕个别事件反复；只罗列事实不讨论原因，又无法形成改进。主持人按时间盒推进，每个环节到时即切换，未讨论完的内容记入待办，不在现场无限延长。
| 环节 | 时长 | 主持人动作 | 产出 |
|---|---|---|---|
| 开场与规则说明 | 5分钟 | 说明本次回顾的范围、议程和时间盒，重申对事不对人 | 参与者对议程达成一致 |
| 事实对齐 | 20分钟 | 逐项呈现目标、完成情况、范围变更和阻碍记录，请参与者补充遗漏 | 一份团队认可的事实清单 |
| 个人观察补充 | 15分钟 | 每人用一句话说出做得好的和需要改善的各一点，不展开辩论 | 补充事实与初步关注点 |
| 原因讨论 | 30分钟 | 围绕候选问题追问原因，区分流程、协作、技术、外部依赖等类别 | 问题与原因的对应关系 |
| 问题收敛与投票 | 15分钟 | 合并同类问题，组织参与者投票选出优先处理的少数问题 | 2至3个关键问题 |
| 改进项设计 | 25分钟 | 针对每个关键问题提出动作，现场确认负责人和时间 | 可执行的改进项清单 |
| 收尾确认 | 10分钟 | 复述改进项，确认下次检查时点，收集对会议本身的意见 | 改进项登记表与跟进约定 |
从多个问题收敛到少数关键问题，常用做法是先合并同类项，再用每人有限票数的点投票排序，最后检查入选问题是否满足两个条件：团队自身有影响力，且在本迭代内可以采取动作。外部依赖导致的问题如果团队无法直接改变，应转为上报事项，而不是占用改进项名额。
主持人的引导动作包括：在事实未澄清时暂停原因讨论；在出现针对个人的评价时把话题拉回具体事件和流程；在讨论发散时提醒剩余时间和当前环节目标；在无人发言时按顺序点名收集观察。常见跑偏有三类：一是把回顾开成任务进度汇报，处理方式是提醒进度已在事实对齐环节呈现，当前讨论的是过程问题；二是围绕单个技术细节争论，处理方式是记入待办，会后单独讨论；三是提出的改进项过于宏大，处理方式是现场追问第一个可执行动作是什么。
改进项怎么写才可执行
改进项与普通任务的区别在于它针对的是过程问题，并且必须能被验证。每条改进项至少包含四个字段：动作、负责人、完成时间、验证方式。动作要写成具体行为，例如“在迭代计划会前由产品负责人完成需求澄清并输出验收标准”，避免“加强沟通”“提升质量”这类无法判断是否完成的表述。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 对应问题 | 引用回顾中确认的关键问题 | 需求在开发中途频繁变更 |
| 动作 | 具体行为，说明谁在什么时点做什么 | 迭代计划会前完成需求澄清，输出验收标准并经过开发与测试确认 |
| 负责人 | 一名具体责任人，不用团队名义 | 产品负责人 |
| 完成时间 | 明确日期或迭代节点 | 下个迭代计划会前 |
| 验证方式 | 可观察的检查口径 | 下个迭代中变更需求数量及变更时的开发进度，在下次回顾会上核对 |
数量上建议每次回顾只保留2至3项改进。改进项过多会分散执行注意力，也增加下次回顾的核对负担。取舍时优先选择影响面大、团队可控、下个迭代内能见到效果的问题；影响大但短期内无法解决的，可以拆出一个起步动作，其余部分转为长期事项另行跟踪。
迭代中未完成的工作需要在回顾时逐项重新评估，而不是默认结转到下个迭代。评估时回答三个问题：这项工作是否仍然需要做；如果需要，剩余工作量和原估算差异在哪里；下个迭代是否有容量承接。重新评估后，由产品负责人决定放回待办列表、拆分、调整优先级或取消。把未完成项直接顺延，会掩盖估算偏差和容量问题，也会让下个迭代的承诺失真。
改进项进入下一迭代跟进的方式是：在迭代计划时把改进项作为独立工作项纳入，指定负责人和检查时点；在下一次回顾会的固定环节核对上轮改进项的动作完成情况和验证结论，未完成的说明原因并决定继续、调整或放弃。这样改进项与迭代工作在同一处被跟踪，避免散落在会议纪要里无人回看。
当回顾所需的工作项完成情况、范围变更记录和改进项集中在一个研发管理工具中时，会前汇总和会后跟进可以省去多处收集。以ONES为例，工作项的完成状态、变更历史和迭代内的阻碍记录可以在项目中直接查看，改进项可以作为工作项登记负责人、完成时间并在下一次迭代中检查状态，使回顾的输入和跟进有共同的记录位置。团队使用其他方式记录时，保持同样的字段和检查节奏即可。
角色分工与各环节交付物
回顾会的责任链可以概括为：迭代负责人保证数据和议程到位，主持人保证现场讨论按节奏推进，产品负责人对范围与优先级问题作出决定，改进项负责人对动作落地负责，团队共同参与事实确认和问题收敛。
| 角色 | 会前 | 会中 | 会后 | 交付物 |
|---|---|---|---|---|
| 迭代负责人 | 汇总完成情况、范围变更和阻碍记录，提前发出材料 | 补充事实，回应数据相关问题 | 整理改进项登记表，跟踪状态 | 会前输入清单、改进项登记表 |
| 主持人 | 设计议程和时间盒，确认参与者 | 控制节奏，处理跑偏，组织投票和收敛 | 确认改进项字段完整，发出会议记录 | 议程表、会议记录 |
| 产品负责人 | 提供迭代目标、承诺范围和变更原因 | 对范围调整和未完成工作的处理作出决定 | 确认下个迭代是否承接相关改进项 | 范围与优先级决定 |
| 团队成员 | 提交各自遇到的阻碍和观察 | 确认事实，参与原因讨论和投票 | 承担分配的改进项动作 | 阻碍记录、改进项执行结果 |
| 改进项负责人 | 核对上轮改进项进展 | 提出或认领改进动作 | 按完成时间执行并准备验证材料 | 改进项完成情况与验证结论 |
改进项从提出到验证的责任链是：提出人在会上说明动作和预期效果，团队确认负责人，负责人在完成时间内执行，下次回顾会由负责人报告完成情况和验证结果，主持人核对后决定关闭或继续。跨团队依赖问题如果超出本团队影响范围，由迭代负责人或产品负责人整理成上报事项，写明依赖对象、影响和期望解决时间，提交给相应的协调机制，并在下次回顾会上报告进展。
一个完整示例：两小时回顾会怎么走
以下为演示情景，用于说明流程如何落地，不代表真实团队数据。某团队刚结束一个两周迭代，承诺完成12个工作项，实际完成9项，迭代中新增3项紧急需求，另有2项因外部接口未就绪而阻塞。会前两个工作日，产品负责人提供了迭代目标和范围变更记录；会前一天，迭代负责人汇总了完成情况和阻碍记录，并发出材料。
会议按议程推进。前5分钟主持人说明规则。事实对齐环节用20分钟逐项核对：12项承诺中9项完成并通过验收，1项部分完成，2项未开始；新增3项需求均由同一业务方在迭代中期提出；2项阻塞累计等待4天。个人观察环节用15分钟，多人提到“需求变更来得突然”和“联调环境不稳定”。
原因讨论用30分钟，团队把候选问题归为三类：需求变更缺少提前沟通、联调环境准备滞后、部分工作项估算偏乐观。投票后选出前两项作为本次重点，估算问题记入待办，留待下个迭代结合数据再讨论。改进项设计用25分钟，形成两条改进项：一是产品负责人与业务方约定迭代中变更需求的提出窗口，并在计划会前完成验收标准确认，完成时间为下个迭代计划会前，验证方式为统计下个迭代变更需求的数量和提出时点；二是迭代负责人协调在迭代开始前完成联调环境检查，输出检查记录，完成时间为下个迭代第一天，验证方式为下个迭代是否出现环境导致的阻塞。
收尾10分钟，主持人复述两条改进项及负责人，约定在下次回顾会的前15分钟核对。会后迭代负责人把改进项登记为工作项，纳入下个迭代跟踪。整个过程约115分钟，未超出时间盒。
完成检查：回顾是否真正产生改进
回顾会结束时，主持人和迭代负责人可以用下面的清单逐项核对。清单的作用是判断本次回顾是否达到完成标准，而不是评价会议气氛。
- 会前输入是否齐全：迭代目标、完成情况、范围变更、阻碍记录和上轮改进项进展是否在会前发出并被参与者阅读。
- 事实是否经过团队确认：完成情况和变更记录是否存在未被解释的差异。
- 关键问题是否收敛：是否明确选出了少数重点问题，并说明取舍理由。
- 改进项字段是否完整：每条改进项是否写明动作、负责人、完成时间和验证方式，负责人是否为具体个人。
- 改进项数量是否受控：是否控制在2至3项，超出部分是否转为待办或长期事项。
- 未完成工作是否重新评估：是否逐项判断继续、拆分、调整或取消，而非默认结转。
- 上次改进项是否被检查：上轮改进项的完成情况和验证结论是否在会上报告并作出关闭或继续的决定。
- 跟进时点是否约定：下次核对改进项的时间是否写入记录。
出现以下情形时，应阻断本次回顾的结论输出或安排重开：关键数据缺失且团队无法就事实达成一致；改进项没有具体负责人或验证方式；上次改进项未作任何检查；讨论集中在个人评价而非过程问题。此时可以先完成事实补齐或缩小议题范围，再另行安排一次短会形成改进项，避免在信息不足的情况下产出无法执行的结论。
常见问题
迭代回顾会和迭代评审会有什么区别，能不能合并开？
两者关注的对象不同。评审会面向迭代产出，由团队向相关方展示完成的工作并收集反馈，重点是交付物是否符合预期；回顾会面向团队自身的协作过程，讨论目标达成、范围变更、阻碍和流程问题，重点是下个迭代怎么改。两者可以安排在同一天前后衔接，但议程和参与人应分开设计。合并成一场会时，常见结果是时间被产出演示占满，过程问题来不及讨论，改进项草草收场。
团队在会上不愿发言，或者只有个别人主导讨论，主持人怎么处理？
先检查会前材料是否提前发出。参与者没有读过数据时，现场只能依赖记忆和印象，发言自然集中在少数人身上。可以要求每人会前提交至少一条观察，会上按顺序逐人收集，避免自由发言被强势声音占据。讨论原因时改用书面便签或在线收集，先各自写再统一展示，能减少从众。主持人还应控制自己的表达量，把追问留给团队，对针对个人的评价及时拉回具体事件和流程。
迭代周期很短，比如一周一个迭代，回顾会还要开两小时吗？
不需要。会议时长应随迭代周期和工作项数量调整。一周迭代可以把回顾压缩到45至60分钟：事实对齐用10至15分钟，原因讨论和问题收敛合并进行，改进项控制在1至2项。关键是保留三个动作：核对事实、选出重点问题、确认改进项的负责人和验证方式。周期短时，上次改进项的核对尤其不能省，否则改进动作会在快速迭代中被冲掉。
改进项连续几次回顾都没有完成，应该怎么处理？
先判断原因属于哪一类。如果是动作写得太大，把它拆成第一个可执行的小步骤，重新指定完成时间；如果是负责人没有相应的时间或权限，换人或由产品负责人协调资源；如果是问题本身已经不再重要，明确关闭并说明理由。连续未完成还可能是改进项数量过多，团队同时推进的事项超出承受范围，此时应减少每轮改进项数量。无论哪种处理，都要在下次回顾会上报告结论，避免同一项被反复挂起却无人决策。
跨团队依赖导致的问题，团队自己改不了，回顾时怎么处理？
把这类问题转为上报事项，不占用改进项名额。上报时写明依赖对象、对本次迭代的具体影响、期望解决时间和需要对方作出的动作，由迭代负责人或产品负责人提交给相应的协调机制。团队内部仍可形成一个可控动作，例如提前一个迭代确认对方排期、在迭代中期设置检查点。下次回顾会报告上报事项的进展，如果长期没有回应，应升级到更高层级的协调会议，而不是在团队内部反复讨论。
