One Product Owner, two teams, 180 specifications
A single Product Owner supports two Scrum Teams (five Developers each) building an internal claims platform. The Product Backlog holds 180 items, most written as four-page specifications the Product Owner produces alone before refinement. Refinement has been skipped in three of the last six Sprints because the Product Owner "had no time"; Developers say they only discover what an item means when they start it. Four department heads email the Product Owner directly and expect individual replies within a day; two have learned to escalate to the Product Owner's manager when their item is not ordered at the top. The Product Owner works 55-hour weeks and is now the bottleneck for every question the teams ask. Leadership proposes hiring a second Product Owner so each team has one.
1. Which parts of the Product Owner's work can be delegated, and which cannot? Be specific.
Read the worked answer
The line to draw. The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. Accountability can be supported by delegation of activities, but it is not transferred. The PO remains the single point at which ordering decisions are made, and must be one person rather than a committee.
Delegable (with the PO still answerable):
- Writing and refining Product Backlog items - Developers, a business analyst, or a domain expert can draft, provided the PO sets the intent and reviews the outcome.
- Stakeholder interviews, usage-data gathering, support-ticket triage: evidence collection.
- Facilitating refinement sessions.
- First-line response to department heads, with a published cadence instead of 24-hour personal replies.
Not delegable:
- The final order of the Product Backlog and the choice of Product Goal.
- Accepting or rejecting work against the Definition of Done at the Sprint Review (the PO is accountable for the value conversation here).
- Deciding what the product will not do - the refusal decision is the PO's.
Test to apply. If two people could give contradictory answers to a Developer and both be "right", the accountability has been delegated too far.
2. Evaluate leadership's proposal: a second Product Owner, one per team. What would you recommend instead?
Read the worked answer
Why the proposal is attractive. The PO is visibly overloaded, and one-per-team looks like symmetry.
Why it will make things worse. Both teams build one claims platform. Two Product Owners means two people ordering one product's backlog, or two backlogs that must later be reconciled. The department heads' escalation behaviour will not diminish - it will double, because there are now two people to lobby. The expensive symptom (conflicting priorities) is not caused by PO headcount; it is caused by an unclear decision structure and by a backlog the PO alone authors.
What to recommend instead.
- Retain one Product Owner. Split the work around that role: two Developers act as refinement leads for defined product areas, drafting items and running sessions; the PO sets intent, order and Product Goal.
- Fix the intake. Replace 24-hour personal email replies with a single visible Product Backlog and a published path for new requests. Escalation to the PO's manager should be answered by "is it in the backlog, and where is it ordered?"
- Restore refinement. Skipping it three times in six Sprints is a capacity and priority signal, not an accident - protect a fixed slot and make it the Developers' session with PO input, not the PO's performance.
- Kill the four-page specs. Detail written before discussion locks in solutions and is a major driver of the PO's hours.
When a second PO would be right. Only when there is genuinely a second product with a distinct customer and value proposition - not to reduce one person's inbox.
3. The Product Owner wants to cut the 180-item backlog to something manageable. What principles should guide that, and what is the risk?
Read the worked answer
Principle: the Product Backlog is ordered, not comprehensive. Its purpose is to be the single source of what might be done, ordered so the most valuable work is at the top. 180 items of equal apparent status is an ordered list only in name.
Practical approach.
- Establish and publish the Product Goal. Items that cannot be connected to it are candidates for deletion, not deferral.
- Treat the top ~2–3 Sprints of work as the refined set: small, understood, estimated, testable. Everything below is a placeholder - which is fine, as long as it is honest about being one.
- Delete rather than archive: duplicates, items older than a year nobody has asked for, and items whose requester has left. A backlog nobody prunes is a backlog nobody trusts.
- Order on explicit criteria (expected value, risk reduction, cost of delay, dependencies) rather than recency of complaint.
The risk to name out loud. Deleting items looks like losing commitments. Department heads who escalate will escalate harder when their item disappears. So the deletion must be accompanied by a visible, consistent explanation: the item is not refused, it is not now, and here is the criterion by which it would move up. Without that, the PO will be forced back into 180-item appeasement within a quarter.