Sprint评审会议长期以来一直是Scrum的一个很重要的部分，它是团队为迭代交付的产品增量获得反馈的一种机制。在Sprint评审会议上，产品负责人根据收到的反馈来决定接下来的Sprint的需求的优先级。
那么，到现在Sprint评审是否已经过时了呢？
十年前，差不多每个Scrum团队都是按照Sprint，Sprint，Sprint，Release（发布）这样的模式交付的，每个做几个迭代上线一次，极端情况是每个迭代都上线，很少听说在Sprint中间发布上线。
而现在，很多团队都在实践持续交付和持续发布，一天发布多次也是很普遍的。
我们设想一下，针对一个进行持续发布的团队，我们按照原来的思路进行Sprint Review的场景：
如果他们每天发布多次，他们让产品负责人和干系人在迭代结束的时候针对他们已经交付给真实用户的特性给一些反馈，那么干系人会说：“嗯，那么我们的用户是怎么看待这些特性的呢？”。如果团队是在迭代中间完成之后就发布产品Backlog条目的情况，标准的Sprint评审会议评审的是已经发布，并且用户已经使用过的特性，评审会议实际价值较小。
我辅导过一些团队进行一次一个特性的评审。具体的模式是这样的，团队中的一个或两个成员和提出需求的干系人一起碰一下，有必要的话也可以叫上PO, 他们向干系人演示做好的这个特性，收集干系人关于这个特性的反馈，然后决定是发布这个特性或者是做一些必要的调整。和标准的Sprint评审不同，原来是一次评审一大批产品Backlog条目，现在是团队内的小组根据需要在迭代中间做了多轮一次一个特性的即时评审。
但是，即使是这种情况，传统的在迭代末进行的Sprint评审仍有价值。评审会的主要目的是获得反馈，但是它还有一个附加价值，干系人全身心参与可以更好的学习和了解产品。进行一次一个特性评审的团队也可以考虑进行正式的Sprint评审，它是让所有干系人学习和了解Sprint发布内容的非常好的方式。
不是所有的团队都合适一次一个的特性评审方式，比如，如果你的团队交付的是一年发布一次的物理产品，一个传统风格的Sprint的评审仍然是最好的选择。如果你的团队大部分情况是一个迭代发布多次，考虑转换成一次只评审一个特性的方式以更好地取得敏捷的成功。
译者：
Eric Liao 廖靖斌，国内知名敏捷教练、顾问、培训师
原文作者：
Mike Cohn
