With just two scrum teams, a true scrum-of-scrums may not even be needed. If your teams are co-located, they could do their daily scrum back to back and have a team member from the other team present to relay any important information. This becomes impractical after say 3 or 4 teams, which is when a SoS is a better solution (though scrum.org has started to recommend a concept called Nexus Daily Scrum, which is before, not after the normal daily scrums).
The biggest problem when going to two teams is that both teams still should produce only 1 integrated increment to the product they're building. This requires coordination between the teams and possibly collective effort to ensure that you end up with a releasable increment. Your development practices will also need to be adjusted to support this. With multiple teams it becomes even more important to focus on finishing what you started before picking up new work (a concept called Work in Process Limits from the Lean world applies in these cases).
Your product owner job will likely be a full-time role. One product owner for both teams is the recommendation from almost all agile practitioners. With two teams you will not yet need to delegate the role of the product owner as long as this person is available most of the time.
Another issue that will most certainly pop-up is cross team dependencies. You'll want to minimize these by the way work is ordered. If teams are heavily dependent on eachother it's far harder to operate as separate teams and you'll need a lot more cross team communication than when both teams can work mostly independent.
A common pattern is to have a single Sprint Review for the product if the teams are working on one product.
Another common pattern is to split the Sprint Retrospective into two parts, one focusing on how the teams work together, the other focusing on how each team works as a group. For the second part the teams each go into their own area or a private meeting room to ensure the trust level is maximized when talking about possible conflicts, ways to optimize and roadblocks.
On Refinement it helps to have a mix of both teams present. If you have been doing refinement with the whole team present, this may become too hard (too many people) and too expensive to invite everyone. It is important that outcomes and important choices are fed back into the teams so that everyone understands the reasoning behind the choices made. By having both teams participate together you ensure that any team potentially can pick up the work.
There is some good literature available on this topic and there is a lot of guidance to be found in the larger scaling frameworks. Just remember, since you're scaling small, a lot of these large practices will be overkill. After the team has split itself up, see where you can improve and look at the resources available to you in these larger scaling models to look for common patterns. Try them, see if they work for you. If they don't go back to the basics.
Scaling frameworks to investigate for common patterns:
- Scrum.org Nexus
- Less
- SAFe - I'd stay away from this for now, it's focused on so much larger organisations that you're likely to pickup bad habits, instead of good practices.
The authors of Less have written two books on agile scaling, they provide loads of experiments they've seen working in certain situations.
