scrum sprint_产品负责人的Sprint审查提示

scrum sprint

冲刺审查会议对于产品人员来说可能是最重要的Scrum活动，它可以帮助您收集反馈并做出正确的产品决策，从而增加创建成功产品的机会。 但是我发现产品所有者并不总是清楚应由谁参加会议，应如何召开会议以及如何收集相关反馈。 本文回答了这些问题，并分享了我的一些技巧，以充分利用sprint审查。

让合适的人参与

从合适的人那里收集反馈对于做出正确的产品决策至关重要：如果邀请错误的人员或关键人员不见了，那么您不太可能收到所需的反馈。 因此，您应该确保邀请合适的人。

根据经验，请那些需要验证其最新产品增量并向前移动产品的人员参加。 这些通常是您的关键利益相关者 ，即对您的产品感兴趣并且需要开发和提供产品的人员。 其中可能包括来自营销，销售，服务和支持以及其他业务部门的人员，具体取决于您的产品和组织。

我发现向个人解释为什么要求他们参加会议以及他们可能看到什么，以鼓励他们参加并设定期望值很有帮助。

合作但不要害怕拒绝

我参加的一个以上的sprint审查会议很快结束了：一名开发团队成员演示了该功能，以使背景模糊的利益相关者与产品所有者混淆。 之后，ScrumMaster询问是否有任何问题或反馈，但是利益相关者只是互相看着对方，有的说“很好”，“看起来不错”，然后人们离开了。 在这次会议上收集到的宝贵反馈为零。

因此，鼓励人们积极参与并分享他们的观点，想法和疑虑。 使用开放式问题，例如“您对我们对注册功能的改进有何看法？” 尝试了解为什么有人喜欢或不喜欢产品增量。 收到“看起来很棒”之类的反馈可能会感觉不错，但它并没有提供任何新见解。 人们为什么喜欢这些变化？ 还有什么可以进一步改善的吗？

让所有与会者都有机会被听到。 即使您不同意或很难接受他们，也要感谢他们的意见和反馈。 切记：利益相关者的创造力，知识和反馈应有助于您做出正确的产品决策并提供最佳产品。

同时，请勿接受个人使用会议提出要求或为自己或他们的业务部门达成最佳协议。 我记得在一次冲刺审查会议上，一位资深利益相关者向产品所有者和开发团队大声疾呼了他的要求，这当然既不合适，也没有帮助。

作为产品负责人，要善良和理解。 但是，不要让利益相关者告诉您该怎么做。 您拥有产品，必须拥有最终决定权，否则您将没有足够的权威和尊重 。

如果想法和要求没有帮助和现实，请不要害怕。 将产品路线图与整体产品策略一起使用，以决定是否应接受请求。 毫无疑问，请使用下一个冲刺来测试该想法或请求是否对用户有利。 但是请记住，几乎不可能提供令所有人满意的产品。

请您的ScrumMaster协助会议并建立基本规则。 这使您可以与与会者互动并收集反馈，而无需进行审核。

考虑将会议分为两部分

有时将sprint审核会议分为两个部分会有所帮助。 首先，您和开发团队会聚在一起。 团队将产品增量演示给您。 然后，您可以向团队成员提供反馈，并使用例如发布燃尽图（如我在下面更详细地讨论）来确定完成了哪些项目以及取得了多少进展。 如果您决定利用即时评论，在冲刺过程中提供有关新功能的反馈，则可能根本不需要此部分。

在第二部分中，利益相关者参加会议。 我发现作为产品所有者，您通常最适合向利益相关者展示产品增量：您可能比开发团队成员更好地理解用户如何与产品交互并使用新功能。 然后收集利益相关者的反馈，以了解您是否在创建具有正确用户体验和功能的正确产品。 例如，按照上面的建议提出开放性问题，以了解为什么新功能很棒，或者为什么应该更改它。

