0. 前言
按照The Scrum Guide的定义（这里是中文版：Scrum指南中文版（The Scrum Guide）），迭代评审会是在Sprint快结束时举行，用以检视所交付的产品增量并按需调整产品待办列表的一个会议。在Sprint评审会议中，Scrum团队和利益攸关者协同讨论在这次Sprint中所完成的工作。根据完成情况和Sprint期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情来优化价值。
那么如何召开一个成功的迭代评审会议呢？根据对多次迭代评审会议的观察，总结如下：
1. 鸡类角色与猪类角色都要参与迭代评审会议
以下两类人员都应该参与：
- 项目组的所有成员，包括PO、SM、开发和测试人员。
- 项目组外部的其他利益相关者，包括客户、最终用户、管理者等。
上述两类角色都是必须的。只让项目组成员参与的迭代评审会议不能获得充分的反馈意见，会让会议的价值大打折扣。
2. 选择合适的演示操作人员
强烈建议由PO进行演示操作，一是让PO实际操作、感受一下软件，便于提出更多的功能改进建议，二是PO展示时，关注完成了什么，而不是怎么做的，关注于业务，而非技术。三是迭代评审会议不是给PO汇报需求完成情况，而是整个团队的成员给项目组内外部的人员展示需求完成情况，也可以在会议上，让用户试用一下软件。
PO不应该只是在迭代评审会议上才看到完成的软件功能，在每天的站立会议之前应该都检查过功能是否满足了客户的需求。
3. 事先准备演示环境与演示数据，不准备PPT
演示环境，演示的数据需要提前准备好，以提高会议的效率。由于是多个人参加的会议，一旦出现演示环境准备不充分的情况，会导致大量的时间浪费。
如果前期做过功能测试，则演示的环境可以基于测试环境进行准备。
迭代评审会议只看Demo，不看报告，所以不需要准备PPT。
4. 要向所有人重申一下本次迭代的目标
有的人知道本次迭代的目标，有的人可能已经忘记了迭代目标，有的项目组外部的人可能不知道本次迭代的目标，通过重申迭代目标，让大家更加聚焦于目标来评审进展与功能的完成情况。
5. 要提前声明会议规则
为了确保迭代评审会议的成功，需要主持人事先声明会议规则，如：
- 提醒各位与会人员不要跑题
- 不要指责别人
- 提出一个问题的同时要给出一个建议的解决方案
- 不展示如何做的
- 不要在一个话题上花费太多时间
- 等等……（这里提示一点，最好让参会成员共同制定这个会议规则）
6. 不要在演示过程中讨论问题
为了保证演示人按照流程完整演示Demo，参会人员在演示过程中不可以互相讨论问题，如果有没看懂的步骤或流程，可以适当向演示人提问，但是不可以就流程和步骤进行讨论，如果觉得步骤和流程有问题的，可以先记到便签纸上，等演示完成后，集中讨论。
7. 对照Sprint Backlog演示完成的故事
本次迭代该完成的story都定义在Sprint Backlog中了，在演示时，应该对照本次迭代的Sprint Backlog进行演示，历史已经完成的story如果在本次迭代中没有修改可以不展示。
迭代评审会议是演示完成的需求，而不是解释完成的需求，要Demo，而不是仅仅宣称完成了哪些需求。
8. 演示的功能应该满足DoD
没有完成的功能，没有达到DoD标准的功能不演示，便于大家客观了解现状。
DoD是迭代计划会议上定义的故事或任务的完成标准，如：
- 开发完成
- PO认可
- 相关文档完成
- 集成完成
- 测试完成
- 等等……
DoD可以根据不同类的任务定义不同准则，比如如果某个任务是开发原型，则仅需要达到可演示的程度即可，而不追求可用或好用的目标。理论上DoD由团队共同制定，但同时也要参考公司的一些规章制度，比如必须通过Sonar的代码扫描，单测覆盖率必须达到多少比率等等。
如果迭代评审会议的时间充足，经过PO的认可，可以演示非完成的功能或原型，以便于获得其他利益相关方的反馈。
9. 利益相关方要反馈意见
与会的所有人员都可以反馈意见。项目组成员、PO、测试人员、客户、最终用户、高层管理者都应该积极反馈意见：
- 认可或不认可；
- 改进建议；
- 需求变更；
- 缺陷；
- 等等……
都可以。SM会前要准备好便签，方便大家记录问题，PO负责根据大家的反馈整理修订Product Backlog。
演示会上也可能发现程序的错误，会后要对这些错误进行原因分析，识别改进点。
10. 会议上不讨论如何解决问题，只讨论是否是问题
不讨论如何做的，只展示做成了什么样，应该做成什么样。聚焦于需求是否达到了客户的预期，而不是解决方案。有分歧的议题，难以短期内达成一致的议题，可以暂时搁置，另行开会讨论。不要在细节方面花费太多的时间，每个议题限制讨论的时间。
