在Sprint评审会过程中最有辨识度的活动，就是对在Sprint中所构建的功能进行演示，但是一个好的Sprint评审会不仅仅局限于此。
下面是一个我所使用的Sprint评审会议程示例，供大家参考。
欢迎参会者，并为Sprint评审做好准备
产品负责人可以简单地用“感谢大家前来参会”作为开场白来欢迎大家参加Sprint评审活动。
如果参加者彼此之间不熟悉，产品负责人可能邀请他们作简单的自我介绍。通常自我介绍环节是新产品启动的一个不错的想法，毕竟团队成员不如产品负责人了解谁来自于哪个部门。
这也对那些偶尔参加Sprint评审的人很友好，例如有些来自于市场部的同事仅需要参加团队交付与市场相关需求的其中两次Sprint评审。
然而，这个环节需要尽可能地简要，只需要介绍自己姓名以及角色即可。但是如果团队达到某种规模，再追加介绍自己所负责的工作可以帮助干系人更快的了解成员情况。
在产品负责人完成欢迎环节和一些必要的介绍之后，就可以分享评审过程的基本规则或对Sprint评审的期望。例如，一些产品负责人发现有必要保持会议的文明，如：可以直接说不喜欢某个功能的实现方式，但不要称其“愚蠢”等等。虽然这些显而易见的事大家都心知肚明，但必要的时候还需要给予提醒。
另外，基于参与者的人数和其他因素，产品负责人可能还需要申明在Sprint评审环节更侧重的是反馈而不是对功能的再设计。
有了欢迎辞、介绍和基本规则，现在是时候进入下一个议程环节了。
说明演示的范围
在这一点上，许多团队开始就直奔演示。相反，我建议产品负责人尽可能简要概述一下演示范围。
但是产品负责人如果只是口头陈述，会让参与者无法跟上节奏以清晰明确演示清单。请在显示器或者投影仪上同步展示这部分内容，或者打印一些材料供参与者阅读。
我喜欢把它准备成一份文件，并在前一天下班前通过电子邮件发送给潜在参与者们。这让人们有机会看到将要展示的内容，并可以据此对于是否参加评审进行决策。
下方是一个示例表，列出了我希望评审过程中展示的每个产品待办项的关键信息，并建议将此列表按演示的顺序排列（顺序可以在会议期间根据需要随时更改）。
表格以用户故事或其他条目的描述开始，紧随其后通常是以故事点统计的条目规模。然后列出包括项目是否完成、其他需要注意事项的条目状态。最后一列，显示是否在本次评审中演示该条目。
你可能好奇为什么在上述列表中有几项是计划不演示的，接下来跟大家解释一下。
那些被计划在Sprint中但又没有全部完成的内容通常不会被演示（除非团队完成的工作足以帮助解决一些未决问题）。我还展示了一个简单的错误修复，只更新了一个屏幕上的一个角色，但也没有安排演示。我们聚焦的是获得利益相关者的反馈，而类似漏洞修复或者过多细碎的内容会让利益相关者失望，最终影响Sprint评审的出席率。
很可能有参与者会要求查看一些计划外的内容。当这种情况发生时，和其他内容一起演示即可。毕竟你并不是想逃避演示，只是想尊重人们的时间以让利益相关者充分参与，从而会把那些不那么需要收集反馈的内容排除在计划外而已。
注意上面的示例表，还列出来一个在Sprint期间新增的产品待办项。我认为最好指出在Sprint过程中新增的内容，以便将它们与在Sprint计划会中所确认的内容区分开来。如果新增内容的事情频繁发生，可以考虑添加一个初始列。在这个列中可以填P（表示计划内容）或A（表示新增内容）。
或者你还想在最右侧新增一列，用于指示每个条目是否被评审参与者接受或准备发布等。如果这类决策行为是Sprint评审的一个正式环节，那么就这样做吧（但我不建议将Sprint评审作为签字会议）。
注意避免在这个环节花费太多时间，这只是会议环节的介绍。目标不是获得对交付内容的反馈，也不是谈论为什么计划只完成了一部分。在产品负责人介绍完这个列表之后，就进入Sprint评审的主要部分：演示。
演示新功能
这是Sprint评审的核心。如果你已经在进行Sprint评审，这很可能是你议程中唯一的内容。
在评审的这一环节中，按照您之前向会议参与者介绍的内容列表逐次演示。请记住，Sprint评审的目的是征求反馈。
此处没有硬性规定谁来做演示负责人。在某些情况下，尤其建议在与特别具有挑战性的利益相关者进行评审时由产品负责人操作演示。但其他时候，团队成员会演示他们完工的某个产品待办项。任何方法几乎都可以，试着找到一个最适合你的团队的就行。
讨论关键事件
演示完所有已完成的产品待办项后，再讨论Sprint过程中发生的关键事件或问题。
这一讨论可以由产品负责人或Scrum Master引导。虽然这两种方法都同样有效，但是我更倾向于让Scrum Master主持这部分会议。到目前为止，在大多数Sprint评审会议中产品负责人都是比Scrum Master说的更多。因此，我发现让Scrum Master为这个议程提供引导是一个很好的平衡。另外这个环节通常更多讨论的是过程而不仅仅是产品，更符合Scrum Master所在的领域。
介绍后续的产品待办项
Sprint评审议程的最后一项应该是对后续产品待办工作的讨论。Sprint评审的目的是获得对当前Sprint工作的反馈，而这通常会影响后续Sprint的工作内容。
例如，如果评审的参与者喜欢新的界面外观，产品负责人可能希望加快将新设计延用到产品的其他部分。或者如果参与者不喜欢某个功能的实现方式，也许下一个Sprint应该花在解决这个问题上。而不是像没有Sprint评审的时候，直接继续进行下一个待办条目。
产品负责人通过展示产品待办工作中的下一组潜在内容以开始这个讨论环节。他可能会说，“在屏幕上，你会看到我原计划接下来要做的十件事。但我想加入一些今天发现的内容，可能会将其添加在第三项。”
然后，产品负责人征求参与者对拟议的下一组待办项的意见。然而，我不建议产品负责人在Sprint评审期间根据这些意见做出任何有关优先级的决定。原因有很多，例如产品负责人可能需要时间思考这些意见，或者产品负责人可能希望从团队那里获得关于评审过程中所要求变更的评估等等。所以产品负责人是在Sprint评审期间征求意见反馈，然后在会议后做出决定。
会议总结
最后，可以简单地感谢大家的参与，也可以考虑一下感谢整个团队在Sprint中所做的工作，或者偶尔表扬一两名在Sprint中表现特别好的团队成员，并最终提醒大家下一次评审的时间和地点。
Sprint评审后续工作
虽然不是评审议程的一部分，但需要有人将任何新的产品待办条目输入团队正在使用的工具中（如果使用物理卡，则将其张贴在墙上）。
你是如何进行Sprint评审的？你的Sprint评审会议程中有我没提到的内容吗？你跳过其中的一些步骤了吗？欢迎在下方的评论区分享你的想法。
原文地址：冲刺评审的议程 (mountaingoatsoftware.com)
注：部分图片来源于网络
关于作者
【作者】Mike CohnMike是敏捷联盟及Scrum联盟创始人之一，是帮助企业适应和改进敏捷过程及技术，以建立极致高效团队的专家。著有《用户故事与敏捷方法》，《敏捷估算与规划》，《Scrum敏捷软件开发》以及视频课程《更好的用户故事》。
【译者】Scrum中文网翻译组
Scrum中文网是全球第一个Scrum中文网站，中国最早的Scrum和敏捷教育及推广机构，也是国际Scrum联盟（ScrumAlliance）官方授权教育机构，Scrum.org官方合作培训机构，大规模敏捷SAFe官方机构SAI中国区授权合作伙伴。Scrum中文网是国内领先的敏捷培训及教练咨询机构，作为中国敏捷教练的摇篮，启蒙和培养了数万名敏捷专业人士，帮助数百家知名企业成功转型敏捷。