拆分会议可以使您与开发团队进行私人对话，并可以在Scrum团队外部的人员加入您之前解决所有分歧。 当您在冲刺期间没有机会与团队互动时，这特别有用-因为您与团队不在一起，或者您忙于拜访用户和客户或参加贸易展览或会议。 但是，请确保开发团队成员出席整个会议并出席第二部分。 直接听取利益相关者的反馈是非常宝贵的。

考虑分别收集用户和利益相关者的反馈

冲刺审核会议的初衷是将所有合适的人员召集在一起，并同时收集每个人的反馈。 如果这对您有用，那就太好了。 但是，通常，我发现分别收集用户和内部利益相关者的反馈会更有帮助。 为什么？ 两组倾向于有不同的观点和兴趣。

通过与用户一起测试产品增量，您可以了解该产品是否能够为其目标群体做出出色的贡献，以及它是否提供了正确的用户体验和正确的功能。 与利益相关者讨论增量，可以帮助您了解产品是否可以有效提供，组织是否可以操作，销售，销售和支持。

此外，最好使用不同的技术收集用户和利益相关者的反馈：在实现很少的功能时，将产品增量演示给最终用户是有意义的。 否则，使用可用性测试和早期发布等方法观察或衡量人们实际使用产品的方式往往会更有帮助。 （有关更多信息，请参见我的文章“ 如何在Scrum中选择正确的产品验证技术 ”。）

由于这些技术通常需要比sprint审查会议提供的时间更多的时间-向（选定的）用户发布产品增量后可能需要几天的时间来收集相关数据-这自然将收集用户数据与收集利益相关者的反馈区分开来。

请记住，用户胜过利益相关者：如果该产品对用户没有好处，那么人们将不会（长期）使用该产品，无论该产品的可销售性或可服务性如何，或首席执行官多么喜欢它。

不要仓促决定

有时，如《 Scrum指南》建议的那样，有可能在sprint审查会议中立即做出产品决策，甚至更改产品积压。 但是通常（尤其是如果反馈影响更大并导致大量积压更改），您将受益于有更多时间分析反馈，得出正确的结论并确定需要更改哪些积压产品。 此外，如上所述，如果您决定分别收集用户和利益相关者的反馈，则可能无法在sprint审核会议中获得所有相关数据。

因此，您应该考虑将收集的反馈和数据与分析和操作分开。 例如，您可以选择在下一次冲刺计划会议之前召开简短的，重点突出的产品积压研讨会，从而为您提供机会客观地评估反馈并与开发团队一起更新积压； 或者，当您借助分析工具收集了足够的用户数据后，您可能希望在下一个冲刺中安排产品积压会议，正如我在我的文章“ 何时应该进行产品积压整理？ ”。

讨论发布进度

想象所有反馈和数据表明人们会喜欢您的产品。 但是，如果您落后于计划和预算，那么您的产品可能不会成功-甚至可能不会正式发布。 因此，定期确定所取得的进展非常重要。

冲刺审核会议是执行此操作的绝好机会，因为您现在应该能够分辨出哪些项目已经完成，因此可以了解到您已经走了多远。 此外，参加会议的主要利益相关者有兴趣了解是否将按计划发布新产品（版本）或是否有延迟，因为这很可能影响他们的工作。 更重要的是，讨论进度会将当前的sprint置于上下文中，并将其与先前的sprint连接起来。

我喜欢使用发布燃尽图 ，这是Scrum的标准工件，用于跟踪发布进度并预测项目的发展方式。 该图表显示了产品积压工作从冲刺到冲刺的发展过程—这种想法是随着时间的推移，这种工作量会减少或“消耗掉”。

无论使用哪种工具：请确保它可以帮助您了解进度如何并进行必要的调整-是向团队添加UX设计器，推迟发布日期还是部分满足发布目标并可能交付少于计划的功能。

翻译自: https://www.javacodegeeks.com/2017/11/sprint-review-tips-product-owners.html

scrum sprint