敏捷之路：如何开好迭代评审会

一、目标：

根据团队这次Sprint所发布的版本，评审相关的Backlog中的问题，检查是否已达到Sprint的目标。

1、验证产品是用户所想要的

2、讨论接下来的features是什么样子

3、获得客户认同和信任

4、迫使可交付的产品准备完毕

注意：最后一点常常被忽略。有时Sprint评审会被误以为是另一个演讲机会。“看看我们做了多少伟大的工作，然后就开始讲PPT”这不是客户或stakeholder希望看到的。他们想看真正的产品!

二、参会人员：

产品经理、Product Owner、Scrum Master、团队所有成员，并且要让客户参与进来。

三、会议时长：

1-4小时，视演示内容而定。

四、输入、输出成果：

输入：Sprint Backlog, Working Software

演示的内容：本次迭代的需求，修改的重大bug

输出：产品 Backlog，阻碍 Backlog，发布燃尽图

五、会议准备：

1、对于每个人来说Sprint目标都是公开的。

2、对没个人来说既定产品Backlog是公开的，可获取的。

3、小组准备好工作站和设备等等，用以展示产品的新功能。

4、所有的利益相关者（投资者，客户等）都要被邀请参加。

六、会议进程：

1、团队按Backlog中的问题，逐个地介绍这次Sprint的结果，和演示新功能。

2、产品负责人给出评价和反馈。

3、如果产品负责人想要改变功能：添加一个新问题到产品Backlog中。

4、如果对功能有一个新的想法：添加一个新问题到产品Backlog中。

5、如果小组报告项目遇到阻碍现在还没有解决：把该障碍加入到障碍Backlog。

6、每个Sprint结束都要有demo。

7、只有完成的用户故事才演示，Demo要演示可以工作的功能。

8、Demo过程中要收集利益相关者的一些反馈。

9、Demo开始的时候要介绍一下原始的Sprint计划。

10、以用户故事是否能成功交付来评价任务完成情况。

七、优秀的迭代评审应做到如下几点：

1、集中精力展示产品；

2、保持功能陈述的简单和简短；

3、尽可能避免使用ppt，而是使用短剧或其他有创意的带有互动性的方式；

4、使用团队的系统(例如电子看板系统)展示计划的工作；

5、提前为会议做些许准备；

6、让客户或其他干系人参与进来；

有了一个很棒的Sprint评审和许多积极的反馈以后，是时候把这些积极的能量带到Sprint回顾会中了。

八、注意事项：

1、整个故事是否已经达到交付标准，而不是从其中分解出来的任务完成了多少，因此若一个故事"差一点就完成了"，这种情况属于未完成。

2、常常发生很多故事都已经开始开发了，但都差一点完成的现象。因此应按迭代内的优先级逐条开发和交付故事。

3、一般总是优先开发MoSCoW方法中必须完成和应该完成的故事，再考虑其他可以完成的故事。

4、一般在迭代计划会上设定每个故事的完成标准，如是否需要测试、是否需要考虑性能、是否需要说明文档等等。这些标准一般由项目组提前设定好。尽管有正式的评审会，但很多团队还是习惯于在单个故事完成时，就让产品负责人进行单个故事的评审，以确保交付时不会有"惊喜"。

5、评审会上发现的问题或改进将被累积到产品待开发项，也不会马上或在下一个迭代中马上开发，而是由优先级排序决定什么时候开发。