Sprint 回顾模板：4 种格式 × 3 种团队规模
三列 Start / Stop / Continue 看板 + 底部 Action Items 区域。适合 60 分钟直播式回顾会议，含 3 到 30+ 人团队的时间盒建议。可编辑白板——直接拖动便签、聚类主题、指定负责人和截止时间。
使用此模板模板亮点
- Start / Stop / Continue 三列 + 预填的便签示例
- 独立的 Action Items 区域，附 owner + deadline 提示
- 针对 3 人 / 15 人 / 30+ 人团队的时间盒指导
这个模板适合做什么
给不想只拿一张打印清单或只读教程的敏捷团队。这是一份可拖拽的白板模板，团队可以在 60 分钟的会议里直接贴便签（sticky note）、聚类主题、投票选出 action items。包含 4 种经过验证的回顾格式（Start-Stop-Continue、Mad-Sad-Glad、4L、Sailboat），并给出从 3 人小组到 30+ 人团队的时间盒建议。
适用场景
- 两周 sprint 结束后，Scrum 团队用 Start-Stop-Continue 做常规回顾。
- 新组建的跨职能团队用 4L 做第一次回顾，帮助建立反思习惯。
- 冲突较多或情绪波动明显的 sprint 后，用 Mad-Sad-Glad 释放情绪。
- 用 Sailboat 隐喻拆解复杂的跨团队依赖和系统性阻碍。
- 30+ 人部门级回顾：拆分小组 + 汇总到主白板。
- 在同一份文档里跟踪多个 sprint 的 action items 落地情况。
使用步骤
- 1Set the stage（5 min）：明确 sprint 范围，每人用一句话描述当前状态。
- 2Gather data（15 min）：所有人独立写卡片并贴到白板对应区域。
- 3Generate insights（20 min）：对卡片分组、标注重复主题、投票聚类。
- 4Decide what to do（15 min）：从高票问题中选 2~3 个 action items，指定 owner。
- 5Close（5 min）：每人说一句「下一个 sprint 想改变的一点」。
简单示例
Start / Stop / Continue 实际使用
相关资源
和相似工具的对比
Start / Stop / Continue
用三列区分应该开始、停止和继续的行为。适合稳定迭代、节奏固定的团队。结构直观、上手成本低，但容易停留在表层——需要主持人追问根本原因才能深入。
Mad / Sad / Glad
按情绪分类收集 sprint 体验。适合情绪波动明显或冲突较多的 sprint。能快速释放情绪、促进表达，但容易情绪化而忽略原因分析——主持人必须主动引导向「原因/行动」收敛。
4L（Liked / Learned / Lacked / Longed for）
从喜欢、学到、缺失和期待四个维度回顾。适合新团队或跨职能协作阶段。覆盖面比 3 列更完整，但填写量稍大——写作阶段建议留 20 分钟以上。
Sailboat
用帆船隐喻：风推着你前进、锚拉住你、暗礁是隐藏风险、岛屿是目标。适合复杂项目或跨团队协作 sprint，能可视化系统性问题。需要额外 5 分钟解释隐喻。
常见误区
只收集不收敛
卡片很多，但没有任何分类或归纳，会议结束仍是原始列表。破解：在中段强制进行 2 轮分组，每组必须写一个标签才能进入下一步。
变成吐槽会议
讨论集中在负面事件，没有行动输出。破解：每条负面卡片必须追加「可改变的动作」字段才算完成。
Action item 没负责人
所有改进点都写了，但没人执行。破解：每个 action item 强制填写 owner + 下一次 review 时间——没有负责人的行动是意向，不是承诺。
话多的人主导
少数人持续发言，其他人只补充。破解：使用 2 分钟 silent writing + 轮流发言机制，让每个人不管性格如何都能平等贡献。
白板变成「卡片墓地」
会议结束后白板留在原地，卡片没归档、action item 没跟踪，下次 retro 谁也不记得上次讨论了什么。破解：会议结束前用 5 分钟把 action items 复制到一个独立的 frame，命名为「Sprint N Action Items」；下一次 retro 开场直接打开这份白板做 5 分钟状态回顾。CodePic 的 frame 支持命名，能把每个 sprint 的 action items 都留在同一份文档里可追溯。
常见问题
Sprint retrospective 和 sprint review 有什么区别？+
Sprint retrospective 关注流程改进，sprint review 关注成果展示。在 retrospective 中，团队不看功能 demo，而是回顾「怎么做的」。实际操作中可以分开安排：review 45 分钟展示成果，retrospective 60 分钟讨论过程。避免混在同一个会议里，否则讨论会被 demo 打断。
团队回顾会议应该多长时间？+
常见比例是 sprint 每工作 1 周对应 45~60 分钟回顾。例如 2 周 sprint 通常安排 60 分钟。如果团队超过 10 人，可以增加到 75 分钟并加入分组环节。时间不足会导致只收集不分析。
如何让沉默的成员开口？+
先让所有人 5 分钟独立写卡片，不允许讨论。然后按轮次发言，每人最多 1 分钟描述一张卡片。这样可以减少即时压力，而不是直接点名发言。
Action items 如何真的落地不被遗忘？+
每个 action item 必须包含 owner + deadline + 可验证结果。例如「补齐 API 文档（张三，7 月 12 日前，PR 合并）」。同时在下一次 retrospective 开始前回顾上次所有 action item 状态。
Remote 团队怎么做 retrospective？+
使用在线白板工具（如 CodePic），分三个区：写卡片区、分组区、投票区。全程开启 timer，每个阶段严格控制时间，并使用 dot voting 代替口头表决，减少同步成本。
在线开始编辑
在 CodePic 中打开模板后，替换示例节点，就能很快整理成自己的学习导图。
