Sprint 回顾是什么
Sprint 回顾在评审之后、下个迭代之前进行，检视本轮在流程、协作、工具与技术实践上的表现，识别改进项并形成可执行的行动。回顾的对象是工作方式而不是人，产出的行动项需要责任人与验证方式，并在下个迭代复核。一个月迭代的回顾通常不超过三小时。
基本信息
| 参与者 | Scrum Master（主持）、开发团队；产品负责人视情况参加 |
|---|---|
| 输入 | 本轮事件与数据（速率、缺陷、阻塞时长、未完成项原因） |
| 时间盒 | 一个月迭代不超过 3 小时，两周迭代通常 1-1.5 小时 |
| 标准输出 | 1-2 个可验证的改进行动项，含责任人与跟踪时点 |
| 常见形式 | 做得好/待改进/新尝试、时间线回顾、根因讨论 |
典型使用场景
- 迭代节奏结束后检视协作方式，把反复出现的问题转化为改进行动
- 重大事故或严重缺陷之后，围绕根因组织专门回顾
- 团队扩张或人员变动后，重新校准沟通与协作规则
- 交付速度持续下滑时，识别技术债与返工的影响并制定改善计划
- 新流程试运行一个迭代后，判断保留、调整还是放弃
回顾常见形式（文字示意）
回顾常见形式（文字示意）
做得好 / 待改进 / 尝试新做法 # 适合节奏稳定的常规迭代
时间线回顾：按天标注关键事件与团队情绪曲线 # 适合刚经历波动的迭代
根因讨论：用 5Why 聚焦 1-2 个改进主题 # 主题过多则无法深入
输出行动项：做什么、谁负责、何时验证 # 缺任一项都会落空
跟踪：下个迭代开场先复核上轮行动项的完成情况 # 不跟踪等于没做改进项筛选标准
| 标准 | 说明 | 反例 |
|---|---|---|
| 可控 | 团队自身能推动，不依赖他人批准 | 要求公司更换报销系统 |
| 小步 | 一个迭代内能完成并观察到结果 | 全面重构遗留模块 |
| 可衡量 | 有明确的结果信号 | 加强沟通、提高积极性 |
| 成对出现 | 每项行动指定责任人与验证时点 | 仅写「大家注意测试覆盖」 |
回顾结论若无跟踪，团队会认为回顾是形式主义，逐步停止暴露真实问题。把行动项写进下个迭代的待办列表或看板的固定位置，并在开场时先复核上轮完成情况。