Sprint评审
在Sprint结束后，将进行Sprint评审，团队在此期间展示他们所构造的产品。出席此会议的有产品所有者，开发团队成员，ScrumMaster，加上客户，项目管理者，专家，高层人士和任何对此感兴趣的人。会议时间不长，目的只是对工作结果的展示和听取反馈。
Sprint回顾
在Sprint评审之后，开发团队会进行Sprint回顾。有些开发团队会跳过此过程，这是不合适的。因为它是Scrum使潜在的改进可视的重要技巧，并可以将其转化为结果。这是提供给开发团队的非常好的机会，来讨论什么方法能起作用而什么不起作用，并一致通过改进的方法。Scrum开发团队，产品所有者和ScrumMaster都将参加会议，会议由外部中立者主持；一个很好的方法是由ScrumMaster互相主持对方的回顾会议，可以起到各团队间信息传播的作用。组织Sprint回顾的最简单方法是在白板上画两个栏，分别注明“哪些项工作顺利”，“哪些项可以做得更好”，让与会者在每一类别下增加些项目。当项目重复2，可以在该项旁边记正字累计，这样一些比较普遍出现的项目就一目了然了。然后团队成员共同讨论找寻这些项目出现的根本原因，统一在下一个Sprint中的改进计划，并负责在下一个Sprint回顾会议上评审项目结果。一个非常实用的方法是在回顾的尾声，让团队成员在每一类下的项目中，用”C”标记如果其根源是Scrum，或用“E”标记如果其是由Scrum显现出来的（换句话说，无论Scrum存在与否该项目都会发生，但是Scrum使开发团队注意到了该项目的产生）。或用”U”表示，如果其产生与Scrum无关（如天气情况）。开发团队会在“哪些项目工作顺利”下发现许多的C标记，在“哪些项目不成功”下有许多的E标记，这是个非常好的现象，即使“哪些项目不成功”是比较长的列表，因为解决问题根本原因的第一步就是让其显现出来，Scrum正是此作用的强有力的促进因素。