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