最近，Innolution公司的执行总监、Essential Scrum的作者Ken Rubin在其公司博客上撰写了一篇题为It’s a Sprint Review Not a Sprint Demo!的博客，强烈呼吁大家不要把sprint评审会议（sprint review）当成跟sprint演示会议（sprint demo）一样的东西。北京敏捷社区的姜信宝（Bob Jiang）同学认为这篇文章非常不错，在征得Ken Rubin许可后，将本文翻译成中文并推荐至InfoQ中文站。以下为译文：

　　译者注：本文虽然是在辩解“sprint评审会议”和“sprint演示会议”的字面含义，但需要更深入了解其背后的原因，这其实才是作者的初衷。
（sprint评审会议=sprint review；sprint演示会议=sprint demo）

　　几乎每周我都会拜访一到两家公司，在现场讲授Scrum课程或者进行敏捷指导。最近，参加敏捷培训的人很可能在之前有一些Scrum经验或（通过书或视频）接触过Scrum——大多数情况下，这是件好事。

　　但我得吐吐槽。当人们把“sprint审查会议”实践当做“sprint演示会议”或只是“演示”的时候，我就会有所担忧。这看起来只是一个语法问题，然而把评审叫做演示的结果是，它破坏了sprint评审会议的真正目的。

　　尽管演示是sprint评审会议中很有用的一部分，但这不是评审会议的目的所在。sprint评审会议最重要的方面是参与者之间的深度交谈和协作，以及使产品知识浮现出来并进行开发。

　　已经构建好的内容演示，只是一种激发围绕具体事情交谈的、非常有效的方式。但其中没有谈到产品如何工作。

　　下图会澄清我是如何看待sprint评审会议活动。

　　

　　在图的中间，你会看到sprint评审会议图标。这个活动的关键是检视与调整sprint过程中产出的产品增量。这个图标的下边你会注意到一种举办sprint评审会议的方法。

　　第一步是回顾sprint目标和承诺的特性集，并和实际完成的情况进行对比。第二步是演示和讨论完成的特性，并对产品backlog或者发布计划做出必要的调整，以反应讨论中新的认知，然后重复这个步骤。这个循环直到讨论完所有完成的特性之后才结束。

　　在这个方法中，演示只是sprint评审会议中的一个活动，它不是sprint评审的目的。这就是为什么我认为这个很重要，应该叫sprint评审会议，而不是sprint演示会议。

　　再次重申，sprint评审会议的目标是检视与调整构建的产品。成功的评审结果是双向的信息流动。不属于Scrum团队的人也可以得知开发的成果并帮忙指出方向。

　　同时，Scrum团队成员通过频繁的反馈而加深了对产品的业务和市场认识。所以，sprint评审会议是一个检视和调整产品的预定机会。

　　应该叫做sprint评审会议，而不是sprint演示会议，对于这个观点，您同意吗？请留下您的建议。