This is probably too complex a thought for a tweet, but it's best if you have a single *product* backlog (no team-level backlogs) and a single PO for the entire product (no team-level POs). Here's why: 1/10
Sort your product backlog by value: (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ) 2/10
Shuffle the first 12 of those items out to three teams A:(1 4 7 10) B:(2 5 8 11) C:(3 6 9 12) 3/10
If all three teams work at exactly the same rate, then you'll always be working on the most valuable stuff. However, let's say that team A—your best team—retires all its items and the other teams retire only two. Team A pulls four more items off the product backlog: 4/10
A:(13 14 15 16) B:(8 11) C:(9 12) 5/10
At this point, team A—your best team—is doing nothing but low value work, and the delivery of the higher-value work is being delayed because it's sitting in the backlogs of teams B and C. 6/10
You could solve that problem by having A pull work from B and C's backlog, but that's getting pretty complicated. If there's only a single product backlog from which all teams pull, you don't have this problem at all. 7/10
NOWHERE in the Scrum Guide does it say that you must have a single PO per team. Many very functional Scrum shops have a single PO for the entire product. That way, there's a single decision maker. 8/10
If the team's have POs at all, their main job is to answer questions and make decisions during development, but if you have a small number of team (say 4-6) working on a single product, one PO can handle the job just fine. 9/10
Note that I'm assuming a competent PO who's not wasting time creating detailed up-front designs in Jira. Stories stay at the 2-3 sentence level until they're pulled into a Sprint for development, and only then are the details are flushed out in Sprint planning. 10/10
