Sprint评审/冲刺回顾中，除了新功能演示你还要做这三件事

在Sprint审查期间最可辨别的事情是演示Sprint期间构建的功能。但是，一个好的sprint评审不仅仅包括功能演示。让我们看一下Sprint评审的议程。

欢迎参与者并为Sprint评审搭建舞台

产品所有者首先欢迎所有人参加Sprint评审。这可以简单到说“谢谢你来。”

如果参与者彼此不熟悉，产品所有者可能会让与会者简要介绍自己。在新产品开发计划开始时，自我介绍通常是一个好主意。产品所有者知道来自Marketing的Joe，但团队成员可能不知道。

如果偶尔的新参与者参加sprint评论很常见，那么介绍也会很有帮助。也许来自市场营销部的乔只会参加两个评审会议，这是在团队致力于营销相关功能的冲刺之后。

介绍应该保持极短。“嗨，我是迈克，我是开发人员。我一直在研究购物车的功能“——太多了。在某些情况下，“我是迈克，我是开发人员”——这就足够了。但是，一旦团队达到一定规模，可以让利益相关者知道谁在做什么。

在产品所有者的初步欢迎和任何所需的介绍之后，产品所有者可以分享任何基本规则或对冲刺审查的期望。例如，一些产品所有者认为有必要说明保持会议的公平性。如果某人不喜欢某个功能的实现方式，但不要把实现称为“愚蠢的”等等。是的，不管怎样，我们都应该知道这样的事情，但有时人们需要被提醒。

根据与会者的数量和许多其他因素，产品所有者可能还会声明，当她在寻找关于构建内容的反馈时，Sprint审查本身并不是重新设计功能的时候。

随着欢迎信息、介绍和基本规则的出现，现在是时候进入议程上的下一个项目了。

说明会（或者不会）展示什么

在这一点上，许多团队直接进入并开始演示。相反，我建议产品所有者简要介绍将要演示的内容和不会演示的内容。

为避免产品所有者只是阅读参与者无法遵循的项目列表，请在显示器或正在使用的投影仪上显示内容，或者为那些想要的人提供印刷版。

我喜欢将其作为日事清上的文档准备，并在审核前的一天结束时通过日事清发送给可能的审核参与者。这使人们有机会看到将要演示的内容。然后，每个人都可以根据将要显示的内容决定是否参加。

下表显示了我希望为每个产品backlog项目包含的信息。我建议将此列表按照演示项目的顺序排列，你可以在会议期间根据需要随时更改。

· 以项目的描述开始。将用户故事或其他说明放在此处。

· 项目的大小，通常这将是故事点。

· 列出项目的状态。大多数情况下，这是项目是否完成，但包括其他重要的事项。

· 最后添加一个列，指示是否将演示该项目。

你可能想知道为什么我们会有团队不会演示的项目。我在示例表中提供了几个示例。显然，计划进入sprint但丢弃的项目无法展示。我还展示了一个简单的错误修复程序，可以在一个屏幕上更新一个字符 - 它也没有安排进行演示。

一个或多个参与者可能会要求查看您未计划展示的项目。当发生这种情况时，请继续展示该项目以及所有其他项目。你不是试图避免展示某些东西，你只是试图通过不向他们展示那些不需要反馈的东西来尊重他们的时间。

请注意，在上面的示例中，我指出在sprint期间添加了一个产品积压项目。我认为在sprint期间添加项目是一个好主意，这样可以将它们与计划进入sprint的项目区分开来。如果经常添加项目，请考虑添加初始列并将P（对于计划）或A（对于已添加）放入其中。

避免在议程的这一部分上花太多时间。这里的目标不是获得有关项目的反馈或讨论为什么计划项目仅部分实施。这仅仅是会议其余部分的目录。在产品所有者提交此列表后，转到sprint审核的主要部分：演示本身。

演示新功能

这是Sprint评审的核心。如果你已经在进行冲刺评论，那很可能这是你正在做的议程的唯一部分。

在此部分审核期间，请继续查看您之前向与会者展示的项目列表。请记住，Sprint评审的目的是征求反馈意见。

关于谁给出演示没有硬性规定。在某些情况下，产品所有者将给出演示。我建议在与特别具有挑战性的利益相关者的审查中这样做。但是，其他时候，团队成员将演示他们所处理的特定产品积压项目。这些方法都可以，你可以找到最适合您团队的那个。

讨论关键事件

在演示完所有已完成的产品积压项目后，讨论冲刺期间发生的关键事件或问题。

产品所有者或Scrum Master可以促进这种讨论。我发现这两种方法同样有效。但是，我确实对Scrum Master执行会议的这一部分有一点偏见。

到目前为止，在大多数sprint评论中，产品所有者将比Scrum Master做更多的讨论。所以我发现让Scrum Master为这个议程项目提供便利是一个很好的平衡点。此外，这通常更多地是对流程的讨论，而不是严格的产品讨论，因此它在Scrum Master的领域中更多一些。

提交即将发布的产品Backlog项目

Sprint评审的议程的最后一项应该是对产品积压（product backlog）下一步工作的讨论。因为冲刺审查的目的是获取有关当前冲刺工作的反馈，这通常会影响后续冲刺中的工作。

例如，如果审查的参与者喜欢新屏幕的外观，那么产品所有者可能希望加速将产品的其他部分转移到新设计中。或者，如果参与者不喜欢某个特性是如何实现的，那么下一个sprint应该花在解决它的问题上，而不是转移到下一个项目上，就像在没有sprint评审的情况下可能发生的那样。

产品所有者通过展示产品待办事项中的下一组潜在项目来开始此讨论。产品所有者可能会说，“在屏幕上，你会看到我认为下一个要处理的十件事情，但我想插入今天出现的这样的东西。我将补充说明可能是第三项。“

产品所有者然后征求参与者关于拟议的下一组项目的评论。但是，我不建议产品所有者根据这些评论在冲刺审核期间做出任何优先级决定。产品所有者可能需要时间来考虑审核中的内容。或者，产品所有者可能希望从团队获得有关审核中请求的更改的估算值。等等。相反，产品所有者在冲刺审查期间征求意见，然后在会议后做出决定。

会议结束

最后请感谢大家参与。考虑感谢整个团队的冲刺工作。考虑偶尔赞扬一个或两个在冲刺期间表现出色的团队成员。提醒每个人下次审核的时间和地点。

Sprint评审之后

虽然不是实际审核议程的一部分，但有人应该将任何新产品积压项目输入团队正在使用的任何工具中（或者如果使用实体卡，则将其发布在墙上）。

你如何进行评论？

请让我知道你如何进行冲刺评论。你包括我没有提到的任何东西吗？你跳过这些步骤吗？请在下面的评论中分享您的想法。