我们有一个开发团队（大约20个团队成员）目前从事5个产品，其中5个产品（每个产品）。我们正在为不同产品与许多会议之间的故事优先级斗争。
以下是我们正在查看的两个选项：
1。将产品积压合并到单个产品积压
，团队可以将故事从一个产品积压的故事中吸收到Sprint Backlog。（并且不必再考虑优先事项）。但是单个产品的积压可能太大且难以管理。
2。将团队分成5个团队
，但这是不可能的，因为我们有资源专门为特定的煎锅，需要在产品中共享。
有什么建议？
我建议第三个选项。
围绕产生最多工作的产品组成的团队。然后让其余的开发人员在覆盖其余产品的团队中工作。
类似：
团队1-产品1
团队2-产品2
团队3-产品3、4、5
希望这将减少故事优先级的斗争（尽管并非完全消除）。
最重要的是确定您想通过新的组织结构以及您打算如何衡量成功的收益。
获得一些合适的指标，尝试新结构，看看指标是否会变得更好或更糟。然后检查并适应您的方法。
我有几件事要指出，任务优先级根本不责任开发团队，这是是由于多种原因由PO管理的东西，但不要对此进行讨论。
由于您没有一个PO，因此在一场利益之战中转变。如果他们之间没有共同的目标，那么每个PO都希望他们的我们尽快完成，因为这是他们的最高优先事项（这是完全可以理解的）。
因此，如果您想保留一个团队来保留所有这些产品单一产品因此，开发团队不必在冲刺中间改变其"环境"（但这是一个奖励点，而不是强制性的）。
最主要的是，如果有可能拥有这个单个PO来管理此单个积压，那么最终与您当前的5个POS成为利益相关者一样，他们会要求他们想要什么，而这个单一的PO将会将这些东西整理好。基于什么 ？可能需要公司，如果存在阻塞问题，或者可能像金钱一样容易……谁是付款最多的人，那就是您将首先参加的。
在简历中，删除从团队中挑选要开发的任务的责任，可以通过这种单一PO方法，通过PO之间的论坛，他们一起管理单个产品的积压。那是我的两个命题。
有太多因素，公司，POS共享的愿景和需求，为什么有1个单一团队正在管理这一切。等等。
我们目前正在与一个团队合作以购买多种产品，我们只有一个PO和一个产品积压，而且情况顺利。
希望这会有所帮助！毫无疑问，请告诉我！
这是一个常见的问题，可以通过纪律和团队工作来解决这个问题。
5个产品的接缝类似于20人，希望其中一些工作是相似的，您可以将其包括在一起。我会鼓励小组组成少数6 -3的团队，并让他们选择如何最好地完成工作。
如果您有一个自组织的团队组，他们将能够弄清楚如何交叉训练足够多，以至于您将不需要这么多专家。请查看Scrum指南（http://www.scrumguides.org/），并关注其中的指导校长。
我将首先做出一些假设：
- 产品与众不同 - 例如如果您的公司生产人力资源软件，则产品可能是时间表，培训，绩效管理等...
- 产品之间有一定数量的共享代码。登录，登录，部署等...
- 有可能拥有较小的团队，这些团队具有运输产品功能所需的技能。
- 产品所有者能够理解产品功能的业务价值并优先协商。
在这种情况下，我会...
- 分成3个6/7的团队 - 这是足够的人，具有完成重要功能的技能。
- 有3个团队"拥有" 1或2个产品 - 这是为了使团队能够真正理解并为产品的长期视野做出贡献，并确保将技术积压项目适当地优先考虑产品价值。
- 对每个团队都有一个积压 - 产品主和团队拥有的。
- 具有一种明确的方法，产品所有者用来优先考虑功能 - 例如业务价值，WSJF，Kano等...同意这一点并将其写下来可能有助于停止有关该方法的争论
- 有3个团队协调共享代码的更改 - 也许是内部源类型方法。
- 有一名教练帮助团队和利益相关者进行变更。
也许打开太多前部？退后一步，重新审视您的公司目标，考虑降低期望并相应地重新组织团队。如果您推迟使用产品并制作4种产品而不是5种产品，这不是世界的尽头。这将为您提供其他产品的良好增长。要聪明，选择战斗。您不需要与每场战斗进行战斗。