团队在Sprint快结束时举行Sprint评审会议，目的是检视所交付的产品增量并按需调整产品的Backlog。团队经常误以为Sprint评审是邀请很多人（包括领导）参加的一个很正式的评审会议，需要走正规的评审流程，于是为了评审顺利而做了大量的准备工作。

实际上，Sprint评审是一个非正式会议，并不是一个进度汇报会议，目的是为了获取产品的反馈。因此，我个人比较喜欢Sprint评审会议的另一个叫法：SprintDemo，或者很多公司称其为ShowCase。SprintDemo是对产品进行检查与调整的反馈环。SprintDemo可以让产品的每个利益干系人清楚地看到产品当前的进展，也许会超出预期，也许会大大低于预期。但不论是让人惊喜还是沮丧，都给大家看到了产品进展的真相。

SprintDemo会议召开的时间是在Sprint结束、Sprint回顾会议之前，参会人有团队、产品负责人、产品的利益干系人（包括客户、投资人、用户代表等）。

SprintDemo的流程很简单：团队一一演示这个Sprint交付的用户故事，听取与会人的意见。但是有很多团队没有达到SprintDemo应该实现的意义。

在瀑布的开发方式里，产品的利益干系人习惯于等到最后产品上市的时候才看到产品，然后提出改进意见。所以，团队刚开始转型的时候，利益干系人还不习惯每个Sprint都来参会，导致经常只有产品负责人参加团队的SprintDemo会议。

在这种情况，ScrumMaster需要做一些布道的工作，给利益干系人介绍Scrum的流程，以及大家到SprintDemo会上来的意义是什么。第一次参会后，当利益干系人真实地看到每个Sprint团队都可以交付出可用的产品后，就会爱上Demo这个习惯。

有的团队为了Demo演示顺利，在会前1分钟还在编写代码。开会时间一到，大家急匆匆地跑到会议室来，当着各产品利益干系人的面现场打开投影仪，启动电脑，启动演示环境。结果，服务器挂了……现场捣鼓了20分钟后才开始演示。

在SprintDemo会前1小时，ScrumMaster要跟团队协商，谁来做Demo，要做Demo的同事提前进入会场，将一切准备就绪。一般来说，由参与用户故事开发和测试的同事来演示自己参与的用户故事会让他们很有成就感。

在有些团队的SprintDemo会上，ScrumMaster打开一个PPT文档，列出了这个Sprint团队完成了哪些用户故事、哪些任务，以及由谁完成的，技术上采取什么方案来实现等，然而，团队却没有可工作的软件。

这样的SprintDemo不是对产品的演示，而是Sprint汇报总结。这对产品负责人、客户以及用户没有意义，Demo是产品的反馈环，本着收集大家对产品的意见为目标。

在一些团队的SprintDemo会上，产品负责人经常现场否定团队Demo的用户故事，这会让团队感觉沮丧。file:///C:\Users\19805\AppData\Local\Temp\ksohtml\wpsE0B5.tmp.png

其实团队不是一定要等到SprintDemo的时候才可以请产品负责人来验收Sprint成果。团队完全可以在Sprint执行过程中，每做完一个用户故事就及时找产品负责人验收。这样做的话，如果有问题还有时间改，不至于等到SprintDemo会上才被产品负责人否定。

SprintDemo就只是演示，没有利益干系人体验产品的环节。

SprintDemo除了自己演示Sprint成果之外，最好让参会者自己体验产品。因为看别人操作和自己亲身操作的感受是不一样的，所以请利益干系人亲自体验产品，会得到更真实的反馈。

对于产品负责人来说，做产品验收一定要亲自体验团队的开发成果，因为你的使用路径未必是团队给你演示的常规路径。如果参加SprintDemo会议的有用户代表，这正好是现场开展用户测试的好时候。

问：修复的Bug也要演示吗？

答：如果有利益干系人关心的与重要价值产出相关的Bug可以演示，其他Bug无需演示。

问：有的工作对用户不可见，怎么演示呢？

答：这个问题要仔细看，是哪些工作对用户不可见。总的来说，不可见的工作有以下几类。

1.貌似不可见，其实可见

在一个团队SprintBacklog里，有一个用户故事是：提升性能，10万并发用户同时操作，页面响应在1秒钟之内。

在SprintDemo会上，团队认为，现在没有这么多用户，没办法演示。我问团队：“这个测试过吗？”团队说：“模拟测试通过了。”我问团队：“那有测试报告吗？”团队答：“当然有了。”

在这样的情况下，测试报告本身就可以Demo，证明这个故事已经达成目标。

2.技术改进类工作，确实不可见

比如，团队为了能够让特性独立发布，做了架构解耦的工作。但是，架构解耦对用户确实不可见。怎么办呢？

如果团队Demo新的架构设计，或者架构评审意见，参会者未必看得懂。即使看得懂，他们也不会在会上评审架构。所以团队还不如直接告诉与会者：我们做了架构解耦的工作，能够达到什么效果。

3.交付的东西不足以产生价值

一个团队的某个用户故事描述为：后台报表修改×××字段。如果这个用户故事本身不直接产生用户价值，而是需要与前台集成后才产生价值，那么这个问题就不是如何Demo的问题，而是用户故事的拆分方式问题。团队要从价值的角度拆分用户故事，贯穿前端、后端，使其对客户和用户产生价值。

