题，我们可以限时让他们讨论出问题的根源和推荐出改进计划，这样我们一个能节省时间，更有价值的是可以调动每一个成员的积极参与度。
SMART的改进计划
一个老调重弹的就是所有的改进计划都必须是SMART的，SMART原则也不介绍了。这点说得容易，但做起来往往困难很大，大家非常容易产出一些类似建议一样的东西，完全没办法执行。这里给大家一个小窍门，在每产出一个action的时候就问一下大家“这个action可以执行吗？能判断是否完成吗？”，这样往往就能帮忙准确判断是否SMART。
避免产出过多改进计划
当然还有一个陷阱就是改进计划过多，到时候团队根本没有时间完成这么多的改进计划，这个也需要排优先级；还有超出团队能力范围的改进要避免，不然也没法落实。
2.5 结束会议
结束会议如果有必要的话我们可以简单对本次会议的组织做个总结建议，可以帮助我们提高下次回顾会议的组织能力。
但我最喜欢的结束会议的方式是让大家每个人通过一张纸片的形式感谢团队里的一个人，并附上理由。我觉得这是一个很好的激励团队更多合作和相互帮助的好办法。写好纸片之后，我会请大家当众宣读一下卡片内容，并亲手交给自己感谢的人，纸片格式如下：
三、提供几个需要注意的地方
一般情况不建议团队的经理参加回顾会议。这有悖于准备环节中提到的设立一个安全的环境，大家会担心在会议上暴露团队问题会对他们绩效产生不好的影响。但也有一种情况我们需要经理在场，那就是团队已经积累了很多非常严重的问题，但是经理可能都不大了解情况，大家都期盼的经理在场能听到并推动解决这些问题。
会议产生的改进计划怎么有效地跟踪？一般我们建议把这些action之间放到团队下个迭代的工作列表中，和普通开发工作一样对待跟踪，只有这样才能有效地使得改进落地。
前后回顾会议产出相同或类似的改进计划。这说明老问题一直没有解决，有的时候会发现每次改进计划都完成了，但是老问题仍然还在。一般如果想改进能力或是外部依赖的问题往往会导致这样的情况，这些不像团队自己的流程那样能立竿见影，面对这样的问题，团队最好能计划一些长期的（周期跨迭代的）改进计划，下次回顾会议可以监控进展，而不是提重复的问题。
如果需要，别忘了在回顾会议前面简单过一下上次回顾会议产出的改进计划完成情况。
