http://www.cnblogs.com/enze/archive/2012/08/13/2635679.html
1.评审会(Review Meeting)
a.小组向产品经理展示迭代成果。
b.产品经理给出产品的评价和反馈。
c.以用户故事是否能成功交付来评价任务完成情况。
怎样展开评审会？
答：敏捷开发采用时间盒(Time Boxing)的方法，即限定时间而不限定范围。所以迭代不会延期，因为在迭代终点将放弃未完成的故事。
评审标准是什么？
答：整个故事是否已经达到交付标准，而不是从其中分解出来的任务完成了多少，因此若一个故事"差一点就完成了"，这种情况属于未完成。
分析说明:
常常发生很多故事都已经开始开发了，但都差一点完成的现象。因此应按迭代内的优先级逐条开发和交付故事。
一般总是优先开发MoSCoW方法中必须完成和应该完成的故事，再考虑其他可以完成的故事。
一般在迭代计划会上设定每个故事的完成标准，如是否需要测试、是否需要考虑性能、是否需要说明文档等等。
这些标准一般由项目组提前设定好。尽管有正式的评审会，但很多团队还是习惯于在单个故事完成时，就让产品负责人进行单个故事的评审，以确保交付时不会有"惊喜"。
评审会上发现的问题或改进将被累积到产品待开发项，也不会马上或在下一个迭代中马上开发，而是由优先级排序决定啥时开发。
2.反思会(Retrospective Meeting)
a.在每个迭代结束后，会召开简短的反思会。
b.总结团队在开发中哪些做的好，哪些做的不好，总结经验。
c.指定改进计划
怎样展开反思会？
答：一般在反思会上讨论三个问题：我们在上个迭代中哪些事情做的好？哪些做的不好。好的继续保持，不好的希望改进，有何改进计划。
分析说明:
经常出现一些问题多次被提到，但却始终没有解决，应该每次仅就1~3个关键问题作出可行的解决方案，在下一个迭代中执行改进。
"可行"的概念包括两个含义:a.方法简单、影响范围小、见效快；b.目标不要激进，而要显示可行、积少成多。
如果必要可以执行领导回避制度，即具有管理职能的人不参加反思会，即使这些人是产品负责人、项目经理、甚至是Scrum Master。