怎样才能开一场高效的迭代评审会？

共创嘉宾| 潮海项目教练

撰文编辑| LigaAI

全文约 4,300 字，阅读约需 12 分钟

迭代评审会（Sprint Review）基于真实的用户使用场景，展示当前整个产品增量，通过获取贴合用户使用习惯的反馈和建议，最终输出产品待办列表的优化调整。迭代评审会应重点关注用户需求的解决情况，而不是查找缺陷（当然，影响核心流程的重大缺陷一定要记录在册）。

• 展示结果：开发团队检视当前迭代的最初计划，展示每个需求/故事的工作结果及变化；

• 评审反馈：产品负责人进行确认，收集反馈，并记录进一步的改进设想为新需求/故事；

• 调整方案：产品负责人及关键干系人介绍有关后续迭代的新信息/设想，为接下来的迭代计划会议提供有价值的输入信息。

基于清晰的会议目的和讨论重点，如何更好地完成迭代评审会？高效的迭代评审会又有哪些不为人知的事半功倍小技巧？

本期敏捷实践，LigaAI 联合潮海项目教练团队的资深敏捷教练，一一为你解答。

一、 每个迭代结束都要进行评审吗？

作为 Scrum 五大事件之一，迭代评审会通常在产品增量完成后、正式发布前举行，但在实践经验中，并非每个迭代完成都必须要进行评审。依据时间频率的不同，迭代评审会分为高频评审和低频评审。

• 高频评审适用于产品增量复杂的情况。通过将产品增量拆分成若干个关键需求，并在每个关键需求完成后，邀请重要干系人参与检验，以分散一次性评审的会议压力。

• 低频评审适合产品增量对干系人的感知价值不大（比如长流程的端到端需求）或干系人时间紧张等情况。通过多个增量的合并评审，减少频繁会议对工作的占用和干扰。

此外，以迭代周期/固定周期作为举行迭代评审会的标志并非最优解。迭代周期是团队内部的开发管理单位，在可感知价值增量层面或有不稳定性。

更好的做法是基于里程碑/史诗的完成情况，以增量结果为指标，按需开展迭代评审会。 研发里程碑一般分为「内部里程碑」和「外部里程碑」两种。

• 内部里程碑常指项目关键决策点，如需求阶段完成、设计阶段完成，主要用于评估项目内部风险，一般不涉及用户反馈，无需迭代评审；

• 外部里程碑是涉及对外发布的重大功能/模块的完成，需要在产品发布前邀请关键干系人参加迭代评审会，并贡献真实的使用反馈。

二、 干系人一定要参与会议吗？

在《每日站会能不能取消？》一文中，我们曾提到「非必要情况下，Scrum Master 可以不参加每日站会」。那么，迭代评审会是否也可以不需要关键干系人的参与呢？

答案是——不可以。

迭代评审会的核心目标是收集用户反馈，所以关键干系人的参与极其重要。 但在实际中，不可避免地，干系人可能因各种原因无法参加会议，可以采用以下几种方式解决：

第一，由干系人授权的决策代表代替干系人参加会议。决策代表需要具备对产品增量贡献反馈的能力，并且要能够提出「通过与否」的关键性意见。

第二，如果干系人无法分出大块时间参与评审，那 Scrum 团队可以采用高频小模块的方式完成反馈，遵循「价值原则」——先展示最急需反馈的功能。

第三，将干系人的会议预约列入待办。避免临期预约的冲突和缺席隐患，产品负责人可以在迭代规划期，就提前锁定关键干系人的会议时间，或将迭代评审会以定期形式常态化（比如安排在每双周的固定时段），确保干系人可成功出席。

贡献反馈的干系人必须参加，而执行反馈的技术人员也同样不能缺席。 开发团队应在现场直面用户，聆听最真实的用户声音，才能更好地理解业务、理解需求。

理想情况下，开发团队应全员参与迭代评审会，同干系人一起协作讨论，在认同中建立工作价值感；

