Sprint Retrospective（迭代回顾会）是 Scrum 团队在每个迭代结束时召开的复盘会议，目的是检视协作过程本身——哪里做得好、哪里有问题、下个迭代改进哪一件事。 它评审的是「我们怎么工作」，而 Sprint Review 评审的是「我们做了什么」。
30 秒版
- 频率：每个 Sprint 结束时一次，紧随 Sprint Review；
- 时长：两周 Sprint → 60~90 分钟；一周 Sprint → 45 分钟；
- 产出：1~2 条有负责人、有验证方式的改进行动项（不是一堆「下次注意」）；
- 健康信号：连续三次回顾会的行动项都落地了，说明流程在真实改进。
回顾会标准议程（60 分钟版）
| 时间 |
环节 |
目的 |
| 0:00–0:05 |
开场与破冰 |
定基调：安全、对事不对人 |
| 0:05–0:15 |
收集数据 |
全员写下本迭代的事实与感受（用下面的活动框架） |
| 0:15–0:30 |
生成洞察 |
归类、投票，找出最重要的 1~3 个主题 |
| 0:30–0:50 |
决定行动 |
把主题转成具体行动项：谁做、做什么、怎么算完成 |
| 0:50–0:60 |
收尾 |
回顾上次行动项的完成情况，确认本次行动项进看板 |
回顾会最大的失败模式不是冷场，而是「聊得很热闹，行动项没人跟踪」。 行动项必须进迭代看板，和需求同等对待。
24 个回顾会活动/游戏点子
A. 经典框架（日常轮换够用）
Start / Stop / Continue：开始做什么、停止做什么、继续做什么。最简单通用，适合任何团队；
4Ls：Liked（喜欢）、Learned（学到）、Lacked（缺少）、Longed for（期望）；
Mad / Sad / Glad：情绪导向，适合暴露士气问题；
帆船（Sailboat）：风=助力，锚=阻力，礁石=风险，岛屿=目标。视觉化强，适合项目里程碑节点；
KPT：Keep / Problem / Try，日系团队常用，结构清爽。
B. 聚焦质量的专项活动
缺陷地图：把本迭代缺陷按模块聚类贴出来，肉眼找「缺陷重灾区」，讨论是设计问题还是流程问题；
返工时间线：列出每个被打断/返工的任务，追问根源（需求不清？环境不稳？报告缺上下文？）；
一次难忘的 Bug：每人讲本迭代最离谱的一个缺陷及其根因，比抽象讨论有效得多。
C. 活跃气氛的破冰游戏（KD 最低的那类「回顾游戏」）
两真一假：每人说三件本迭代发生的事，其中一件是假的，其他人猜；
Emoji 天气预报：用表情包总结自己本迭代的状态；
轮盘抽人：随机指定下一发言者，避免总是同几个人说话；
时光机：想象一年后回看今天的项目，写一封信给现在的团队。
D. 深挖根因的活动
5 Why：对票选出的头号问题连问五个为什么；
鱼骨图：从人、流程、工具、环境四个维度归因；
倒放（Pre-mortem）：假设下个迭代失败了，提前写「失败报告」，反推要防什么。
E. 远程团队适用
在线白板便利贴：FunRetro / EasyRetro / Miro 的经典三栏板，匿名贴条 + 点票；
静默书写再讨论：先全员独立写 3 分钟，再逐条过，避免被先发言的人带偏；
热力投票：每人 3 票投给最想讨论的便利贴，得票前 2 才进讨论；
分时段分组：大团队先 breakout room 小组讨论，再合并汇报。
F. 维持新鲜感的变体
等级评分：给本迭代打分（1~10）并说出为什么不是更高分；
目标检视：把 Sprint Goal 贴出来，讨论每项工作对目标的实际贡献；
角色互换：开发替 PO 发言、PO 替 QA 发言，各说 2 分钟；
感谢圈：每人公开感谢一位同事的具体帮助，收尾用，修复情绪；
微实验：把行动项包装成「实验」：本迭代试一下 X，下届回顾会看数据决定留不留。降低承诺压力，更容易落地。
行动项怎么写才不会被遗忘
| 坏写法 |
好写法 |
| 「加强测试」 |
「发布前按 checklist 走一遍，由本周值班 QA 执行，两届回顾会检查执行率」 |
| 「减少无效沟通」 |
「缺陷报告统一走台账，群里只发链接不描述问题，下周三抽查一次」 |
| 「提高代码质量」 |
「引入提交前 lint 钩子，本周五前由后端负责人配完」 |
共同特征：有负责人、有截止时间、有可验证的完成标准。
用数据支撑回顾会，而不是凭印象
「这迭代质量不行」这种印象式结论在回顾会上只会引发辩解。用可量化的数据说话：
- 缺陷的来源分布（内部测试发现 / Beta 用户报告 / 线上用户报告）。
这些数据需要一个统一的缺陷台账，而不是翻群聊记录。BugCapturer 的报告自动附带截图标注与 Console/Network 报错（见诊断功能），并自动推送进 Slack / Microsoft Teams 频道形成统一跟进入口，按模块/严重级/状态透视即得上述数据——回顾会前导出一张表，缺陷地图（活动 6）和返工时间线（活动 7）的素材就有了。
FAQ
Q：Sprint Retrospective 的目的是什么？
A：持续改进团队的工作方式。Scrum 指南明确其产出是可执行的改进计划，而非单纯的情绪表达。
Q：回顾会和 Review 有什么区别？
A：Review 评审产品增量（给干系人演示），Retrospective 复盘协作过程（只有团队参加）。两者都要开，不能合并。
Q：团队只有 3 个人，有必要开吗？
A：有必要，可缩短到 30 分钟：5 分钟收集、10 分钟投票、15 分钟定行动项。小团队改流程更快，回顾会的收益反而更大。
Q：总是同样几个问题反复出现怎么办？
A：说明行动项没有落地或没有负责人。下一届回顾会第一件事就是公开检视上次行动项的完成率，必要时把「改进项落地」纳入 Definition of Done。
Q：回顾会上抱怨太多、气氛压抑怎么办？
A：收尾必须用感谢圈或等级评分这类正向活动收束；并确保每次至少有一个「继续做」的结论——回顾会不是批斗会。