表明上看，拆分团队是一个相对简单的任务。将团队成员分成两组，确保每组中都有相似经历的成员，明确新团队的目标。然而，在拆分团队时还有很多因素需要考虑进去以免影响团队以后的成功。
团队士气需要时刻牢记的最重要的事情之一就是团队士气。一天结束时，团队中的成员将不得不在新的组织架构中工作。如果团队在敏捷原则方面是成熟的，那么他们应该能够自己分裂。这是最理想的结果，因为团队成员最了解他们的内部关系——谁与谁关系最好以及谁能从分离的组织中收益。
跨职能团队Scrum推动跨职能团队“拥有创建产品增量所需的所有技能”。扩展到两个甚至更多团队时也是如此。对于很多开发者尤其是一些敏捷新手来说，自然趋势是与技术线路一起思考的。例如，团队经常想将拆分成前端和后端。这在某些罕见的情况下可能会有意义，但作为产品经理，你应该在大多数时间提出反对意见。一个全是前端开发者的团队无法自行提供产品增量并且自然地就开始思考技术能力也就是将他们团结起来的原因。相反，他们更应该关注的是客户以及如何满足他们的需求。
另一个有趣的考虑因素是团队中的非开发角色。在各种情况下，一个团队可能包括一个设计师、业务分析师和QA专家。一旦你拆分了一个团队，尤其是如果你没有雇更多的新人，那么在处理这些角色的问题上就会陷入两难的境地。他们应该分配自己的时间到不同的团队吗？你应该雇佣只服务于一个团队的新人吗？他们应该跟开发团队一起工作呢还是成为产品团队的一员？
对此并没有绝对的好建议因为每个产品都是不同的。这些决定最好与团队一起做出，同时记得需要一直不断修正。
如果一个团队被拆分，那么接下来的问题自然就是他们应该用同一个backlog工作还是再独立一个backlog出来。
Scrum@Scale是由Scrum指南的创建者开发的一种方法。Scrum@Scale不是很规范，但它确实指出了两点：
团队级别的流程跟Scrum指南中的流程相同。
产品负责人组成专门的产品负责人团队，在他们那里创建单一的backlog。这样做是为了避免重复工作，在公司范围内增强可见性。与此同时，团队从统一的backlog中提取各自的backlog。
所以，本质上来讲，Scrum@Scale描绘了新团队与他们各自的PO和backlog紧密配合的场景。只是添加了一些额外的结构来协调团队之间的工作。Scrum@Scale适合数个、数十个或数百个团队，但即使你们只有两个团队一起工作它也能提供一些有价值的见解。
大规模scrum（LeSS）
LeSS提供了一种有趣的产品backlog方法。在LeSS中，一个PO与2到8个团队一起工作。一个PO能跟那么多团队一起工作看起来有点不太可能。LeSS的理念是PO在抽象层面上工作，并将产品backlog项细化的职责委托给团队。这种情况下，跨职能开发团队还应该包括业务领域知识以便交付产品增量。在LeSS中，只有一个backlog。
如何保持更新？对于一个产品经理来说，多团队意味着更多的工作追踪和响应查询。
优先级会议如果你曾参加单个团队的每日站会，那么现在你可能会发现继续这个习惯很可能是徒劳的。将每日站会作为一个让他们了解团队动力并提醒他们可以进行讨论的机会。
你参加sprint规划会议与否取决于你团队的成熟度。如果团队中有很多新面孔或者他们已经很长时间没有用敏捷的方式工作了，那么你的指导就非常必要。即使你有信心让团队在没有你参与的情况下进行规划，如果出现问题请务必要在规划期间与团队进行交流或语音聊天。
Sprint review必须始终是你的首要任务，所有人都应该参加。Sprint review是一个能让你从所有在场的利益相关者和团队本身获得第一手反馈的机会。这是一个验证假设的时间，不应该错过。
你可能会减少某些scrum仪式的参与，但应该增加与scrum master间的合作。团队拆分后，肯定不止一个scrum master，这种情况下，你需要与他们所有人密切合作。
确保你可以信任他们，以便真实了解团队的进展及sprint期间出现的任何问题。这种关系可以帮助你了解最新进展并且无需参加所有的scrum仪式。
scrum of scrums 介绍
时候也称为元scrum，scrum of scrums是一个新的仪式，通常作为scrum流程规模引入。它是更高级别的站会的复制品。每个团队都指派一名大使，所有大使每天都在S0S会议上碰面沟通进展和阻碍。这个会议还用于突出可能需要解决的任何跨团队技术问题。
考虑扩充产品团队如果你的团队设置要求产品经理积极参与到团队中，那么请考虑在产品方面再添加一些人员。有几种方法可以解决这个问题：