In a Scrum or Agile team is it advisable for a Product Owner to be involved in more than one product?
首先你必须明白，在 Scrum 中你不会对此有一个客观的答案。你必须检查并适应。 Scrum 指南（由 Scrum 发明者编写）中没有提到 PO 不应处理超过 2 个产品，但他们确实提到，为了使 PO 成功，他必须对产品承担全部责任，并且组织必须尊重 PO 的决定。PO 是产品待办事项列表中的“猪”，无论是 1 个还是 2 个或更多产品，如果 PO 和利益相关者可以处理这个问题，我会说尝试一下，然后检查和调整。还有各种因素，例如产品的复杂程度、产品负责人的专业化程度以及 PO 必须为多个产品履行 PO 职责的带宽有多少。在尝试之前请考虑所有这些。
Is it good to have a Product Owner for the Enterprise System and "sub" Product Owners for the components of that system? i.e. In a Retailer would you have a PO for the enterprise system that drives "sub" PO's for say Retail, Supply Chain and Manufacturing?
同样，您必须在您的组织中尝试一下才能知道它是否“好”。在任命 PO 或子 PO 时，只需遵循正确的 Scrum 指南即可。我在我的组织中尝试过，效果非常好！我们有一个首席 PO 和其他几个 PO，您可以将他们称为子 PO，但我更喜欢让每个人都处于同一级别，以避免命令和控制行为，如果滥用，可能会毁掉一个项目。首席 PO 的工作是确保 PO 成功完成其工作，并在需要时为 PO 提供帮助。任命 PO 也可以由首席 PO 和首席 SM 或 SM 一起完成。如果我可以稍微离题一下，SM 也遵循相同的结构。首席 SM 的工作是帮助 SM 成功完成其工作，例如，如果 SM 无法解决障碍，他或她可以让首席 SM 介入帮助解决。
Be interested in how others deal with Scrum teams in an enterprise environment with many stakeholders in functional silos.
就像我上面已经提到的那样。我们的企业环境中有一位首席 PO 和其他几位 PO。还有一个包括利益相关者在内的指导委员会。每个采购订单都有自己的产品待办事项列表需要管理。我们进行了两周的冲刺。我们每个月召开两次名为“指导委员会会议”的会议，所有利益相关者以及首席 PO 和 PO 都会开会，引导企业产品朝着正确的方向发展，每个 PO 都将工作翻译成 Scrum 术语（潜在的可交付用户）对于每个产品，首席 PO 在教育和保护 PO 免受对 Scrum 框架知之甚少的利益相关者和成员的影响方面发挥着至关重要的作用。他们保护 PO 不被劫持。每个 PO 都有自己的 Scrum 团队。我建议首席 PO 是一位在组织中具有良好地位的敏捷教练，并且将 PO 放在一起，这尤其有助于解决跨团队依赖性和问题
In a Scrum or Agile team is it advisable for a Product Owner to be involved in more than one product?
First of all you have to understand that you won't have an objective answer to this in Scrum. You will have to inspect and adapt. Nowhere in the Scrum Guide (written by the inventors of Scrum) is it mentioned that a PO should not handle more than 2 products but they do mention that for the PO to succeed (s)he has to take full responsibility of the Product, and the organisation has to respect the POs decision.The PO is a "pig" of the Product Backlog, be it for 1 or 2 or more products, if the PO and the Stakeholders can handle this I would say try it, and inspect and adapt. And there are various factors also like how complex the products are, and how speacialised the Product Owner is in them and how much bandwidth the PO has to do the PO duties for more than one product. Please take all of them into consideration before trying it.
Is it good to have a Product Owner for the Enterprise System and "sub" Product Owners for the components of that system? i.e. In a Retailer would you have a PO for the enterprise system that drives "sub" PO's for say Retail, Supply Chain and Manufacturing?
Again you will have to try it in your organisation to know if it is "good". Just follow the right Scrum guidelines when appointing the POs or sub POs. I tried it in my organisation and it worked wonders! We had a Chief PO, and several other POs who you may call sub POs but I prefer keeping everyone on the same level to avoid command and control behavior which when misused can ruin a project. The Chief POs job would be to make sure the POs are successfull in what they do, and also help the POs out when needed. Also appointing POs could be done by Chief PO along with a chief SM or SM. If I may digress a little, the same structure was followed with SMs. The Chief SMs job would be to help the SMs succeed at doing their job, for example if an SM cannot resolve an impediment he or she could have the Chief SM come in to the picture to help resolve it.
Be interested in how others deal with Scrum teams in an enterprise environment with many stakeholders in functional silos.
Like I already mentioned above. We had a chief PO, and several other POs in our enterprise environment. There was also a steering committee which included stakeholders. Each PO had their own product backlog to manage. We had 2 week Sprints. Twice a month we had a meeting called the 'Steering Committee Meeting" where all stakeholders and Chief PO and POs met, and steered the Enterprise product in the right direction, and the each of the POs translated the work in Scrum terms (potentially shippable user stories) for each of their products, the Chief PO had a crucial role of educating and protecting the POs from the Stakeholders and members who had little knowledge of the Scrum Framework. They protected the POs from being hijacked. Each PO had an own Scrum Team with a SM and team members. I would suggest have the chief PO be an Agile coach with a good hold high up in the organisation. Also have the POs collocated, it helps especially in resolving cross team dependencies and issues.
Note: One thing that had not worked for us was 2 POs for one team with one product backlog, there were just too many conflicts between the POs!
另一种方法是将子项目分成单独的 Scrum 团队，然后形成“Scrum of Scrums”；但我认为这不适用于单个开发项目，因为这会在团队之间造成更困难的信息流。除非每个子项目可以彼此独立运行，否则我建议使用第一种方法。
I've been a ScrumMaster in a similar situation. You can have "sub" product owners or "joint" product owners for sub systems of your development effort; in an enterprise this is pretty common. They in essence become a "Product Owner Team", which may also include business analysts.
However you should have a designated 'lead' for this product owner team; someone who can settle differences and establish overall priorities for the backlog This person should make sure that the needs of all the other product owners are met. In practice, this has usually been the project manager.
An alternate approach is seperating the sub-projects into seperate scrum teams, and then have a 'scrum of scrums'; but I don't think that will work for a single development project, as that will create more difficult information flow between the teams. Unless each sub project can function independently of each other, I'd suggest the first approach.
In a Scrum or Agile team is it advisable for a Product Owner to be involved in more than one product?
As long as the PO is able to work on the Product Backlog(s) to get a set of prioritized Product Backlog Items before each Sprints, is maximizing the ROI, and is available for the Team(s) during the Sprint (in other words, as long as the PO is doing his job), it should be ok. If he is not, major impediments will be raised quickly.
Is it good to have a Product Owner for the Enterprise System and "sub" Product Owners for the components of that system?
This is actually a typical pattern when using Scrum of Scrums to scale Scrum. And scaling Scrum to a entire company is definitely doable (Scrum has been designed for infinite scalability --Jeff Sutherland), and Scrum has already been used with huge teams (500+ people).
But I would certainly not try to scale Scrum to a whole company directly, there are steps to follow for Enterprise wide Scrum/Agile deployment and not doing so would be crazy (a good recipe for failure).
Rally has IMO awesome presentations, white papers and blog posts on this topic (well, they aren't the only one but I enjoyed reading their material). I warmly suggest to have a look:
A product owner can be in this role for multiple products, depending on their size. On the other side, you can have multiple product owners for sub components of a larger enterprise application. Then you have a "Chief Product Owner".
发布评论
评论（4）
首先你必须明白，在 Scrum 中你不会对此有一个客观的答案。你必须检查并适应。 Scrum 指南（由 Scrum 发明者编写）中没有提到 PO 不应处理超过 2 个产品，但他们确实提到，为了使 PO 成功，他必须对产品承担全部责任，并且组织必须尊重 PO 的决定。PO 是产品待办事项列表中的“猪”，无论是 1 个还是 2 个或更多产品，如果 PO 和利益相关者可以处理这个问题，我会说尝试一下，然后检查和调整。还有各种因素，例如产品的复杂程度、产品负责人的专业化程度以及 PO 必须为多个产品履行 PO 职责的带宽有多少。在尝试之前请考虑所有这些。
同样，您必须在您的组织中尝试一下才能知道它是否“好”。在任命 PO 或子 PO 时，只需遵循正确的 Scrum 指南即可。我在我的组织中尝试过，效果非常好！我们有一个首席 PO 和其他几个 PO，您可以将他们称为子 PO，但我更喜欢让每个人都处于同一级别，以避免命令和控制行为，如果滥用，可能会毁掉一个项目。首席 PO 的工作是确保 PO 成功完成其工作，并在需要时为 PO 提供帮助。任命 PO 也可以由首席 PO 和首席 SM 或 SM 一起完成。如果我可以稍微离题一下，SM 也遵循相同的结构。首席 SM 的工作是帮助 SM 成功完成其工作，例如，如果 SM 无法解决障碍，他或她可以让首席 SM 介入帮助解决。
就像我上面已经提到的那样。我们的企业环境中有一位首席 PO 和其他几位 PO。还有一个包括利益相关者在内的指导委员会。每个采购订单都有自己的产品待办事项列表需要管理。我们进行了两周的冲刺。我们每个月召开两次名为“指导委员会会议”的会议，所有利益相关者以及首席 PO 和 PO 都会开会，引导企业产品朝着正确的方向发展，每个 PO 都将工作翻译成 Scrum 术语（潜在的可交付用户）对于每个产品，首席 PO 在教育和保护 PO 免受对 Scrum 框架知之甚少的利益相关者和成员的影响方面发挥着至关重要的作用。他们保护 PO 不被劫持。每个 PO 都有自己的 Scrum 团队。我建议首席 PO 是一位在组织中具有良好地位的敏捷教练，并且将 PO 放在一起，这尤其有助于解决跨团队依赖性和问题
。对我们来说，没有工作的是一个团队有 2 个 PO，只有一个产品待办事项列表，PO 之间存在太多冲突，
希望这会有所帮助。
First of all you have to understand that you won't have an objective answer to this in Scrum. You will have to inspect and adapt. Nowhere in the Scrum Guide (written by the inventors of Scrum) is it mentioned that a PO should not handle more than 2 products but they do mention that for the PO to succeed (s)he has to take full responsibility of the Product, and the organisation has to respect the POs decision.The PO is a "pig" of the Product Backlog, be it for 1 or 2 or more products, if the PO and the Stakeholders can handle this I would say try it, and inspect and adapt. And there are various factors also like how complex the products are, and how speacialised the Product Owner is in them and how much bandwidth the PO has to do the PO duties for more than one product. Please take all of them into consideration before trying it.
Again you will have to try it in your organisation to know if it is "good". Just follow the right Scrum guidelines when appointing the POs or sub POs. I tried it in my organisation and it worked wonders! We had a Chief PO, and several other POs who you may call sub POs but I prefer keeping everyone on the same level to avoid command and control behavior which when misused can ruin a project. The Chief POs job would be to make sure the POs are successfull in what they do, and also help the POs out when needed. Also appointing POs could be done by Chief PO along with a chief SM or SM. If I may digress a little, the same structure was followed with SMs. The Chief SMs job would be to help the SMs succeed at doing their job, for example if an SM cannot resolve an impediment he or she could have the Chief SM come in to the picture to help resolve it.
Like I already mentioned above. We had a chief PO, and several other POs in our enterprise environment. There was also a steering committee which included stakeholders. Each PO had their own product backlog to manage. We had 2 week Sprints. Twice a month we had a meeting called the 'Steering Committee Meeting" where all stakeholders and Chief PO and POs met, and steered the Enterprise product in the right direction, and the each of the POs translated the work in Scrum terms (potentially shippable user stories) for each of their products, the Chief PO had a crucial role of educating and protecting the POs from the Stakeholders and members who had little knowledge of the Scrum Framework. They protected the POs from being hijacked. Each PO had an own Scrum Team with a SM and team members. I would suggest have the chief PO be an Agile coach with a good hold high up in the organisation. Also have the POs collocated, it helps especially in resolving cross team dependencies and issues.
Note: One thing that had not worked for us was 2 POs for one team with one product backlog, there were just too many conflicts between the POs!
Hope this helps.
我担任 ScrumMaster 时也遇到过类似的情况。您的开发工作的子系统可以有“子”产品所有者或“联合”产品所有者；在企业中，这种情况很常见。他们本质上成为一个“产品负责人团队”，其中可能还包括业务分析师。
但是，您应该为该产品负责人团队指定一名“领导”；能够解决分歧并确定待办事项的总体优先级的人 此人应确保满足所有其他产品负责人的需求。实际上，这通常是项目经理。
另一种方法是将子项目分成单独的 Scrum 团队，然后形成“Scrum of Scrums”；但我认为这不适用于单个开发项目，因为这会在团队之间造成更困难的信息流。除非每个子项目可以彼此独立运行，否则我建议使用第一种方法。
I've been a ScrumMaster in a similar situation. You can have "sub" product owners or "joint" product owners for sub systems of your development effort; in an enterprise this is pretty common. They in essence become a "Product Owner Team", which may also include business analysts.
However you should have a designated 'lead' for this product owner team; someone who can settle differences and establish overall priorities for the backlog This person should make sure that the needs of all the other product owners are met. In practice, this has usually been the project manager.
An alternate approach is seperating the sub-projects into seperate scrum teams, and then have a 'scrum of scrums'; but I don't think that will work for a single development project, as that will create more difficult information flow between the teams. Unless each sub project can function independently of each other, I'd suggest the first approach.
只要 PO 能够在每个 Sprint 之前处理产品待办事项列表以获得一组优先的产品待办事项列表项目，即可最大化投资回报率，并且在 Sprint 期间可供团队使用（换句话说） ，只要 PO 尽职尽责），应该没问题。如果他不这样做，重大障碍将很快出现。
这实际上是使用Scrum of Scrums 来扩展 Scrum。将 Scrum 扩展到整个公司绝对是可行的（Scrum 专为无限可扩展性 --Jeff Sutherland），并且 Scrum 已经在大型团队（500 多人）中使用。
但我当然不会尝试直接将 Scrum 扩展到整个公司，企业范围内的 Scrum/敏捷部署需要遵循一些步骤，不这样做就会很疯狂（这是失败的一个好方法）。
Rally 有关于这个主题的 IMO 精彩演示文稿、白皮书和博客文章（嗯，他们不是唯一的，但我喜欢阅读他们的材料）。我强烈建议您查看：
我很确定在阅读其中一些资源后您会有更好的了解。但我并不是说这很容易。
As long as the PO is able to work on the Product Backlog(s) to get a set of prioritized Product Backlog Items before each Sprints, is maximizing the ROI, and is available for the Team(s) during the Sprint (in other words, as long as the PO is doing his job), it should be ok. If he is not, major impediments will be raised quickly.
This is actually a typical pattern when using Scrum of Scrums to scale Scrum. And scaling Scrum to a entire company is definitely doable (Scrum has been designed for infinite scalability --Jeff Sutherland), and Scrum has already been used with huge teams (500+ people).
But I would certainly not try to scale Scrum to a whole company directly, there are steps to follow for Enterprise wide Scrum/Agile deployment and not doing so would be crazy (a good recipe for failure).
Rally has IMO awesome presentations, white papers and blog posts on this topic (well, they aren't the only one but I enjoyed reading their material). I warmly suggest to have a look:
I'm pretty sure you'll get a better picture after reading some of these resources. But I'm not saying this is easy.
产品负责人可以针对多个产品担任此角色，具体取决于产品的规模。另一方面，您可以为大型企业应用程序的子组件拥有多个产品所有者。那么你就有了一位“首席产品负责人”。
这是完全有效且可取的。
所有这些概念均在《使用 Scrum 进行敏捷产品管理：创建客户喜爱的产品》一书中详细介绍。 /a> 由罗曼·皮克勒编写。
我在 Scrum Gatherings 上多次看过他的演讲并与他交谈过。他的专业是产品负责人。
A product owner can be in this role for multiple products, depending on their size. On the other side, you can have multiple product owners for sub components of a larger enterprise application. Then you have a "Chief Product Owner".
It's perfectly valid and advisable.
All those concepts are detailed in the book Agile Product Management With Scrum: Creating Products That Customers Love written by Roman Pichler.
I've seen hi speechs and talk to him many times at Scrum Gatherings. His specialization is Product Owners.