Sprint Review不是回顾，其目标是演示这个Sprint中自己的工作成果，参会人员包括设计师、开发人员和Product Owner。在Worktile，我们尽量保持Sprint评审会的轻松随意氛围。团队成员们会聚集在桌子周围进行非正式的演示，讲述自己在本次迭代中完成的工作。在这期间团队成员可以相互提问、尝试新的功能并提供反馈。成功的分享是构建敏捷团队的重要工作。
首先，我们回顾一下为什么团队对“完成”的定义对Sprint review如此重要：
第一步：定义“完成”如果你在使用敏捷开发工具，那么你就应该清楚将任务卡从“测试中”拖到“已验收”这个操作会令你非常有成就感。这个任务卡的流转代表着一项工作终于完成了！
在截止时间前完成工作需要合理的规划、定义清晰的“完成”和专注的执行力。虽然大多情况下，这些工作是在Sprint规划阶段要做的事，但为了确保Sprint和review能顺利进行，团队要做的远不止规划，还要形成一种清晰的交付文化以及明确“完成”的定义。
交付文化高效团队能够将清晰的流程和开发文化带到每个工作项中。你可以用下面这些问题来评估一下你的流程，确保该流程能让团队保持最佳状态：
实施前，Product Owner、设计师和研发团队对用户故事的定义是否明确？
每个人是否都理解并践行团队的工程价值观和文化？
关于代码审查、自动化测试和持续集成是否有明确的定义和需求来鼓励可持续的敏捷开发？
团队每完成一个用户故事，是否会有很多bug？ 换句话说，“完成”是否真的意味着“完成”呢？
团队的质量和完成文化应该在每个用户故事、工程工作项和bug之上。这种文化反映了团队交付软件的方式。
为每个工作项定义“完成”明确 “完成”的定义可以帮团队聚焦每个工作项的最终目标。当Product Owner在团队的backlog中添加工作时，定义验收标准是他工作流程中非常关键的一部分。用户故事的完成意味着什么？在Worktile，团队也会跟踪其他用户故事的验收标准和测试说明。这样，整个团队就能够明确掌握每个工作项的完工情况。那么什么是验收标准和测试说明呢？
验收标准：Product Owner用于确认故事已满足其需求的指标。
测试说明：来自质量支持团队的简短、有针对性的指导，可帮助开发工程师编写更好的功能代码进行自动化测试。
定义明确的事项在实施过程中更容易成功。通过使用Worktile，团队可以轻松添加字段及描述，让每个任务都有清晰的定义。
第二步：庆祝团队成果
Sprint review是庆祝团队和个人在迭代过程中所取得成就的好时机。所以在Worktile，我们通常在周五下午进行Sprint review。Sprint review并不是回顾的同义词，所以要确保在迭代完成之后，回顾之前举行Sprint review会议。虽然我们欢迎外部人员加入会议，但通常情况下是Product Owner、整个开发团队和Scrum master参与会议。为了取得最佳效果，建议每个迭代花费30分钟到1小时的时间。
我们喜欢Sprint review，因为它可以保证团队的健康和士气。Sprint review的核心目标就是团队建设。review并不是对抗，也不是考试——而是整个团队的协作活动，让成员可以展示自己的工作，现场交流并获得反馈。
如果Sprint review没能在团队中产生积极影响，原因可能是：
团队任务太多以至于迭代期间无法完成；
团队深陷现存的技术债；
功能开发未能确保持续性，以避免在代码库中引入新的bug；
团队的开发习惯没有适时调整；
Product Owner在迭代过程中更改了优先级，而开发团队则因范围的变更陷入困境；
注意：团队在迭代中遇到困难是常有的事。迭代回顾会议时，团队可以花费点时间探讨一下为什么迭代过程中会发生变更，并制定计划在下一个Sprint中解决问题。
最后建议对于那些不熟悉sprint review的团队来说，它们很容易就将其并入sprint回顾会议。Sprint review是独立于sprint回顾会议之外的独立仪式。通过sprint review，我们可以花点时间享受工作成果、自由地庆祝成就。有效的sprint review可以增强团队的士气和动力。