我们是否拉起PBI以使所有团队忙碌？
当我们查看新的产品待办事项列表时，我们发现排名前20位的PBI将填补此空白 发布，但是排名前20的PBI并不涉及10个团队中的3个。 PB后面的一些PBI确实参与了这些团队，但要使他们交付，他们将需要（依赖）前20名中已经忙碌的团队，这是不可能的。
解决方案是什么？常识表明，所有团队必须保持忙碌，但这与总体产品优先级相冲突。
答案 0 :(得分：0)
听起来您有两个问题之一：要么您的团队非常孤岛，要么您的架构轮廓不可持续。在试图快速交付产品时，任何一种都会给您带来麻烦。
虽然您当然可以在待办事项列表中进行进一步介绍，但我也将考虑寻找可以减轻瓶颈的方法。交叉培训能否帮助您将来避免这种情况？在这段时间内您是否可以克服结构性障碍？
我认为团队的忙碌实际上并不重要。相反，重要的是团队必须继续生产-在短期和长期内，什么措施可以使生产更快地发生？
答案 1 :(得分：0)
我认为您的问题指向答案。
排名前20的PBI不涉及10个团队中的3个
Scrum和敏捷与适应变化有关。当团队变得过于专业并且无法在某些PBI上工作时，这将非常困难。也许值得一聚并讨论引入更多灵活性的方法吗？
但要使他们能够交付，将需要依赖前20名中已经忙碌的团队，这是不可能的
消除PBI之间的依赖性将使您的生活更加轻松。它将为您提供灵活性，使您的团队得到充分利用。考虑一下编写PBI的方式以及组织团队的方式，以使依赖关系不再是问题。
答案 2 :(得分：-1)
如果您组织成团队，则很可能会阻塞团队或专注于各自组件中较低价值PBI的团队之间的依赖。
我想您可能想开始过渡到feature teams。
功能团队：团队具有必要的知识和技能，可以完成以客户为中心的端到端功能。如果不是这样，则期望团队学习或获得所需的知识和技能。
...
向功能团队过渡：不同的组织在需要时需要不同的过渡策略 从组件团队转变为功能团队。我们有很多经验 在不同情况下有效但失败的策略。安全—但是 慢-过渡策略是在内部建立一个功能小组 现有的组件团队组织。在这支队伍表演之后 好，成立了第二个功能团队。这种情况在 加快组织适应的速度。
答案 3 :(得分：-1)
我为您提供2个答案。
1 /纯agilist方法：
花一天的时间，召集所有团队的所有成员并信任他们找到解决方案。
他们比我们更了解步骤和障碍。解决方案可以在外部找到，但必须在内部找到。
别忘了，您的工作就是以团队的责任心和创造力来开发软件
为了提供帮助，有很多帮手。对于大型团体，我倾向于根据需要使用“解放结构”，确定优先级，进行工作并进行循环
2 /更传统的方式：
您必须将您的团队转变为功能团队，以减少依赖性。
毫无疑问，这是一项艰巨的任务。您可能必须更改架构。作为功能专家，我的建议是首先拆分数据库。这是一项艰巨的工作，但它却带来了丰厚的回报，这确实使您的团队以一种特色方式工作。 DB通常是您的瓶颈，但是我们又一次不知道您的情况。您的团队知道！
当您处于单独的功能中时，它更容易分离积压，然后更容易分离PBI
答案 4 :(得分：-1)
我可以建议以下内容。