该活动应设置时间盒，最长三个小时。重点是评估产品。开发团队专门为此活动准备的时间不应超过30分钟。很多时候，团队会陷入误区：使用临时支撑结构来让产品在Sprint评审会议中“运行良好”，或者花时间试图用精美的演示来“打动”相关方。但在这里，依靠外在手段很难说服他人----产品本身说明一切。团队应在接近最终用户环境的情况下演示产品，不使用任何特殊的“演示支持”，也不使用任何使产品看起来比实际更好的道具。一个好的经验法则是：禁止使用PowerPoint®（除非你的产品就是PowerPoint）。

此事件的典型活动可能包括：

• 用户对产品进行动手/实际探索。

• 讨论团队是否达成了Sprint目标。

• 产品负责人确定哪些产品待办事项(PBIs)已完成，哪些未完成（参见¶82完成的定义）。

• 开发团队演示已完成的功能。

• 产品负责人评估产品并决定是否接受PBI(s)。

o 产品负责人通常在Sprint计划时指定验收测试。产品负责人可能会在Sprint评审会议期间执行这些测试。

o 产品负责人可能偶尔会在Sprint结束前接受一个PBI（参见¶84响应式部署）；团队仍应开展Sprint评审会议，并与其他相关方共同审查在Sprint期间已发布的部分产品增量。

• 参与者讨论产品的方向，以及产品待办列表可能的排序。重点是学习。

• 讨论应考虑产品健康状况的指标，包括开发团队的速率、技术债务的推测（和实际）水平、缺陷和构建的当前状态，以及¶45产品路线图 的进展。

• 团队应回顾在之前Sprint评审会议中确定的行动的进展情况。许多此类行动项可能已被视为PBIs，但其他项可能需要在评审常规关注点之外给予特别关注。例如，团队可能发现了两个关键客户的需求存在不明确或冲突的问题。尽管它本身不是产品增量的一部分，但团队应持续关注该产品问题直至其得到解决。

产品负责人宜采取开放的姿态，听取团队对其决策和方向的反馈，特别是在产品方向、处理技术债务和产品质量方面的关键决策，了解团队是否认同并信任其决策指引。这有助于强化信任社区。

请注意，这个会议的议题完全围绕产品展开。而关于¶7 Scrum团队 绩效和流程的讨论，应在¶36Sprint回顾会议 中进行。

Sprint评审会议为各方创造信息：产品负责人和相关方了解产品的状态，包括可能的发布和未来方向。开发团队了解他们在多大程度上满足了相关方的期望，这为他们进行Sprint回顾提供了更多信息。

验证状态并获得对PBI(s)反馈的一个好方法是让用户动手实践（《哈佛商业评论》93 [Kol15]，第66页及后续）。例如，支持团队、拥有不同市场视角的用户焦点小组成员可以提供实际的见解。另一个例子是游戏工作室让玩家试玩他们的游戏以获得反馈。在Sprint评审会议中进行此类评估并不能替代完整的验收测试；然而，使能规范有时可以减少对此类广泛测试的需求。（如果产品负责人能凭经验证明其必要性，Scrum的迭代开发并不是省略长期运行的稳定性或耐久性测试的借口。）尽管如此，深思熟虑的用户还是会珍惜被倾听的机会，让他们参与此次评审有助于建立信任。最终用户确实可能会注意到产品与他们期望之间的差距，并且无论如何，当团队讨论未来产品方向时，他们都可以提供很好的输入。

许多Scrum拥护者将Sprint评审会议视为Scrum中敏捷反馈的主要机制，通常认为它能应对涌现需求、市场变化、业务条件变化等常见因素。这或许不无道理。但是，产品负责人和其他相关方很难在一个三小时的会议中，准确评估一个复杂的产品增量是否真正满足了预期的需求。更现实、更诚实的洞察来自于在更真实的应用环境中、在更长时间内尝试使用产品。然而，产品负责人和其他相关方能够并且将会注意到，人们在Sprint计划时认为达成一致的内容与开发团队交付的内容之间，存在不一致的假设和观点。这种差异更多地来自于流程中的问题，而非涌现或演变，或客户想法的改变。Sprint评审会议的主要功能之一，是让团队注意到是哪些流程失误导致他们交付了客户未预期的东西，并将这一认知带入Sprint回顾会议。

Sprint评审会议是团队反思过去Sprint所获成就的良机，这有助于¶38产品自豪感 的增长。如果团队达到了一个特别显著的目标，或者只是为了偶尔庆祝，Sprint评审会议也可以成为一种庆祝形式。芬兰的一家公司偶尔会在桑拿房里举行Sprint评审会议，配上美食和饮料，直到深夜。此活动涵盖了例行的议程项目，但真正的重点是让团队共同庆祝他们的工作成果。 (感谢Jukka Järvelä分享这个故事)