本文主要是为了检测你对SCRUM 评审会议的了解和使用程度,
通过本文你可以检测一下
1、你们的SCRUM 评审会议的过程和步骤
2、SCRUM 评审会议的输出结果
一、会议目的
1. 团队的成果得到认可。他们会感觉很好。
2. 其他人可以了解你的团队在做些什么。
3. 演示可以吸引相关干系人的注意，并得到重要反馈。
4. 演示是（或者说应该是）一种社会活动，不同的团队可以在这里相互交流，讨论各自的工作。这很有意义。
5. 做演示会迫使团队真正完成一些工作，进行发布（即使是只在测试环境中）。如果没有演示，我们就会总是得到些99%完成的工作。有了演示以后，也许我们完成的事情会变少，但它们是真正完成的。这（在我们的案例中）比得到一堆貌似完成的工作要好得多，而且后者还会污染下一个 sprint。
6. 根据团队这次 Sprint 所发布的版本，评审相关的 Backlog 中的问题，检查是否已达到 Sprint 的目标。
7. Scrum 团队在会议中向最终用户展示工作成果。团队成员希望得到反馈，并以之创建或变更 Backlog条目
二、会议时间
1. 该会议时间限制为不超过 90分钟。
三、会议准备
1. 邀请与会者：
产品负责人
Scrum Master
团队所有成员
2. 对于每个人来说 Sprint 目标都是公开的
3. 对每个人来说既定产品 Backlog 是公开的，可获取的
4. 小组准备好工作站和设备等等，用以展示产品的新功能
四、会议进程
1. Product Owner欢迎大家来参加Sprint 复审会议。
2. Product Owner提醒大家关于本次 Sprint的目的：Sprint目标、Scrum团队在
3. 本次Sprint中选定要开发的故事。
4. 产品开发团队展示新功能，并让最终用户尝试新功能。
5. Scrum Master 推进会议进程。
6. 最终用户的反馈将会由 Product Owner和/或Scrum Master记录
(1). 如果产品负责人想要改变功能：添加一个新问题到产品 Backlog 中
(2). 如果对功能有一个新的想法：添加一个新问题到产品 Backlog 中
(3). 如果小组报告项目遇到阻碍现在还没能解决：把该障碍加入到障碍 Backlog
7. 注意事项：
(1). 确保清晰阐述了 sprint 目标。 如果在演示上有些人对产品一无所知，那就花上几分钟来进行描述。
(2). 不要花太多时间准备演示，尤其是不要做花里胡哨的演讲。把那些玩意儿扔一边去，集中精力演示可以实际工作的代码。
(3). 节奏要快，也就是说要把准备的精力放在保持演示的快节奏上，而不是让它看上去好看。
(4). 让演示关注于业务层次，不要管技术细节。注意力放在“我们做了什么”，而不是“我们怎么做的”。 可能的话，让观众自己试一下产品。
(5). 不要演示一大堆细碎的 bug 修复和微不足道的特性。你可以提到一些，但是不要演示，因为它们通常会花很长时间，而且会分散大家的注意力，让他们不能关注更加重要的故事。
五、会议结果
1. 对这次 Sprint 的结果和整个产品的开发状态的共识
2. 来自最终用户的反馈
3. 障碍backlog输入
4. 团队backlog输入
5. 来自团队的product backlog输入