通常Sprint回顾会议会在 Sprint 结束时举行。这是一个团队自我反思的好时机。检视已完成的工作可以揭示一个完整的系统视角（其中系统指的是团队及其流程）。在流程中途评估进展只能得到片面的画面，且视角非常有限。因此，我们将回顾会议与工作的完成——即 Sprint 的边界——对齐。此外，Sprint 中的挑战与成功在每个人的脑海中仍然记忆犹新。

团队为了实现最大价值而提出流程变更建议。流程变更可以涉及人员、人际关系、流程、环境或工具。

Scrum 的根源在于丰田生产系统（TPS），而TPS的核心便是流程改进。在 TPS 手册中，我们找到了这样的指示：“检查就是‘反省’(hansei)。”“反省” (Hansei) 是一种因失败而产生的深刻的个人或集体悔意。一个好的 Scrum团队会对其失败进行“反省”，然后将而产生的悔意转化为积极解决问题的积极能量；请参阅 ¶92 Scrumming the Scrum。因此，Sprint 回顾也是团队疗愈和更新的时间。精益社群认为大野耐一是 TPS 的创始人。一句通常认为出自他名言是：那些声称自己没有麻烦的人往往比别人有更多麻烦。（没有问题本身就是最大的问题。）

要培养一种文化，让Sprint 回顾成为每个 Sprint 不可或缺的一部分。将它融入团队的常规节奏中。千万要避免因为觉得需要时间去完成Sprint 的最后工作而跳过它。这种想法会把团队的文化推向认为回顾会议并非真的重要。

为会议设定时间盒。给予足够的时间来深入探讨问题，但不要长到让人感到厌烦。对于为期一个月的 Sprint，Scrum 建议会议时间不超过三小时。当 Sprint较短时，会议通常也较短会相应缩短。

通常，整个 Scrum团队都应参加，包括产品负责人。在极少数情况下，如果开发团队成员觉得 产品负责人主导了对话或以其他方式压制了坦率和公开的讨论，开发团队可能会要求产品负责人不要参加。请注意，这很可能是预示着更大问题的。因为 Scrum 是一个帮助消除问题以实现更大价值的框架，而且产品负责人处于价值主张的核心，所以产品负责人在这些会议中的有效参与，对团队的长期成功有至关重要的意义。敏捷宣言其中一项原则是定期举行回顾会议：团队定期反思如何能变得更有效，然后相应地调整和修正自己的行为。

回顾会议，特别是定期举办的回顾会议，很容易变成一种肤浅的会议，探讨不到任何实质性问题的形式会议。为了应对这个问题，可以使用已知的有效回顾方法，例如《敏捷回顾：打造优秀团队》[DL06] 中所列举的方法。例如，一种方法是识别进展顺利的事情、持续存在的问题以及具体要采取的行动（《敏捷软件开发（第二版）》[Coc06]，《项目回顾：团队审查手册》[Ker01]）。考虑不时变换方法。将讨论建立在经验洞察的基础上。特别是，检查诸如完成的 Sprint待办清单百分比和团队速率等具体指标。此外，确定团队在下一个 Sprint 中将要进行的具体流程变更。

在障碍清单中对计划的变更进行优先级排序。¶88 循序渐进 模式建议团队一次只做一个变更，这样他们才能理解每个变更是如何促进改进的；另请参阅 Scrumming the Scrum。¶91 Happiness Metric (幸福度量) 模式建议采纳最能增加团队热情和参与感的变更。同时，要确保你能衡量变更所带来的好处与坏处：它的成本、益处和缺点（请参阅 ¶87 Testable Improvements (可测试的改进）。

持续使用 Sprint回顾并不能保证流程一定会被改善，甚至不保证流程的稳定。虽然因此仅仅进行举行回顾会议是不够的，更要紧的是将「改善」(kaizen) 的思维熟于脑中（请参阅第 101页的 Kaizen 和 Kaikaku）。好的Sprint 回顾会鼓励团队，并让他们为能够随着时间推移而看到的进步感到自豪；请参阅 ¶38 Product Pride (产品自豪感)。

回顾会议很容易退化成抱怨大会。为了克服这个问题，请遵循 Norm Kerth 的最高指导原则来进行回顾会议：「无论我们发现了什么，我们都理解并真正相信，在当时所知的情况、自身技能和能力、可用资源以及手头处境下，每个人都已尽力做到最好。」（《项目回顾：团队审查手册》[Ker01] 第六章「回顾练习」）。这需要一个如¶95 Community of Trust (信任社区) 第 466 页 中所描述的社群。同时，让团队意识到他们自己能改变什么，以及在短期内甚至可能完全无法改变什么（《高效能人士的七个习惯》[Cov94]）。此外，要同时找出好的方面（“金块”）和问题。不要只看坏的方面。一些好的事情可能值得写下来。例如，一份书面的 ¶82 Definition of Done (完成的定义) 应该随着团队发现和学习达成「完成」的新技术而增长（请参阅 Definition of Done）。抱怨也可能预示着更深层次的问题，Scrum Master应对回顾活动整体基调中更深层问题的线索保持警觉。

请注意，仅仅两三个小时的回顾会议通常不足以探讨深层次的问题。因此，Sprint 回顾在某种程度上是需要在深度讨论和会议时长之间的找到一种个折衷。在 Sprint 回顾期间发现的问题，可能存在某种更深层次、更复杂的关系，而团队无法在短短三小时内恰当地揭示和探讨这些关系。Jeff Sutherland 根据他与投资集团的一次交流所写的经验报告中提到以下内容：障碍就像蚊子。你拍死一只，又飞来 25 只。所以，你需要找到根本原因。你必须把沼泽的水抽干，才能让那些蚊子不再来。

为了「抽干沼泽」，你可以考虑在双环甚至三环学习的层面上工作，正如 Swieringa 和 Wierdsma 在《成为学习型组织：超越学习曲线》[SW92]，第 37-42 页中所描述的那样。简而言之：单环学习是关于改变规则，而双环学习则是改变底层结构。三环学习处理的是组织基础和历史中的核心原则与价值观。Norm Kerth 建议花三天时间来探讨组织中的深层结构性问题，并为此提出了一个为期三天的异地回顾会议框架，以驱动达到这一层次的改进（《项目回顾：团队审查手册》[Ker01]）。Kerth 的深度回顾会议更适合处理团队深层的脆弱性，因为它比相对简短的 Sprint 回顾投入更多时间来建立团队成员之间的信任。它还能实现比 Sprint 回顾通常关注的增量式变更更深层次的「改革」(kaikaku)（非连续性）变更。

当时负责 Skype 高品质音视频及编解码器开发的 Skype影音工程团队，会结合他们的 ¶83 Team Sprints  偶尔举行两到三天的异地会议。这些活动促成了新的发明、他们自己工作空间的重新设计，以及开发流程的创新。 — [Gil19]