迭代开发和回顾活动中的努力表达欣赏和感谢，根据情况可以让大家做Checkout表达心情和收获。
一些TIPS
不同项目情况的回顾关注点
一次性的项目（项目结束后团队解散）：从做的好的和不好的点，总结相关的经验，关注每个人的成长和收获，大家在其他项目中可以做的更好。
新成立的项目，大家摩拳擦掌准备大干一场的：关注项目成员的配合协作、项目流程完善、统一的规范（可以包括统一的编程规范、沟通方式等），关注改进点；
项目问题比较多，士气不高的团队：关注团队的进度、发现优点，激励士气为主，同时不断从最核心的两三条改进开始；
成熟团队，经历了长期合作的：团队资产的不断积累、精益求精：包括团队的技术积累（模块的架构提升、代码亮点、经验库建设等），和业界标杆、周边优秀团队的差异对比等。
什么情况下一定要做回顾
项目很重要，大家觉得需要特别谨慎，或者以后能够提高做重要事情的胜率，建议做一次深回顾。
做全新事情的项目，之前从来没有做过，可以通过回顾找新的规律，以后遇到类似的事情，可以更好的处理。
某件事情未达到预期，可以通过回顾看看到底没有达到预期的原因是什么，是哪一方面存在不足，需要改进，一定要做回顾。
对于认为有学习价值的事情，我们也可以进行回顾，以获取新的经验。
对回顾会引导师或主持人的建议
回顾会是一种团队学习机制，如何营造一个安全的空间，鼓励每个人说出故事，让每个人都发言，对激发团队共创，促进整体的提高和协同很重要；
回顾会不同于个人工作总结，建议设计或按照一定的结构化流程配合引导的方式进行，并且事先一定要做认真准备，确保整个过程达到预期效果；
回顾会需要引导大家的关注重点不在于产出好不好，重点是从过程中学到经验和教训，找到未来可以改进的地方，以学习和共创为导向；
使用便签可以引发每个人独立思考和参与，配合可视化墙可以让大家看到不同人的不同视角以及整个团队Whole Picture更容易达成共识和理解；
有时候在过程中增加"感谢或欣赏"环节有利于各角色建立信任和理解，潜移默化提升团队凝聚力；
数据收集相关内容在启动前事先做一定准备，特别是需要量化数据的内容的时候；
回顾会最终要引导大家落实到可执行的行动计划上，改进项不需要很多，选择优先级最高TOP3~5投入产出最大的改进项落实到计划；
改进项职责分配时引导大家主动选择愿意接下来去推进改进的事项，改进事项的Owner建议引导大家自愿选择承担，必要情况下进行分配；
建立一种可以激发大家自动同步行动计划落实的机制或设置检查点和检查方式，比如建立卡片纳入迭代backlog，同迭代一起贴在看板，每天同步进展，确保行动计划有效执行和落地实施。
一些可参考的改进类型和方向：
技术改进：比如技术架构的可复用性、可拓展性的提升，模块间解耦、老代码技术债务等优化从而提升效率；
工具改进：比如采用新的自动化测试工具和平台、引入DevOps工具链打通自动化交付流水线、引入看板工具提升过程透明性等；
管理改进：比如多团队协同的端到端全价值流协同机制、跨团队不同层级的沟通机制、基于产品整体视角需求管理和优先级排序机制、风险和问题管理升级机制、团队人员成长及横向能力建设机制等；
参考书籍
敏捷回顾：团队从优秀到卓越之道
复盘+：把经验转化为能力
