Scrum Master 如何更好的支持PO？

帮助找到有效定义 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支持。

2

我们可以在Scrum指南中找到另一条参考，Scrum Master可以如下方式服务于PO：

• 确保在Sprint Planning期间，Scrum团队对于即将开始的Sprint的WHY，WHAT 和 HOW都有所了解。
• 建立PBI（产品Backlog条目）的透明度。
• 鼓励PO和团队成员试验不同的创建PBI的方法，也许用户故事并不是唯一的可选形式？
• 提出强有力的问题，例如：几周后你还能理解你的PBI吗？
• 将PBI与完成定义（DoD）联系起来，例如问：怎么才能知道这个PBI被完成了？需要满足什么条件？
• 抛出一个补充实践的想法，例如“准备就绪的定义”（我个人并不喜欢，但我知道某些团队可以从中受益）。
• 建立一个关于PBI的定义标准（例如，它应该有一个目标，描述，验收标准 —— 任何对你的团队有用的东西）。

3

指南中的下一条：

帮助建立针对复杂环境的基于经验主义的产品规划（empirical product planning）

• 在回顾会上，Scrum Master为Scrum团队营造了一个安全的环境来检视他们在前一个Sprint中的工作。
• Scrum Master要确保PO考虑到所开发产品的市场信息。
• 帮助产品负责人找到适合产品的衡量标准，展示不同的方法 —— 也许使用循证管理会是一个好的起点？
• 帮助将注意力集中在我们的产品将为客户提供的价值上 —— 我们确定所有这些功能是真正需要的吗？
• 我们确保PO始终对他设定的产品目标有意识，可以提醒他：这个元素将如何服务于我们的产品目标？    
• 解释什么是复杂环境 —— 并加深对Scrum如何在该领域提供帮助的理解。你上次和你的产品负责人谈论复杂理论是什么时候？

4

最后一点，同样重要：

当需要或被要求时，引导干系人进行协作。

这一点要怎么做到？

• 帮助PO找到组织内和组织外的干系人 —— 也许可以用干系人地图？
• 确保所有的相关信息都被PO考虑在内。
• 在需要时引导专门的干系人会议，就如何选择最符合我们产品发展方向的干系人需求提出一些想法 —— 也许可以用工作/影响矩阵？
• 向PO展示为其产品收集反馈的必要性。
• 确保我们的 Sprint 评审会中有产品用户参加 —— 我们经常只有内部干系人参加，而他们实际上并不使用我们的产品！
• 确保与干系人合作的透明度 —— 也许可以通过 Product Backlog 和其排序展现的清晰愿景？

正如你所看到的，虽然我们在Scrum中有一些指南，但在这个框架之内如何实现，还有着充分的自由度。这既促进了创造力，有时也会让人感到沮丧。