团队在Sprint快结束时举行Sprint评审会议，目的是检视所交付的产品增量并按需调整产品的Backlog。团队经常误以为Sprint评审是邀请很多人（包括领导）参加的一个很正式的评审会议，需要走正规的评审流程，于是为了评审顺利而做了大量的准备工作。

实际上，Sprint评审是一个非正式会议，并不是一个进度汇报会议，目的是为了获取产品的反馈。因此，我个人比较喜欢Sprint评审会议的另一个叫法：SprintDemo，或者很多公司称其为ShowCase。SprintDemo是对产品进行检查与调整的反馈环。SprintDemo可以让产品的每个利益干系人清楚地看到产品当前的进展，也许会超出预期，也许会大大低于预期。但不论是让人惊喜还是沮丧，都给大家看到了产品进展的真相。

SprintDemo会议召开的时间是在Sprint结束、Sprint回顾会议之前，参会人有团队、产品负责人、产品的利益干系人（包括客户、投资人、用户代表等）。

SprintDemo的流程很简单：团队一一演示这个Sprint交付的用户故事，听取与会人的意见。但是有很多团队没有达到SprintDemo应该实现的意义。

在瀑布的开发方式里，产品的利益干系人习惯于等到最后产品上市的时候才看到产品，然后提出改进意见。所以，团队刚开始转型的时候，利益干系人还不习惯每个Sprint都来参会，导致经常只有产品负责人参加团队的SprintDemo会议。

在这种情况，ScrumMaster需要做一些布道的工作，给利益干系人介绍Scrum的流程，以及大家到SprintDemo会上来的意义是什么。第一次参会后，当利益干系人真实地看到每个Sprint团队都可以交付出可用的产品后，就会爱上Demo这个习惯。

有的团队为了Demo演示顺利，在会前1分钟还在编写代码。开会时间一到，大家急匆匆地跑到会议室来，当着各产品利益干系人的面现场打开投影仪，启动电脑，启动演示环境。结果，服务器挂了……现场捣鼓了20分钟后才开始演示。

在SprintDemo会前1小时，ScrumMaster要跟团队协商，谁来做Demo，要做Demo的同事提前进入会场，将一切准备就绪。一般来说，由参与用户故事开发和测试的同事来演示自己参与的用户故事会让他们很有成就感。

在有些团队的SprintDemo会上，ScrumMaster打开一个PPT文档，列出了这个Sprint团队完成了哪些用户故事、哪些任务，以及由谁完成的，技术上采取什么方案来实现等，然而，团队却没有可工作的软件。

这样的SprintDemo不是对产品的演示，而是Sprint汇报总结。这对产品负责人、客户以及用户没有意义，Demo是产品的反馈环，本着收集大家对产品的意见为目标。

在一些团队的SprintDemo会上，产品负责人经常现场否定团队Demo的用户故事，这会让团队感觉沮丧。file:///C:\Users\19805\AppData\Local\Temp\ksohtml\wpsE0B5.tmp.png

其实团队不是一定要等到SprintDemo的时候才可以请产品负责人来验收Sprint成果。团队完全可以在Sprint执行过程中，每做完一个用户故事就及时找产品负责人验收。这样做的话，如果有问题还有时间改，不至于等到SprintDemo会上才被产品负责人否定。

SprintDemo就只是演示，没有利益干系人体验产品的环节。

SprintDemo除了自己演示Sprint成果之外，最好让参会者自己体验产品。因为看别人操作和自己亲身操作的感受是不一样的，所以请利益干系人亲自体验产品，会得到更真实的反馈。

对于产品负责人来说，做产品验收一定要亲自体验团队的开发成果，因为你的使用路径未必是团队给你演示的常规路径。如果参加SprintDemo会议的有用户代表，这正好是现场开展用户测试的好时候。

问：修复的Bug也要演示吗？

答：如果有利益干系人关心的与重要价值产出相关的Bug可以演示，其他Bug无需演示。

问：有的工作对用户不可见，怎么演示呢？

答：这个问题要仔细看，是哪些工作对用户不可见。总的来说，不可见的工作有以下几类。

1.貌似不可见，其实可见

在一个团队SprintBacklog里，有一个用户故事是：提升性能，10万并发用户同时操作，页面响应在1秒钟之内。

在SprintDemo会上，团队认为，现在没有这么多用户，没办法演示。我问团队：“这个测试过吗？”团队说：“模拟测试通过了。”我问团队：“那有测试报告吗？”团队答：“当然有了。”

在这样的情况下，测试报告本身就可以Demo，证明这个故事已经达成目标。

2.技术改进类工作，确实不可见

比如，团队为了能够让特性独立发布，做了架构解耦的工作。但是，架构解耦对用户确实不可见。怎么办呢？

如果团队Demo新的架构设计，或者架构评审意见，参会者未必看得懂。即使看得懂，他们也不会在会上评审架构。所以团队还不如直接告诉与会者：我们做了架构解耦的工作，能够达到什么效果。

3.交付的东西不足以产生价值

一个团队的某个用户故事描述为：后台报表修改×××字段。如果这个用户故事本身不直接产生用户价值，而是需要与前台集成后才产生价值，那么这个问题就不是如何Demo的问题，而是用户故事的拆分方式问题。团队要从价值的角度拆分用户故事，贯穿前端、后端，使其对客户和用户产生价值。