Sharing the same scrum scope between several scrum teams, just for the sake of dividing the workload, is against the scrum spirit and it is doomed to fail.
In addition, developers are not just an interchangeable capacity to process user stories: developers build up knowledge during each sprint and share it within the small team. This knowledge must remain available in the subsequent sprints for ensuring sustained efficiency.
You will certainly be disappointed to hear this. But fortunately there's some hope on the side of Nexus, if you're ready to adapt a little bit your approach.
Detail: why is it against the scrum principles ?
The issue with the PO
Scrum is based on the assumption that one Product Owner (PO) is totally in charge of the product in scope and decides about priorities. According to the Scrum guide:
The Product Owner is responsible for maximizing the value of the
product resulting from work of the Development Team.
The Product Owner is the sole person responsible for managing the
In your situation the single PO is a bottleneck. So you want to have several PO. But then the POs are no longer the sole responsible. And if there are several POs, do they all have the same understanding (and ownership) of the product ?
A couple of periodic meetings will not solve this issue. Either there will be three POs owning the product with necessarily a different understanding of the product. Or there will be one PO and two assistant POs who no longer have the required power. This will no longer be Scrum.
The issue with the teams
One of the principle in Scrum, is that the teams are autonomous, organise themselves, and have all the skills to succeed. Some quotes from the Scrum guide:
teams have all competencies needed to accomplish the work without
depending on others not part of the team.
Scrum recognizes no sub-teams in the Development Team
accountability belongs to the Development Team as a whole.
De facto, your organisation is to have three subteams that are co-responsible for the overall product.
Making several teams working on the same scope just for splitting the workload, will result in one team being dependent from another (for example if a team has to develop a refinement of a user story made by another team). You will lose all the synergies that Scrum tries to achieve.
Scaling Scrum is not a problem !
Scrum of Scrum
The scrum of scrum is the most common approach. There are several teams (and hence several PO), but each is responsible for one sub-product. Of course there could be some overlap between the teams, but it's limited to the frontier between sub-products and well managed in the scrum of scrum. Reported scalability is beyond 200 and up to 1000 team members.
Nexus: a solution for you ?
The Nexus approach is closer to what you are looking. It was developed by the inventors of Scrum.
A Nexus has one single PO (and hence clear ownership of the product) and a single SM, but several integrated teams. The approach addresses in detail the inter-team integration and synchronisation across the full Scrum process. For this purpose it uses a tightly coupled integration team (more tightly coupled than scrum of scrum).
The backlog is split between the teams so to minimize dependencies (so to increase autonomy of each team). You will be pleased however that there is no requirement to identify different sub-products. Nevertheless, this approach takes account of the knowledge building aspect I've mentioned earlier:
To the extent that requirements, team members’ knowledge, and
code/test artifacts are mapped to the same Scrum Teams, dependency
between teams can be reduced.
The reported scalability is three to nine scrum teams, meaning 9x9+2=83 persons.