Two Product Owners, one product, 70 duplicate backlog items
Two Scrum Teams, six Developers each, build one product: a mobile banking app with a shared codebase and a single production release every three weeks. Each team has its own Product Owner, its own Product Backlog and its own Sprint cadence. Last quarter they shipped duplicate notification preferences - both teams built one - and the login screen and the fraud-check screen disagreed on token expiry for eleven days. Two releases were rolled back. Stakeholders now send requests to whichever PO replies first. You are Product Owner for Team A. The new CTO asks you to 'fix the backlog problem' before the next release. Team A's backlog holds 180 items; Team B's holds 240; roughly 70 items appear on both, worded differently, with different acceptance criteria. Both teams are competent and neither wants to give up its own backlog. There is one Product Goal on paper - 'account opening in under four minutes' - but neither backlog is ordered against it.
1. Judged against Scrum, what is structurally wrong here?
Read the worked answer
The product is the unit of structure, and this organisation has split the wrong thing.
- One product should have one Product Backlog. Two backlogs on one codebase mean there is no single ordering, so 'maximise value' has no meaning - two people optimise their own lists and the duplicates are the predictable result.
- One Product Owner per product. Scrum assigns accountability for effective Product Backlog management to a single person who may delegate the work but never the accountability. With two POs, the 70 overlapping items have two owners and therefore no owner.
- The Product Goal is decorative. A Product Goal is a commitment the backlog is ordered against. Here it sits on a slide while both backlogs are ordered by whoever shouted last.
- No single intake channel. Requests going to whichever PO answers first means stakeholders are effectively ordering the backlog - the accountability has leaked outside the role.
- No shared Definition of Done for integration. The token-expiry mismatch is an engineering symptom, but it reaches you because it prevented a releasable Increment - the thing a Product Owner is accountable for producing value from.
The trap in the question: the teams' wish to keep separate backlogs is not autonomy. Autonomy is about how the work is done, not about owning a private list of what the product should be.
2. You cannot change the org chart this quarter. What concrete steps do you take in the next four weeks?
Read the worked answer
Work on the artefact first, the org chart later.
Week 1 - one list, one accountable name. Create a single Product Backlog in one tool and agree with the CTO who is accountable for ordering it. If that is you, the other PO becomes a delegate for a domain area - legitimate, because Scrum allows delegation of backlog work while accountability stays in one place. Announce one intake channel for stakeholders and a published ordering rationale.
Week 1–2 - deduplicate. Run a joint session with two Developers from each team over the 70 overlaps. One description, one set of acceptance criteria per item; delete the rest. Expect this to take four to six hours and to be unpopular.
Week 2 - order against the Product Goal. Sort the combined list top-down against 'account opening in under four minutes'. Everything below the next two Sprints' worth goes below the line and stops being discussed.
Week 2–3 - joint refinement and a shared Definition of Done that includes integration tests. The token-expiry bug is not a backlog item; it is a missing quality standard.
Week 3–4 - one Sprint Review with both teams demonstrating one Increment, run as a working session.
Measures: duplicate features shipped = 0, rollbacks = 0, percentage of the top ten items with agreed acceptance criteria before development, and average feedback-to-decision time for stakeholders.
3. How do you consolidate the backlog without stripping the teams of their autonomy?
Read the worked answer
Separate the two things the word 'autonomy' is doing here.
What the Developers keep, unchanged:
- Their own Sprint Backlog, drawn from the single Product Backlog. Two Sprint Backlogs against one product backlog is entirely normal; two Product Backlogs against one product is not.
- Selection at Sprint Planning within the ordering, including the right to push back with evidence.
- All decisions about how: design, task breakdown, estimates, internal quality standards, and additions to the Definition of Done.
What changes:
- They no longer own a private list of what the product should be. Frame consolidation as removing duplicate work - the notification-preferences double build was two teams doing the same job and neither getting credit.
- The Product Owner does not assign tasks, does not estimate, and does not sit in the daily Scrum directing flow. You attend refinement and review as the voice of what and why, and you are reachable for clarification.
Keep the local identity alive: shared backlog, but each team keeps its own Sprint Goal derived from the Product Goal, its own retrospective, and its own improvement actions. Run a joint retrospective in week four on how the single list is working.
The honest argument to make to the teams: the rollbacks and the eleven-day token mismatch were caused by the split, not by a lack of skill. Autonomy that produces a broken release is not autonomy the business will tolerate for long.