将产品负责人的角色委派给团队!

错别字在原来的帖子-但饮食团队做所有的工作应该读-但指示团队做所有的工作…

假设产品负责人仍然负责，那么他们有什么动机以不负责任的方式进行委托呢?

PO角色不是兼职角色，在sprint中会消耗大量的时间。Scrum指南中定义的项目详细说明了这一点。

如果PO将其全部委托给团队，那么它就剥夺了团队实际完成工作的能力。它还开始稀释和否定PO角色的价值，因此使他们只是一个审批者。

在与Jeff交谈时(我为他工作)，这并不是他创建PO角色时的意图。

我遇到的PO“太忙了”，没有时间做PO，他们有“其他的日常工作”要做，所以他们告诉团队和/或SM写故事，并想出下一个冲刺。然后他们作为PO简单地表示不同意。

按照Scrum指南的定义，这真的是可以接受的吗?

甚至点头表示赞同……

如果采购订单正在最大化产品的价值，正如Scrum指南中所描述的那样，那么他们可以以他们认为最合适的方式进行委托。

但是，如果他们“太忙”并表现出你提到的行为，他们真的能最大化利益相关者的价值吗?

因此，从PST的角度来看，您认为团队可以编写100%的pbi，对backlog进行优先级排序，优化自己的工作，并决定目标和任务。

我会问:如果PO这样做了，他们会最大化产品的价值，并能够向利益相关者解释吗?

Scrum指南还说:

开发团队由组织组织和授权来组织和管理他们自己的工作。

从理论上讲，这意味着开发团队可以等到Sprint的最后一天，并在当天完成所有工作。当然，如果很明显他们管理工作的方式是有害的，或者至少，不能创造最高可能的价值，那么你就会期望Scrum团队检查自己并相应地进行调整。

虽然在大多数情况下，情况确实如此不对于PO来说，将100%的产品待办事项管理职责委派给开发团队是有益的，可能会有一些奇怪的情况，有证据表明它是这是有益的，订单能够最大化产品的价值，因为它。

想象一下您的订单如何使用Nexus或LeSS大规模工作。

即使是一个非常大的产品，你也只有一个PO，负责使产品价值最大化，具有全球视野。

你认为这样一个订单，即使在这个单一产品上100%的工作，在使用它的时间写PBI时，是最大化产品的价值吗?你认为他能在没有开发团队帮助的情况下优先考虑完整Nexus的薄pbi吗，还是应该专注于史诗级别的优先级?

在将一些基础工作委托给开发团队并留出时间与客户和其他关键涉众合作方面，PO可能更有价值。

如果他们说是的，他们的利益相关者看起来也没问题，那么这是对团队时间的最佳利用吗?

更少的时间来交付功能。如果PO完全参与并扮演PO角色，那么团队可以完全专注于交付价值，而不是在他们可以工作之前创建工作的上下文切换。在我看来，让团队成为PO角色并不是作者的意图，而且只会减慢交付。

更少的时间来交付功能。

也许是的，但我们的目标是交付最好的功能(价值)，而不是更多的功能(速度)。

@Oliver完全同意。同样的逻辑适用于如果他们有更多的能力，他们可以在冲刺中提供更多的价值。

此外，速度(正如我们所衡量的)并不是对交付特性的衡量，而是对交付订单的价值的衡量。唯一的值是一个完整的PBI。

然后你可以做一些有用的推断，看看每个点的价值。这完全取决于你如何看待点(工作规模的估计)，我知道有不同的思想流派:-)

@Oliver和我认识到，在Nexus框架下，3-9个团队有一个单独的订单，类似地，在LeSS中，2-8个团队有一个单独的订单，但另一种观点是，每个团队都应该有一个订单，根据单团队Scrum中的Scrum指南。许多从业者都需要CPO，但每个团队都保留自己的PO。当然，我们可以讨论一种方式与另一种方式的优点，我们都有有效的学习点，但从单一团队的角度来看，也就是Scrum指南，我的观点是，采购订单必须是全职的，完全投入的，并扮演采购订单的角色，而不是将这个角色委派给团队，他们专注于交付采购订单优先考虑的价值。

我的观点是，一个PO必须是全职的，完全投入的，并且扮演一个PO的角色，而不是将这个角色委派给团队，他们专注于交付由PO优先考虑的价值。

@奈杰尔，我不认为这个观点有任何分歧。重点就在这里五月当PO发现开发团队执行一些产品待办事项列表管理是最有价值的时候。

