在过去几年中，和许多Scrum Master交流时，我遇到一个令人担忧的模式。虽然我们有Scrum指南和其他补充资源，许多Scrum Master，特别是刚起步的Scrum Master们，还在日复一日的为如何帮助Product Owner而挣扎着。
以下是我与PO合作的一些案例，以及Scrum指南中的引文，它们能帮助我在给予支持和做他们分内的事之间进行平衡。
「一」
让我们从第一条开始吧：
帮助找到有效定义 Product Goal 和管理 Product Backlog 的技巧；
“帮助找到技巧”是什么意思？是不是一句“给你，这个用户故事地图可以解决你的所有问题”？在我看来，我们Scrum Master 应该通过任何必要的方式来研究这些技术，例如：
“Google一下”，承担与PO相同的“找到最佳技术”的压力。
与其他Scrum Master建立联系，有机会借鉴他们的经验。
让PO与其他PO建立联系，不论是组织内或组织外的，以确保知识共享。也许你们已经有一个PO的社群？如果还没有，或许可以考虑建立一个？
参加各种可用技术的聚会和培训，并能向PO解释它们的含义，以便在必要的时候采用。
引导关于定义Product Goal或管理Product Backlog的工作坊。
教授不同的Product Backlog排序方式 —— 你是否尝试过基于价值的排序方法？
与PO建立日常的一对一辅导机制。
一对一常规会议的重要性，怎么强调都不为过。这就是我所说的“魔法发生”的地方。作为 Scrum Master，我们要确保对 Scrum 框架，以及PO在 Sprint 期间可能遇到的所有问题有更深入的了解。不幸的是，这也是 Scrum Master 没有足够重视的事情之一。我们常说，“要建立关系，要有真正的改变，我们需要信任”。这便是这种信任可以发生的神奇时刻之一。
这只是关于我们如何帮助PO建立产品目标和管理Product Backlog的一小部分想法，我鼓励你使用任何你能掌握的技能，在这件事上给予PO支持。
「二」
我们可以在Scrum指南中找到另一条参考，Scrum Master可以如下方式服务于PO：
帮助 Scrum Team 理解为何需要清晰且简明的 Product Backlog 条目；
以下是关于如何支持这一点的一些想法：
确保在Sprint Planning期间，Scrum团队对于即将开始的Sprint的WHY，WHAT 和 HOW都有所了解。
建立PBI（产品Backlog条目）的透明度。
鼓励PO和团队成员试验不同的创建PBI的方法，也许用户故事并不是唯一的可选形式？
提出强有力的问题，例如：几周后你还能理解你的PBI吗？
将PBI与完成定义（DoD）联系起来，例如问：怎么才能知道这个PBI被完成了？需要满足什么条件？
抛出一个补充实践的想法，例如“准备就绪的定义”（我个人并不喜欢，但我知道某些团队可以从中受益）。
建立一个关于PBI的定义标准（例如，它应该有一个目标，描述，验收标准 —— 任何对你的团队有用的东西）。
「三」
指南中的下一条：
帮助建立针对复杂环境的基于经验主义的产品规划（empirical product planning）
这是个难题。基于经验主义的产品规划到底是什么意思？
对我来说，就是吸取从以前的Sprint中得到的经验，为下一个Sprint做调整。但是，要做到这一点，我们需要在Sprint计划会之前就开始。
在回顾会上，Scrum Master为Scrum团队营造了一个安全的环境来检视他们在前一个Sprint中的工作。
Scrum Master要确保PO考虑到所开发产品的市场信息。
帮助产品负责人找到适合产品的衡量标准，展示不同的方法 —— 也许使用循证管理会是一个好的起点？
帮助将注意力集中在我们的产品将为客户提供的价值上 —— 我们确定所有这些功能是真正需要的吗？
我们确保PO始终对他设定的产品目标有意识，可以提醒他：这个元素将如何服务于我们的产品目标？
解释什么是复杂环境 —— 并加深对Scrum如何在该领域提供帮助的理解。你上次和你的产品负责人谈论复杂理论是什么时候？
「四」
最后一点，同样重要：
当需要或被要求时，引导干系人进行协作。
这一点要怎么做到？
帮助PO找到组织内和组织外的干系人 —— 也许可以用干系人地图？
确保所有的相关信息都被PO考虑在内。
在需要时引导专门的干系人会议，就如何选择最符合我们产品发展方向的干系人需求提出一些想法 —— 也许可以用工作/影响矩阵？
向PO展示为其产品收集反馈的必要性。
确保我们的 Sprint 评审会中有产品用户参加 —— 我们经常只有内部干系人参加，而他们实际上并不使用我们的产品！
确保与干系人合作的透明度 —— 也许可以通过 Product Backlog 和其排序展现的清晰愿景？
正如你所看到的，虽然我们在Scrum中有一些指南，但在这个框架之内如何实现，还有着充分的自由度。这既促进了创造力，有时也会让人感到沮丧。
我希望这篇文章能给你带来一些想法和灵感，让你了解如何把这些挫折的时刻变成创造力。
原文地址：
https://www.scrum.org/resources/blog/how-can-scrum-master-support-product-owner
注：部分图片来源于网络
