迭代回顾要围绕刚结束的这个迭代，把事实、问题和改进行动连成一条可追踪的线。会前收集迭代目标、Sprint Backlog 完成情况、范围变更和未完成工作；会上先对齐事实，再分析原因，收敛出1–3项改进；会后把改进项登记为有负责人、有截止时间的工作项，在下一个迭代中跟进验证。未完成工作需要重新评估剩余工作量和优先级，再决定去向，不做默认自动结转。
要点总览（TL;DR）
- 会前由回顾组织者提前1–2个工作日收集迭代目标达成情况、Sprint Backlog 完成与未完成清单、范围变更、阻塞与缺陷记录，并由执行人更新未完成工作的剩余工作量。
- 回顾会按“对齐事实—分析原因—收敛改进—明确责任”四步推进，改进项控制在1–3项，每项写明负责人、截止时间和可观察的验证方式。
- Scrum Master 负责数据准备、控场和改进项整体跟踪，产品负责人确认目标口径与未完成项优先级，开发团队更新状态、认领并执行改进项。
- 未完成工作逐项复核剩余工作量、重新判断业务价值，按条件放回待办、拆小纳入下一迭代或关闭，判定在下一迭代规划会之前完成。
- 回顾结束后用完成检查清单核对数据口径、改进项可执行性与后续跟进安排，改进项进入下一迭代的每日跟进和下次回顾验证。
迭代回顾会前要准备哪些数据和材料
回顾会的质量很大程度上取决于会前准备。准备的目标是让团队在同一个事实基础上讨论，避免会上花时间争论“到底做了什么”。建议由 Scrum Master 或团队指定的回顾组织者提前1–2个工作日完成数据收集，并在会前发给参会者预读。
可以直接使用下面这份准备清单逐项核对：
| 数据类别 | 具体内容 | 口径说明 |
|---|---|---|
| 迭代目标与达成情况 | 本迭代承诺的Sprint Goal、对应的验收结果 | 逐条标注“达成／部分达成／未达成”，部分达成需写明差距 |
| Sprint Backlog 完成情况 | 计划内工作项的完成、未完成清单 | 以迭代结束时的状态为准，区分“已完成”“进行中”“未开始” |
| 范围变更记录 | 迭代中途新增、删除、调整优先级的工作项 | 记录变更时间、提出方和原因，便于会上判断变更影响 |
| 阻塞与延期事件 | 过程中出现的阻塞、等待、外部依赖未到位等情况 | 标注持续时长和影响的工作项 |
| 缺陷情况 | 迭代内发现和修复的缺陷数量、遗留缺陷 | 区分本迭代引入与历史遗留，避免口径混淆 |
| 未完成工作初判 | 每项未完成工作的剩余工作量估算、当前优先级 | 由负责该工作项的成员在会前更新，供会上复核 |
准备时有两个细节容易被忽略。一是范围变更要单独列出，因为中途插入的工作往往是目标偏差的主要原因，混在完成清单里看不出来。二是未完成工作的剩余工作量要由实际执行人更新，而不是沿用迭代初的估算，否则会上讨论的“还剩多少”会失真。
数据准备完成后，组织者应做一次口径检查：完成状态是否统一、剩余工作量单位是否一致、变更记录是否完整。口径不一致的数据带到会上，讨论很容易变成对数字的争论。完成标志是：参会者能在会前读到一份完整、口径一致的数据包，会上无需再花时间核对基础事实。
回顾会怎么开：从事实还原到改进项收敛
回顾会建议控制在60–90分钟，按“对齐事实—分析原因—收敛改进—明确责任”四步推进。每一步都有明确的输入、动作和输出，主持人按步骤控场，避免讨论提前跳到解决方案。
第一步：对齐事实（约15分钟）
输入是会前准备的数据包。主持人逐项呈现迭代目标达成情况、完成与未完成清单、范围变更和主要阻塞事件，团队成员补充遗漏或纠正偏差。这一步只确认“发生了什么”，不讨论“为什么”。完成标志是全体对事实清单无异议，或异议已记录待后续核实。
第二步：分析原因（约25分钟）
围绕目标偏差和协作瓶颈展开讨论。主持人可以用两个引导问题开场：“哪些偏差最影响本迭代目标？”“过程中哪些环节让团队等待或返工最多？”让成员先独立写下观察，再合并归类，避免少数人主导讨论。分析时区分可控因素和外部因素，对每类问题追问一层原因即可，不必无限深挖。输出是一份按影响程度排序的问题清单。
第三步：收敛改进项（约20分钟）
从问题清单中选出影响最大、团队当下能推动的1–3项，转化为具体改进行动。判断标准是：动作可描述、范围可控、在一个迭代内能验证效果。例如“减少等待评审的时间”应具体化为“需求评审提前一天发出材料，评审意见在24小时内回复”。改进项过多会分散精力，宁少勿多。
第四步：明确责任与验证方式（约15分钟）
为每项改进确定负责人、截止时间和验证方式。验证方式要可观察，例如“下一个迭代中评审平均等待时间从3天降到1天”或“回顾会上检查改进项执行记录”。改进项登记格式建议包含以下字段：
- 改进项描述：一句话说明要改变的具体行为或流程
- 负责人：一名具体成员，负责推动和汇报
- 截止时间：通常落在下一个迭代内
- 验证方式：用什么数据或事件判断改进生效
- 关联问题：对应会上确认的哪个问题
会议结束前，主持人复述全部改进项并确认负责人无异议。会后当天把改进项登记到团队使用的协作工具中，作为工作项跟踪。如果团队使用 ONES，可以把改进项建成独立工作项，指派负责人、设置截止时间，并关联到对应迭代，这样在下一个迭代的每日跟进和回顾中可以直接查看执行状态，避免改进项停留在会议记录里。
回顾中的角色分工与各自交付物
回顾会涉及三类主要角色：Scrum Master（或团队指定的敏捷教练／主持人）、产品负责人和开发团队。职责清晰可以减少会前准备遗漏和会后跟进断档。
| 角色 | 会前职责 | 会中职责 | 会后职责 | 主要交付物 |
|---|---|---|---|---|
| Scrum Master／主持人 | 组织数据收集，检查口径一致性，提前分发材料 | 控场，保证先事实后原因的顺序，引导收敛改进项 | 整理会议记录，登记改进项并跟踪执行 | 迭代数据包、会议记录、改进项清单 |
| 产品负责人 | 确认迭代目标达成口径，说明范围变更的背景和取舍 | 解释需求变更原因，参与判断未完成工作的优先级 | 确认未完成工作的去向，参与下一迭代规划 | 目标达成说明、范围变更说明、未完成项优先级判断 |
| 开发团队 | 更新各自负责工作项的状态和剩余工作量 | 还原过程事实，提出问题和改进建议，认领改进项 | 执行改进项，在每日跟进中同步进展 | 工作项状态更新、问题观察、改进项执行记录 |
改进项的跟进责任需要单独说明：每项改进由认领人负责执行和汇报，Scrum Master 负责整体跟踪和在下次回顾中组织验证，产品负责人在改进涉及需求流程时提供支持。改进项与迭代工作项的关联方式建议是：改进项作为独立工作项登记，标注类型为“改进”，关联到来源迭代和计划验证的迭代，这样在迭代视图中既能看见改进执行情况，也不干扰正常交付工作的统计。
未完成工作如何重新评估和安排
迭代结束时未完成的工作不能默认带入下一个迭代。默认结转会让待办列表不断膨胀，也会掩盖规划或执行中的问题。回顾会后应逐项重新评估，按以下规则处理。
第一步：复核剩余工作量
由负责该工作项的成员重新估算剩余工作量，而不是沿用原估算减去已完成部分。如果过程中发现原估算偏差较大，要记录偏差原因，作为后续估算改进的输入。
第二步：重新判断优先级和业务价值
产品负责人结合当前业务情况，判断该工作项的价值是否仍然成立、优先级是否需要调整。迭代期间外部条件变化可能导致某些工作项价值下降，这类工作项应考虑关闭或放回待办池重新排序。
第三步：按条件决定去向
| 处理方式 | 适用条件 |
|---|---|
| 放回产品待办列表 | 仍有价值但优先级下降，或剩余工作量较大需要重新拆分排期 |
| 拆小后纳入下一迭代 | 价值明确、剩余工作量可在下一迭代内完成、优先级靠前 |
| 关闭 | 业务价值已不成立，或被其他工作项替代 |
第四步：与下一轮迭代规划衔接
处理结果应在下一迭代规划会之前完成，让规划会有准确的候选工作项。时点上建议在回顾会当天或次日完成判定，规划会直接使用判定结果，避免规划会上重新讨论遗留项去向而挤占规划时间。
一个迭代回顾的完整示例
以下为演示情景，用于说明前述方法的串联方式。
背景：某团队进行为期两周的迭代，迭代目标是完成订单查询模块的三个功能点并上线灰度。迭代结束时，两个功能点完成，第三个功能点完成约六成；迭代中途插入一个紧急缺陷修复，占用约两天工作量。
会前数据：组织者整理了目标达成情况（部分达成）、完成与未完成清单、范围变更记录（紧急缺陷插入时间与原因）、阻塞事件（第三方接口联调等待约一天半）、缺陷情况（本迭代引入缺陷4个，均已修复），以及未完成功能点的剩余工作量初判（约三天）。
会上识别的主要问题：团队对齐事实后，归纳出两个主要问题。一是迭代中插入紧急工作后，原计划没有相应调整，导致第三个功能点被压缩；二是第三方接口联调等待时间较长，前期没有提前确认对方可用时间。
形成的改进项：
- 改进项一：迭代中插入紧急工作时，由产品负责人在当天评估对原计划的影响并调整承诺范围，负责人为产品负责人，截止时间为下一个迭代第一周，验证方式为检查下一个迭代的范围变更记录是否附带影响评估。
- 改进项二：涉及外部依赖的联调，在迭代规划时确认对方可用时间并写入工作项备注，负责人为开发团队中负责联调的成员，截止时间为下一个迭代规划会，验证方式为规划会后检查相关工作项是否包含联调时间约定。
未完成工作的处理：第三个功能点剩余约三天工作量，产品负责人确认业务价值仍然成立，拆分为两个较小工作项后纳入下一迭代，并在规划会上重新排定优先级。
会后跟进：两项改进登记为工作项，关联到下一个迭代。在下一个迭代的每日跟进中，Scrum Master 每周检查一次执行状态；下次回顾会开场用十分钟验证两项改进是否生效。
回顾完成检查：怎样判断这次回顾有效
回顾会结束后，可以用下面这份清单逐项核对，判断本次回顾是否达到目的。清单可由主持人自查，也可在下次回顾开始时快速复核。
| 检查项 | 通过标准 |
|---|---|
| 事实数据完整、口径一致 | 迭代目标、完成与未完成清单、范围变更、阻塞和缺陷记录齐全，完成状态和剩余工作量口径统一 |
| 问题经过团队共同确认 | 问题清单来自会上讨论，团队成员对主要问题无重大分歧 |
| 改进项具体可执行 | 每项改进有明确动作描述，数量控制在1–3项，范围可在一个迭代内验证 |
| 改进项有负责人和截止时间 | 每项改进对应一名具体负责人，截止时间已确定 |
| 改进项有验证方式 | 每项改进写明用什么数据或事件判断是否生效 |
| 未完成工作完成重新评估 | 每项未完成工作已复核剩余工作量、重新判断优先级，并明确去向 |
| 改进项进入后续跟进 | 改进项已登记为工作项，关联到下一迭代，纳入每日跟进和下次回顾验证 |
如果清单中有多项未通过，优先补齐改进项的负责人、截止时间和验证方式，这三项决定回顾能否产生实际改变。回顾的价值最终体现在下一个迭代的行为变化上，而不是会议本身开得是否热闹。
常见问题
迭代回顾会开多长时间合适，时间不够时应该压缩哪部分？
建议控制在60–90分钟，四个步骤的时间分配大致为：对齐事实15分钟、分析原因25分钟、收敛改进项20分钟、明确责任与验证方式15分钟。时间紧张时优先保证“收敛改进项”和“明确责任”两步，因为这两步决定回顾能否产生后续行动；对齐事实可以改为会前预读数据包、会上只确认异议，分析原因则聚焦影响最大的两三个问题，不必逐条展开。
如果团队人数较多或问题较分散，也可以把分析原因拆成会前异步收集观察、会上集中归类，把会议时间留给改进项收敛。
团队第一次做迭代回顾，改进项应该定几项？
建议从1–3项开始，首次回顾尤其不宜贪多。判断标准是动作可描述、范围可控、在一个迭代内能验证效果。改进项过多会导致负责人精力分散，下次回顾时难以判断哪些真正生效。
如果会上识别出的问题较多，可以先把问题清单按影响程度排序，选出团队当下能推动的前几项转化为行动，其余问题记录在案，留待后续回顾继续处理。
改进项和普通迭代工作项要不要分开管理？
建议分开登记、建立关联。改进项作为独立工作项登记，标注类型为“改进”，关联到来源迭代和计划验证的迭代。这样在迭代视图中既能看见改进执行情况，也不会干扰正常交付工作的完成率统计。
如果团队使用 ONES，可以把改进项建成独立工作项，指派负责人、设置截止时间并关联到对应迭代，在下一个迭代的每日跟进和回顾中直接查看执行状态。
未完成工作如果价值仍然成立，是否一定要放进下一个迭代？
不一定。价值成立只是纳入下一迭代的必要条件之一，还需要满足剩余工作量可在下一迭代内完成、优先级靠前这两个条件。剩余工作量较大时，更适合拆小后分批纳入，或放回产品待办列表重新排期。
如果迭代期间外部条件变化导致价值下降，或被其他工作项替代，应选择关闭。无论哪种去向，判定都应在下一迭代规划会之前完成，让规划会拿到准确的候选工作项。
回顾会讨论出现分歧或情绪化时，主持人怎么处理？
先把讨论拉回事实层面。主持人可以请发言者指出对应的数据或具体事件，把“感觉某环节很慢”转化为“哪个工作项、等待了多久”。事实对齐之后再讨论原因，能减少立场之争。
如果分歧涉及对目标达成口径的理解不同，可以记录分歧、会后由产品负责人与相关成员核实，不在会上反复争论。主持人的职责是保证会议按步骤推进并收敛出改进项，而不是当场裁决所有争议。