如果团队规模较大，也可以轮流派代表或者安排技术骨干参与会议，负责本次产品增量的开发人员必须出席会议，以减少一手反馈的传递偏差。

三、迭代评审会的多种打开方式

01 合而为一

践行 Scrum 的过程中，敏捷四会（即计划会、每日站会、评审会和回顾会）不必是完全独立的。

例如，对于每周一迭代的短周期敏捷团队，可以考虑将评审会和计划会合为一次会议，以减轻会议负担。会议中，应先评审、后计划：关键干系人在评审结束后先行离场，Scrum 团队继续进行新一期迭代的计划会议。

迭代回顾会则不建议与其它会议合并，因为这是敏捷团队复盘和经验总结的宝贵机会；但可以考虑将多个迭代的回顾会合并一次举行。

02 一分为二

对于产品增量价值低、客户感知影响不大、或有高质量要求，需先进行内部评审的迭代而言，可以采用「一分为二」的低频评审形式，将迭代评审会分为「Scrum 团队的内部会议」和「与干系人协作的外部会议」两次进行。

• Scrum 团队的内部评审侧重于完整的功能展示，重点审查关键功能能否跑通、是否存有 Bug 尚未修复/发现等；

• 有关键干系人参与的外部评审以收集用户真实反馈为主，重点验证产品增量是否满足客户需求、是否达成真正的产品价值。

03 直面客户是最好的形式

远程办公和异地协作盛行的今天，共享式的文档/表格/问卷协作免去许多会议，但是迭代评审会以获取用户真实反馈为核心，面对面沟通却是不可省去的重要仪式——直面客户、观察用户的使用和体验是获取有效反馈的主要途径。

对于重要且急需用户反馈的功能，Scrum 团队应主动安排产品负责人和功能相关的技术骨干前往干系人公司，进行一对一展示和沟通；

面对无法克服的时差或时空问题，也可以采用线上视频会议的形式，但是建议要开启摄像头和麦克风，并使用共享屏幕，让 Scrum 团队「看到」干系人的使用反馈。

四、迭代评审会的四个黄金搭档

高效的迭代评审会一般包含功能演示、体验试用、讨论反馈和待办优化四个环节。

01 功能展示

述清会议内容与目的后，开发成员结合迭代计划与产品增量，向产品负责人和关键干系人展示已经完成的产品价值。

看似简单的功能展示，也存在一些共性的改进空间——《深入核心的敏捷开发》提出「展示会七宗罪」以描述功能展示过程中的七大问题，并针对性地提出了高效展示会的七个技巧。

七宗罪之一：准备工作没做好，空耗会议时间

正确做法：主讲人在正式展示前，应该做好充分的准备工作——预演演示步骤，准备测试数据，提前部署演示环境等等，避免手忙脚乱和空转浪费，提高会议效率。

七宗罪之二：没有说明铺垫，云里雾里不知所以

正确做法：在开始演示之前，主讲人应当简要地介绍会议目标和所要展示的功能，并说明功能给用户带来的价值。清晰的上下文能让产品负责人和干系人更快地进入状态。

七宗罪之三：逐条过验收标准，缺失业务完整性

正确做法：不要逐个演示用户故事/验收标准。主讲人应以功能为单位，将完整的产品/功能/模块串起来展示；最好定义出单独的业务场景，使用业务语言让业务成员更有代入感。

七宗罪之四：相同/类似的功能，演示所有路径

正确做法：只演示最关键的路径。遇到多个路径实现相同或相似功能时，选择其中一条最复杂/重要的路径详细演示，其他路径指出不同的地方，点到为止，无需覆盖全部路径。

七宗罪之五：过多提及跟演示功能无关的内容

正确做法：专注于最有价值/重要的功能演示，不要让小反馈/未完成的模块耽误会议时间；尽量不提及技术难题或技术方案等业务人员不感兴趣的内容。

七宗罪之六：认为展示仅仅是 BA 或 QA 的事情

