The Product Owner Who Cannot Be Found
A Scrum Master supports a Scrum Team of six developers, one of whom also acts as Product Owner. The company is a 200-person insurance firm. The dual-role person, a senior business analyst, is allocated to two other projects and estimates he spends about four hours per week on Product Owner work. Symptoms: the Sprint Backlog is often built from verbal instructions rather than ordered items; two Sprints ago the team built a reporting feature that was never released because 'priorities changed'; refinement sessions are cancelled roughly half the time; and developers frequently ask the Scrum Master to decide which item to work on next. The team's velocity has dropped from 42 to 29 points over four Sprints. The Scrum Master has raised the dual role with the engineering manager twice and been told 'we can't afford a full-time PO'.
1. Analyse the situation against the Scrum Team rules. What is the core problem, and what are the observable consequences?
Read the worked answer
Scrum requires a Scrum Team of one Product Owner, one Scrum Master, and developers, with no sub-teams or hierarchies, and the Product Owner is accountable for maximising value from the product, which in practice requires being available enough to order the backlog and answer questions. The core problem is not the individual's competence but a structural violation: a Product Owner who is 10% available across three projects cannot be accountable for value, because the role's accountabilities require continuous engagement with the team and stakeholders.
The observable consequences map directly onto that gap. Building the Sprint Backlog from verbal instructions means there is no ordered, transparent Product Backlog to select from, so the team is guessing at priority. The unreleased reporting feature is the predictable result of priorities being held in someone's head rather than in a visible ordering. Cancelled refinement means items are not ready, so Sprint Planning is forced to compensate. Developers asking the Scrum Master to choose work is a symptom of an absent decision-maker and, if the Scrum Master accepts, a drift into the Scrum Master acting as proxy Product Owner, which is a role violation. The velocity drop from 42 to 29 is consistent with rework and start-stop work, but it is a symptom to investigate, not proof of cause.
2. The engineering manager says a full-time Product Owner is unaffordable. How should the Scrum Master respond, and what options should be explored?
Read the worked answer
The Scrum Master should reframe the conversation from cost of a role to cost of the current arrangement, using evidence already available: one feature built and never released, roughly half of refinements cancelled, and a 31% velocity decline. Those are wasted capacity and delayed value, which is the real price of the current setup. The argument should be made to the engineering manager and, where possible, to whoever owns product outcomes, because this is an organisational design decision beyond the team's authority.
Options to explore, in order of preference:
- A single accountable Product Owner with reduced other commitments. Even partial reallocation (for example, 60% on this product) is materially different from 10%.
- Delegate ordering work explicitly. The Product Owner may delegate backlog ordering or refinement to others, but accountability stays with him. This must be a clear, visible arrangement, not informal drift.
- Reduce product scope. If the firm genuinely cannot fund the role, the product should have fewer concurrent priorities rather than a nominal owner spread across three.
What the Scrum Master should not do is absorb the Product Owner role to keep delivery moving. That hides the problem, entrenches the status quo, and removes the pressure that would force the decision. The Scrum Master's job is to make the impediment visible, facilitate the decision, and coach the team to escalate rather than route decisions through the Scrum Master.