网站开发主流方法,网页设计工资一般多少钱,互联网营销推广,个人网站可以做百度竞价在过去几年中#xff0c;和许多Scrum Master交流时#xff0c;我遇到一个令人担忧的模式。虽然我们有Scrum指南和其他补充资源#xff0c;许多Scrum Master#xff0c;特别是刚起步的Scrum Master们#xff0c;还在日复一日的为如何帮助Product Owner而挣扎着。
以下是我…在过去几年中和许多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的WHYWHAT 和 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中有一些指南但在这个框架之内如何实现还有着充分的自由度。这既促进了创造力有时也会让人感到沮丧。
我希望这篇文章能给你带来一些想法和灵感让你了解如何把这些挫折的时刻变成创造力。
原文地址
Scrum Master 如何更好的支持PO - Leangoo领歌