正确做法：不让某个角色独占功能展示，人人都应该参与进来；可以采用人员轮换的方式进行展示，这样可以提升成员的业务意识，更熟悉整个系统功能。

七宗罪之末：不熟悉的新人负责展示，重点模糊

正确做法：新人展示前应充分了解业务和系统，确保能够应对和解答业务的挑战和疑问；也可以让新人在结对编程、Story Kickoff 等多做主导，具备一定的系统和业务意识后再向干系人展示。

02 体验试用

开发成员完成功能演示后，更重要的是要让关键干系人亲自体验和试用系统功能/Demo。用户亲自下场试用和检验，是获取反馈中必不可少的一环。

产品负责人也可以邀请真实的用户参加评审会，让其在开发的指导下体验演示的功能和系统。需要注意，此时开发团队应该为干系人和用户留出足够的自主探索空间，引导他们重现最真实的使用习惯和场景，避免成为「产品推销员」。

03 讨论反馈

产品负责人要收集关键干系人（和用户）的反馈，及时记录最新的改进与设想为新的需求。在体验试用环节，Scrum 团队可以通过以下几种方式，观察用户体验，洞悉真实反馈。

• 注重整体的展示，避免成为验收测试

让干系人和用户体验功能并非授权全自主探索——开发成员需要提供必要的场景描述，还原功能使用场景，让用户更有代入感；但，切忌进行步骤指导，过多的干预反而不利于观察真实反馈。

另外，不要逐一演示用户故事。开发成员应尽可能引导用户对整个产品/功能模块进行试用，并关注基于产品整体的功能完整性和衔接流畅性，观察和分析可能存在的优化空间。

• 细心观察用户表现，敏感捕捉使用障碍

在用户体验功能时，Scrum 团队应该留心观察他们自然表达和流露的语言、表情、操作和使用习惯等，要具备捕捉异常的敏感度。

比如用户是否在使用期间出现困惑表情、在无反应的地方反复点击等等。通过深入挖掘用户行为背后的原因，了解最真实的行为反馈。

• 使用开放性问题，引导用户自主表达

与干系人和用户协作、沟通和讨论时，避免使用「是不是」、「有没有」等封闭性问题；多用开放性问题，一步步引导用户表达出最真实的想法。

发现用户频繁点击某个按钮，或浏览选项的时间过长时，可以通过抛出「你希望这个按钮提供什么功能/选项（但没有满足）吗？」等问题，鼓励用户主动说出对系统功能的期待，为后续的迭代贡献有价值的意见和改进空间。

04 待办优化

在评审会的最后，产品负责人及关键干系人介绍有关后续迭代的新信息或新设想，结合当前产品或市场环境的变化，讨论即将发布的版本的产品功能，为接下来的迭代计划会议提供有价值的输入信息。

通常在会后，产品负责人会结合迭代评审会的结果，对产品待办列表和需求优先级进行重新评审和整理——这也是衡量会议成功的关键。

为了更准确地完成待办列表调整，开发团队应对未完成的工作保持开放和透明，以便产品负责人能制定更全面的决策；

产品负责人可以结合不同决策依据，应用优先级排序的三个模型和四张画布，更高效地完成调整。

更多阅读请点击：

不同决策应参考什么指标进行优先级优化？

做优先级排序时使用最多的三个模型

译文 | 四张画布教你判断「产品开发优先级」

# Liga 总结

迭代评审会的核心目标是为了获取真实的用户反馈，为后续的迭代和研发工作贡献有价值的意见。

高效的迭代评审会要抓住功能展示、体验试用、讨论反馈和待办优化四个关键环节。Scrum 团队以专业、高效的姿态，向干系人和用户呈现研发成果；通过引导和观察，洞悉真实场景下的使用反馈，更好地服务后续迭代。

了解更多敏捷开发、项目管理、行业动态等消息，可关注LigaAI获取更多咨讯，LigaAI 期待与你一路同行，助力开发者扬帆远航！