Large Group - How to split

Regardless of how you decide to organize your team, there's a risk of either bottlenecks or idle people. I would strongly recommend that the team find opportunities to cross-train individuals. You should not have 2 backend/API developers and 7 mobile developers. You may have 7 mobile development specialists, but they should be able to pick up and complete backend/API work if that means delivering higher-value work and taking on full slices. Similarly, having dedicated testers could lead to bottlenecks, so the developers should participate in both automated test development and manual test execution. Specialists should help others in their specialty level up.

That said, there are a few options.

First, the recommended size for the Scrum team has been removed from the current (2020) version of the Scrum Guide. The 2017 Scrum Guide suggested that 9 Developers is likely the maximum size for a Scrum Team, and in your team, your 9 developers and 5 testers would make 14 Scrum Developers. Team size is often dependent on context. One indicator that the team is too large is that the Scrum events (especially the Daily Scrum and the Sprint Retrospective) can't be completed within their timeboxes. If the team can complete the events within their timeboxes, you may not need to split yet.

If you do decide to split, a more dynamic approach may work. This approach is based on Helfand's Dynamic Reteaming and FAST Agile. Willem-Jan Ageling called this "Fluid Scrum Teams". At each Sprint Planning, the team would decompose into smaller teams with the skills needed to achieve a particular goal, and each team would have its own Daily Scrum. You could consider taking advantage of concepts from a scaling framework like LeSS to organize: decompose in Sprint Planning 1, sub-team planning in Sprint Planning 2, come together for the Sprint Review, then have sub-team and whole-team Sprint Retrospectives.

You have 14 Developers, in Scrum parlance (2 backend, 7 mobile, 5 testers) plus a Scrum Master and a Product Owner.

If all devs are equally capable in their domain area, e.g., either backend dev can do whatever backend development that is required, then you can create two teams, each of which has a backend dev, and then split the mobile devs 3 and 4, and put 3 testers with the 4 devs and 2 testers with the 3 devs. The Scrum Master and Product Owner would hold their roles for both teams. That would give you two teams, as follows:

Team 1

• 1 backend dev
• 3 mobile devs
• 2 testers

Team 2

• 1 backend dev
• 4 mobile devs
• 3 testers

This should give you two teams with roughly equivalent capabilities, each of which could implement stories with either frontend, backend, or both types of work.

Or, you could put both backend devs on one team with three mobile devs, and 3 testers, and have the other team have 4 mobile devs and 2 testers. You should be staging stories for upcoming sprint reviews during refinement; any stories that would need backend work would be slotted for the team with the backend devs.

For refinement, you could have a backend dev, a couple of frontend devs, and a couple of testers. Remember, the goal for refinement is to get stories to where they can be brought into sprint planning ('ready') with a shared understanding between team and PO of what 'done' looks like functionally via acceptance criteria, and that the team is certain can be implemented in the sprint without outside assistance.

I don't support the idea of regularly mixing up Scrum teams (moving people from team to team). Instead, I support the principle of moving work to people, not people to work. If there are specialized capabilities, then part of refinement is determining what teams should work on what stories. Implementing stories in Scrum is a team activity, and stories should be designed so that more than one Developer (not developer) can work on the story simultaneously, e.g., testers can start creating tests based on acceptance criteria while devs start working on code.