如果Scrum团队和产品可以从中受益，又有什么坏处呢?

我们都同意PO是一个很重要的职位，我们要认真对待全职工作。

对我来说，如果不是PST，问题是锁定瓶颈，我们如何从全局角度优化流程，而不是从PO或开发团队的局部角度。

例如，如果PBI很容易描述和确定优先级，但很难实现，并且开发团队是由3个初级de组成的，那么瓶颈可能就在开发端。如果PO能尽最大努力拥有清晰的PBI和UAT，以帮助开发团队，那就太好了。

如果PBI描述起来非常复杂，业务模型也很难优化，但由9名明星开发人员组成的开发团队很容易实现，那么瓶颈可能就在PO方面。在这里，有开发团队帮助PO会很好。

系统思考方法是必不可少的，您的评论支持了基于经验观察的检查和适应的持续改进观点。

我认为我们所有人都能接受的唯一观点是，采购订单和开发团队将密切合作，以确定管理各种“积压管理”活动的最佳方式。

产品负责人负责“什么”，并确保团队工作在对客户/业务最关键的事情上。如果这种责任以任何方式委托给开发团队(他们的主要责任应该是“如何”)，那么Scrum的这种好处就失去了，我会质疑让一些人不与团队保持一致，只在每个sprint结束时给出赞成或反对的意见的价值。

@Alex在这一点上我没有异议。我担心的是，指南中的这句话为滥用敞开了大门，因为指南是规则的MVP，所以我认为它太模糊了。这只会让指导和培训产生分歧，因为它给PO留下了争辩他/她正在偏离指导的余地。问我怎么知道的!

*跟随不落下

科技债务论坛。没有办法编辑帖子…

刚刚看到这个讨论，即使我对指南中的陈述很满意(因为它将负责任和可问责分开了)，我认为你的问题中有一些有趣的地方。你已经讨论了中心问题，所以我不能/不会再补充一些有价值的东西。

然而，每当我的团队提出这类话题时，总是有一些价值观的味道，往往没有实现，导致缺乏信任。所以，这种担忧不是来自于缺乏信任吗?例如，信任一个PO不会是一个懒惰的人，只是让开发人员做他们所有的工作?

我在大型项目工作了一段时间后意识到，有时团队会改进后端工作功能来增强系统，开发团队通常在某些情况下比PO对这些组件和所有细微之处有更好的了解。他们是系统的一部分，但不面向客户，尽管他们为这些客户创造价值。

尽管PO提供一些业务功能，但它通常只知道这些流程的结果。

当定义验收标准的时候，开发团队的一些成员(开发人员，尤其是测试人员)可能更适合编写和验证它们。

对于这些“后端”故事，PO可能没有太大的帮助。故事标准可能会尊重INVEST规则，并真正为客户提供价值，即使你在客户端没有任何交互界面。

我想到了一些例子:

• 提高生成系统报告的速度
• 增强系统的抗故障能力
• 利用现有系统连接到新的微服务，提供新的安全性
• 等。

我是一名产品经理，每一次冲刺都由我来指导开发团队应该做什么。但是我在一个非常高的层次上做这件事，我不从backlog中创建故事，但是当我们有backlog细化会议时，我在那里回答问题。在我之前的团队中，我创建了待办事项列表中的每一个项目。我认为这里的关键是观察你的团队的成熟度，并决定什么是有意义的，以及整个scrum团队如何才能最好地工作以交付更多的价值。希望大家能理解。

以我为例，我们与团队中的UX专业人员共同编写道具，而这些道具的技术细节则由团队中经验丰富的开发人员完成。所有这些都由采购官审查。它运行良好，给整个团队带来了满意。

指南中提到的采购订单的责任对所有领域、所有类型的项目、所有类型的业务都是通用的。

这也取决于PO与多少个开发团队一起工作的情况

但是正如“赫克托耳莫拉莱斯，作为一名产品经理，他有责任提供更多的价值，参加积压梳理会议并提供澄清。

即使采购订单不创建用户故事，但他需要审查，采购订单是负责的。采购订单将在sprint评审期间呈现(由开发团队演示并进行评审)，并对照sprint目标进行检查。

我不确定以下的主题是否可以考虑由Product Owner委托给DT。因为这是非常正确的，PO应该价值最大化。

参加sprint回顾，参加sprint评审，排序产品待办事项，制定和沟通产品目标

Scrum指南说，产品待办事项列表管理的某些职责可以被授权。你所描述的哪些事情与管理产品待办事项列表有关?