你如何知道什么时候需要扩大资源，什么时候需要挑战价值和优先级
我们的4个产品团队都有很大的需求。
我们的POs目前管理着pbi，我们确保根据我们在之前的sprint中学习到的当前速度将项目放入sprint backlog中。
然而，我们完成工作的速度赶不上需求增长的速度。
我认为这里有两个需要考虑的问题，一是我们的工作流程/方式是否有效(例如，目前我们几乎没有自动化测试)?这可能不是我们想要解决的问题，但考虑到外部需求，这需要产能，尽管它可能会有长期利益，但这很难实现。另一个问题是，我们是否可以扩大我们的团队以增加能力(知道最初这可能会影响团队效率)，以获得中长期收益。
我们目前受到招聘冻结的限制，但我正在寻找社区推荐的潜在工具，以帮助团队增加资源，一些切实的而不是传闻的东西。亚博一百送一百任何意见都将不胜感激。
我们的POs目前管理PBIs
这就是你的问题。产品负责人仅仅管理pbi是不够的。他们必须管理产品待办事项列表本身。
例如，这包括在订购产品待办事项列表时考虑速度，从而优化价值交付。聪明和深思熟虑节流的需求可能包括与团队的讨论减少速度，暂时的，因此可以启用自动化，并实现长期价值。
你特别要求的
帮助证明团队增加资源的工具
你能否提供更多的信息，说明是什么导致你增加资源作为解决方案?
根据您当前的团队规模、配置等，建议实际上可能与您的要求背道而驰，包括减少团队规模，或使用更小的专注团队，甚至使用缩放框架(如Nexus)来帮助管理依赖关系和集成。
布鲁克定律:“将人员添加到一个延迟的软件项目中会使它变得更晚”
我目前服务的团队遇到了这种情况。团队成员被注入到团队中，而没有团队的投入，这实际上导致我们放慢速度并交付更少的价值。注意力受到了影响，工作被遗漏了，因为人们认为其他人已经完成了工作，沟通变得繁琐，活动和会议运行得太长。这需要一些工作，但我们获得了精简团队的支持，这导致了更好的专注和更多的价值交付。不幸的是，在我们的组织中有很多这样的例子，团队增加了更多的人来解决问题，结果发现事情变得更糟，再增加更多的人，结果就更糟了。
对于你的4个产品团队:每个团队都专注于自己独特的产品吗?每个公司都有自己的产品、产品负责人、Scrum管理员和开发人员?目前的团队规模是多少?在这种情况下，产品团队之间是否存在人员共享?如果是，分配是什么样的，是否考虑了上下文切换的成本和对其重点的影响?
还有伊恩说的话。
谢谢Ian和Ryan的评论。
目前，我们从外部承包商那里增加了能力，但这种资源是有限的。他们很可能在今年年底离开我们，而且无人替代。
我们的团队在4-7人之间(不包括外部人员的4-5人)。
Ryan，你关于专注团队的观点很有趣，我们在一个有很多方面的平台上工作，这些方面已经被分组到我们的产品中，一些更适合于专注产品，而一些可能不太符合逻辑的分组。在理想的情况下，我们会把平台分成4个以上的产品，让专注的产品团队更加专注，但回到我最初的观点，我们受到资源的限制。4xPOs 17xDevs和1xSM。
我面临的挑战是，我如何证明再得到两个短信是有益的，或者如果我们将“产品X”分成产品“X和Y”，并带来另一个订单，那么我们将在这些领域看到切实的结果。
我的下一步打算做一个实验，把一个产品分成两部分，看看结果如何，但我担心这可能会让团队紧张，给他们带来更大的压力。
你可以考虑的一种方法是将你当前处境的挑战描绘出来或形象化。
在4个团队中使用一个SM意味着大量的上下文切换。环境转换的影响不应被忽视。一些研究表明，每次切换上下文约25分钟会产生影响。即使你把时间缩短到15分钟，只考虑一个SM可能支持4个团队的所有Scrum事件，大约50%的时间可以花在Scrum事件上(这取决于团队的成熟度)，仅这一点，21%的时间就浪费在上下文切换上。这就没有留给教练、组织支持、障碍消除支持等太多时间了。任何额外的活动只会增加上下文切换的浪费。可以创建一个简单的电子表格来帮助计算上下文切换的成本，并用于演示场景。这是我在自己的组织中用来帮助说明共享团队成员的低效率的方法。
我想知道如何分割你们的产品。还有其他方法可以缩小关注范围。你可以有一个产品，有一个产品负责人和多个Scrum团队。想象你正朝着一个产品目标努力。每个团队将在每个Sprint中专注于实现目标的不同具体步骤。每个人都有自己的Sprint目标，但仍然致力于相同的产品，并朝着相同的产品目标前进。如果超过3个团队，您可能需要考虑利用Nexus。
想法吗?