1.Sprint 评审会议：不是让开发团队做成功“演讲”---会议上不一定要有PowerPoints 图片和文件，通常会议不会需要超过30分钟的准备时间，只是简单的展示工作结果，所有与会人员可以提出问题和建议。
2.在Sprint评审会议之后，开发团队会进行Sprint回顾会议。有些开发团队会跳过此过程，这是不适合的，因为它是使Scrum成功的重要方法之一。这是提供给开发团队的非常好的机会，来讨论什么方法能够起作用而什么不起作用，并一致通过改进的方法。Scrum开发团队，Product Owner和Scrum Master豆浆参加会议，会议由外部中立者主持；一个很好的方法是由Scrum master 互相主持对方的回顾会议，可以起到各团队间信息传播的作用。
3.敏捷回顾不是一场没有主题的讨论会，大家坐下来，七嘴八舌漫无目的一阵“乱弹”，这样的形式对于项目进展没有任何帮助。
4.Scrum回顾会议的过程：
1》在白板上写上主要主导原则；
2》在白板上画上一个至少三页纸连在一起长的时间轴。
3》在白板上写上我们的成功经验是什么。
4》在白板上写上“有什么能够改进”。
5》在白板上写上谁负责，然后分成两个区域---团队和公司。
5.Scrum回顾会议的最高指导原则。即“无论我们返现了什么，考虑到当时的已知情况，个人的技术水平和能力，可用的资源，以及手上的情况，我们理解并坚信：每个人对自己的工作都是全力以赴的”。
6.在项目过程中，处理问题越早，那么付出的代价与成本就越小。问题是，当我们在紧张的开发任务中，有时候很难发现这些错误，更加意识不到这些错误会带来的严重影响。通过回顾会议，利用团队成员互相善意的敲击对方，或者反复“锻炼”开发过程与方法，就能够让每一位成员都练就“火眼金睛”。
7.进行Scrum回顾时，发现问题仅仅是第一步，我们还要在回顾会议中合理分析这些问题出现的原因，所属分类，并因此划定问题的责任。我们要明确这些问题是团队内部的，还是由于外在因素导致的，指定处理人和处理时间。
8.在每个Sprint开始的时候，我们都必须要明确这个Sprint结束的时候需要演示的是哪些东西。很多时候，如果一个Scrum展开的不是很顺利，在Sprint演示的时候我们常常会听到这样的理由，“因为某些原因，这个功能我没有办法展示给你，但是这个功能是有了的，我只需要改动小小一点东西就可以了”。如果这样的话，这些理由到后期会泛滥成灾。我们所能做的，除了拒绝通过这些相关的 User Story 之外，在每个Sprint开始的时候还应该帮助团队了解到我们需要在Sprint演示会议上看到什么东西。强调我们重视的是可交付的版本，而不是一个口头上的更能增加。
