The Proxy Product Owner and the Review Nobody Attends
At a financial services firm, one product is delivered by two Scrum Teams of eight developers each, sharing a single Product Backlog. The Product Owner is the Head of Digital, who attends no refinement sessions and has delegated all prioritisation to a business analyst she calls the "Proxy PO"; the analyst can rank items but cannot approve anything above a fixed cost threshold. Each Daily Scrum runs 25 minutes: developers report in turn to the Scrum Master, who updates the board and assigns the day's tasks. The Sprint Review is a demonstration to the Product Owner only - no other stakeholders have attended in the last four Sprints. The Definition of Done stops at "merged and unit tested"; a separate controls team performs regulatory checks after the Sprint, before release. Sprint length is three weeks. Retrospectives are held every second Sprint because "fortnightly is too expensive".
1. Sort the symptoms into (a) clear deviations from the Scrum Guide, (b) symptoms whose real problem is a missing commitment, and (c) legitimate choices you should leave alone. Justify each placement.
Read the worked answer
(a) Clear deviations. The Daily Scrum is for the developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog; a 25-minute round-robin reporting to the Scrum Master, who then assigns tasks, replaces self-management with direction and empties the event of its purpose. The Retrospective closes every Sprint; running it every second Sprint removes inspection and adaptation from half of them. The "Proxy PO" is an accountability problem: a Product Owner may delegate work - refinement, analysis, drafting - but accountability for maximising value cannot be handed to someone who cannot say yes.
(b) Missing commitment, not a formatting choice. "Merged and unit tested" is fine only if that genuinely produces a usable Increment. If regulatory checks are required before release, the Increment is not Done and the team is reporting transparency it does not have. A Sprint Review with no stakeholders has not been reformatted; it has been amputated - it is the inspection of the Increment by the people who will use it.
(c) Leave alone. Three-week Sprints sit within the one-month limit and may suit the regulatory context. Two teams sharing one Product Backlog, Product Goal, and Product Owner is exactly what the Guide describes for multiple teams on one product. The demonstration format itself is fine; the absence of stakeholders is not.
The sorting matters because it sets your order of work: transparency failures hide everything else.
2. You are the Scrum Master. Sequence your interventions over the next six weeks and explain the ordering principle.
Read the worked answer
Sequence by dependency, not by annoyance.
Weeks 1–2: make the Increment transparent. Work with both teams and the controls team to establish what "done" must include for the Increment to be releasable, or at minimum make the gap explicit - for example, an "undone work" column on the board. Until this exists, every other improvement is measured against a false baseline.
Weeks 2–3: the Sprint Review. Get one real stakeholder into the next Review. Coach the Product Owner to frame it as an invitation to inspect, not a sign-off gate. Two people is a start; the goal is a conversation about value, not an auditorium.
Weeks 3–4: the Daily Scrum. Stop updating the board. Meet the developers and ask what they need from the event; help them try a format aimed at the Sprint Goal - "what stands between us and the Goal today?". Expect two weeks of discomfort.
Weeks 3–4, in parallel: the Product Owner conversation. Bring data: decision lead times, items queued for approval, what happens when the analyst must escalate.
Weeks 5–6: Retrospective cadence. Restore it every Sprint, and make the first one about why the format is not producing change. Then use it to sustain the earlier changes.
The principle: transparency first, because inspection of an opaque system produces noise; then the cheapest, most visible changes, because credibility funds the harder conversations.
3. The Head of Digital says: "I'm accountable, I just delegate the work. What's the problem?" How do you answer her?
Read the worked answer
Start by separating accountability from activity. She is right that she can delegate the work - no Product Owner does all the refinement personally. The question is what has actually been delegated: ranking, or the authority to decide.
Her problem is decision latency, not delegation. If the analyst can rank but cannot approve above a threshold, every significant item queues behind a person who is absent from the conversations where the options are formed. Show her the numbers: how long items sit between "analyst ranked" and "approved", how often a refinement decision is reversed, how many questions in past Sprint Reviews she could have answered in the room.
Then offer concrete options rather than a lecture. Explicit decision rights: a written threshold with a 24-hour response for anything above it, visible on the backlog. Attendance at the Sprint Review, the cheapest way to cut decision latency because it is the one event where stakeholders and team inspect together. Or a genuine handover of accountability to someone whose authority matches it.
What you must not do is imply the arrangement is fine because she is busy and senior. Say plainly that the Scrum Team currently has no Product Owner in the sense the Guide means - someone accountable for maximising value - and let her decide how to resolve it. Then hold her to whatever she chooses.