Sprint 评审
    在Sprint 结束后，将进行Sprint 评审，团队在此期间展示他们所构造的产品。出席此会议的有产品所有者，开发团队成员，ScrumMaster，加上客户，项目管理者，专家，高层人士和任何对此感兴趣的人。这不是开发团队做成果“演讲”——会议上不会有PowerPoints 图片文件，通常会议不会需要超过30 分钟的准备时间——这只是简单的展示工作结果，所有与会人员可以提出问题和建议。会议可以持续10 分钟，也可以是两个小时——会议目的只是对工作结果的展示和听取反馈。

    Sprint 回顾
    在Sprint 评审之后,开发团队会进行Sprint 回顾。有些开发团队会跳过此过程, 这是不合适的, 因为它是使Scrum 成功的重要方法之一。这是提供给开发团队的非常好的机会，来讨论什么方法能起作用而什么不起作用，并一致通过改进的方法。Scrum 开发团队，产品所有者和ScrumMaster 都将参加会议，会议由外部中立者主持；一个很好的方法是由ScrumMaster 互相主持对方的回顾会议，可以起到各团队间信息传播的作用。 组织Sprint 回顾的最简单方法是在墙上挂两张张贴画大小的白板纸，纸上注明“哪些项工作顺利”，“哪些项不成功或者哪些项可以做的更好”——让与会者在每一类别下增加些项目。当项目重复时，可以在该项旁边记正字累计，这样一些比较普遍出现的项目就一目了然了。然后团队成员共同讨论找寻这些项目出现的根本原因，同意在下一个Sprint 中的改进计划，并负责在下一个Sprint 回顾会议上评审项目结果。另一种方法是让团队成员在每一类下的项目中，用“C”标记如果其根源是Scrum，或用“V”标记如果其是由Scrum 显现出来的（换句话说，无论Scrum 存在与否该项目都会发生，但是Scrum 使开发团队注意到了该项目的产生）。开发团队会在“哪些项目工作顺利”下发现许多的C 标记，在“哪些项目不成功”下有许多的V 标记；这是个非常好的现象，即使“哪些项目不成功“是比较长的列表，因为解决问题根本原因的第一步就是让其显现出来，Scrum 正是此作用的强有力的促进因素。

    开始下一个Sprint
    在Sprint 评审会议之后，产品所有者将提取所有建议，和在Sprint 中产生的新的优先权项目，并将这些项目合并于Product Backlog 之中；增加新的项目，现有项目进行了更改，重新排序或删除。当Product Backlog 的更新完毕，循环周期可以再次开始，以下一个Sprint 计划会议为开端。
    许多开发团队感觉在每个Sprint 末期进行优先化的会议很有意义，和产品所有者一起对下一
Sprint 中的Product Backlog 项目进行评审。除了给开发团队的一个机会提醒产品所有者其未注意的事项——技术维护，比如——此会议也开始了在Sprint 计划会议之前所需的初步想法。 在各Sprint 之间没有间隔期——开发团队通常在下午时间进行了Sprint 评审，第二天上午就进行下一Sprint 计划会议。Agile 开发的价值观之一是“可持续性“，只有在正常的工作时间和劳动强度下，开发团队才可以继续此周期的持续。

    产品发布计划
    Sprint 持续直至产品所有者决定产品已经可以准备发布，此时会有“发布Sprint“来进行最后的整合和发布产品前的检测。如果开发团队一直贯彻很好的开发方法，不断地重构和持续集成， 在每一Sprint 中的有效测试，就不会存在许多遗留问题需要清除。 有这样一个问题有时会被提到，是怎样在一个迭代的模式中产生长期的发布计划。在一个项目的起始阶段，开发团队会作出粗线条的发布计划；他们不可能预先得知工作的结果，其重点是创建一个大体的计划提供给项目发展一个大体的方向，并阐明交易决策如何形成（比如范围相对于进度表）。以此作为路标来指引你向目标迈进；在行程中你实际挑选的路程和所做的决策都是途中决定的。
    有一些产品发布是以日期界定的；比如：“我们会在11 月10 日的产品展示会上发布我们项目的2.0 版。“在此种情况下，开发团队会在现有的可利用时间内完成尽可能多的Sprint（构建尽可能多的功能）。有些产品要求某部分构建完成才可以说明整个产品的完成，产品不会在这些要求满足前被发布，无论周期长短。Scrum 强调在每一Sprint 中都生产出可以随时交付的编码，开发团队可以进行中间的发布，使客户可以更快的收到产品的效益。 大多数产品所有者会选择一个发布方式，但是会通知其他的——比如，他们会决定发布日期， 他们会与开发团队成员一起对Backlog 中项目的完成日期做一大体的估算。在“固定价格/固定日期/固定交货期”的情况下——比如，合同制开发——在这些变量中至少有一个内部存在缓冲区，可以容许不确定因素和变更；在此方面，Scrum 于其他的开发方法并无区别。

    普遍存在的挑战
    Scrum 试图让许多存在于开发团队中的问题显现出来，特别是在开发的前期。比如，大多数的开发团队并不擅长于估算在固定期间内完成的工作量，因此在第一个Sprint 结束时不可能交付他们预计完成的工作。对于开发团队来说，这个是工作的失败，可能会导致他们对采用Scrum 方法的质疑。事实上，这个经验正是能更好预计工作量所需的第一步，在经验丰富的Scrum 实践者的帮助下，开发团队可以正确地认识到这一点。开发团队可能会遇到的另一个难题是每日（站立）例会——让开发团队的每一个成员承诺在特定的时间参加会议，准时并且每日参加， 这就需要开发团队比通常有更高的要求，有些团队可能达不到此标准。
    一个开发团队普遍犯的错误是，当他们在Scrum 实践中遇到挑战，他们会改变实践方法，而不是改变自身的问题。比如，开发团队有困难完成Sprint 任务时，会延长Sprint 的周期，这样他们就会有充足的时间完成任务——在流程中，确保自身不用提高工作预测的技能和更好的管理时间。这样，在没有经验丰富的Scrum 培训师的指导下，开发团队只会将Scrum 作为自身弱点和机能失调的映射，并破坏了Scrum 真正的意义：使优点和缺点都显现出来，给开发团队自我的提高提供机会。
    另一个普遍存在的错误是，人们以为某一实践方法是被禁止或不提倡的，只是因为Scrum 没有明确的提出此方法。比如，Scrum 并不特别要求产品所有者对于他或她的产品作出长远的目标计划；也没有要求工程师请教更有经验的人员（比如，他们的经理）关于比较复杂的技术问题。Scrum 将这些问题留给个人作出正确的处理；在很多情况下，以上两个方法（和其他许多的方法）会被建议。做个正确的比喻：“因为Scrum 没有提到早餐的问题，并不意味着你就得挨饿！”
    另一个需要留意的问题是有时经理会强制开发团队使用Scrum；Scrum 是为开发团队提供自我组织的空间和工具，由上层强加于开发团队恐怕不是取得成功的良方。比较好的方法是让开发团队从同辈或经理处了解到Scrum，并通过专业系统的培训，在开发团队实验此方法（比如90
天）后作出决定；在实验周期后，开发团队通过经验的总结来决定是否继续采用此方法。
    在第一个Sprint 之后，结果往往会对开发团队产生很大的挑战，采用Scrum 的好处也会在其尾声显现出来，使得许多新的Scrum 团队宣称：“Scrum 是困难的，但是它比我们以前采用的方法要好许多！”

    Scrum 的成果
    Scrum 产生的收益在开发团队经验中体现在不同的方面。在Yahoo!公司，在上18 个月中我们将近50 个开发项目采用Scrum，一共近600 人参与，采用Scrum 的团队数量在快速发展。这些项目从客户界面，网页设计如Yahoo! Photos, 到后端基础构造服务如服务上百万客户的Yahoo! Mail；从全新的产品如Yahoo! Podcasts，其利用Scrum 作为从构思到发布的流程（并获得该年度同类产品的Webby 奖），到一些增量的项目，包括开发新的部件并维修bug 和其他的维护工作；我们也利用Scrum 来分配分布式项目。每一个季度，我们对Yahoo!公司每一位Scrum 的使用者进行调查（包括产品所有者，开发团队成员，ScrumMaster 和这些人员的经理），并让他们将Scrum 于以前的开发方式做一对比。我们正在准备Yahoo!公司的深入调查报告，以下是相关的资料显示：
    · 生产效率：68%回复显示采用Scrum 后生产效率提高（4 分或5 分在以5 分为衡量标准上）；5%显示采用Scrum 后生产效率降低（1 分或2 分在以5 分为衡量标准上）；27% 显示采用Scrum 后无变化（3 分在以5 分为衡量标准上）。
    · 团队精神：52%回复显示采用Scrum 后团队精神加强；9%显示采用Scrum 后团队精神减弱；39%显示采用Scrum 后无变化。
    · 适应性：63%回复显示采用Scrum 后适应性加强；4%显示采用Scrum 后适应性减弱；33%显示采用Scrum 后无变化。
    · 责任性：62%回复显示采用Scrum 后责任性加强；6%显示采用Scrum 后责任性减弱；32%显示采用Scrum 后无变化。
    · 协作能力：81%回复显示采用Scrum 后协作能力加强；1%显示采用Scrum 后协作能力减弱；18%显示采用Scrum 后无变化。
    · 在产品所有者估算下，开发团队的生产效率平均提高了36%
    · 85%的开发团队成员表示如果其拥有决策权的前提下，将会继续使用Scrum。