A Product Owner in name only
Northwind Logistics has six developers, a QA engineer and a part-time Scrum Master working in three-week Sprints on an internal route-optimisation platform. The Product Owner is also Head of Operations and attends roughly one hour per week; day-to-day product decisions are made by a senior business analyst who is not the Product Owner and who has no authority over budget or priority. Refinement meetings are held when the analyst has time, and about half of the stories entering Sprint Planning have acceptance criteria written by the analyst in the same meeting. During the current Sprint the team has stopped work twice to ask the analyst whether a driver assignment rule should consider overtime, and both times received an answer three days later after escalation to the Product Owner. At the Sprint Review, the operations director rewrote the ordering of the top five backlog items in front of the team and asked the team to "just start on the first two". The team is delivering at 80 percent of its committed points and morale is falling.
1. Identify the accountability problems in this situation and argue which one you would address first.
Read the worked answer
The symptoms list maps onto a small number of root causes:
- Accountability without capacity. There is exactly one Product Owner, as Scrum requires, but one hour a week cannot support value decisions.
- A proxy without authority. The analyst absorbs the work of the role but cannot prioritise or commit budget, so every real decision becomes an escalation with a three-day latency.
- Refinement is not happening. Acceptance criteria written in the same meeting as Sprint Planning means the team plans on unrefined items and discovers ambiguity mid-Sprint.
- Backlog ordering is contested. The operations director reorders items in the Review, which removes the last piece of the Product Owner's accountability.
- Delivery shortfall and morale. 80 percent of committed points is a downstream symptom, not a separate problem.
Address the decision-rights problem first, because the others are its consequences. Fixing refinement while the director can still override priorities simply produces well-refined work that gets reordered. The test is simple: when the team asks whether overtime counts, who can decide, how fast, and is that decision final? Until that answer exists, planning accuracy will not improve.
2. As Scrum Master, what do you actually do about the analyst this Sprint? Set out the options and their consequences, and say what you would not do.
Read the worked answer
Options, roughly in order of cost:
- Do nothing. Cheapest and worst: the three-day decision latency continues and the team keeps stalling.
- Have the team push back on unready items. Legitimate, but with a part-time Product Owner it risks paralysis rather than improvement.
- Negotiate explicit delegated decision rights. The Product Owner remains accountable but delegates defined item-level decisions to the analyst in writing: which kinds of questions the analyst may settle alone, which must go to the Product Owner, and a decision service level (for example, a 15-minute daily availability window and a response within one working day, with a stated default if no answer arrives).
- Escalate to the Product Owner's manager as an organisational impediment. Justified if 3 fails, and much stronger with data.
I would run option 3, because it addresses the actual bottleneck - decision latency - while preserving the single-Product-Owner rule. Scrum permits delegating work; it does not permit delegating accountability for value and ordering. I would bring data, not opinion: days of delay per decision, the 80 percent delivery pattern, and the two current stalls.
What I would not do is become the proxy myself. A Scrum Master who starts answering product questions has moved the bottleneck rather than removed it, and has made the missing Product Owner invisible to the people who can fix it.
3. How should you handle the operations director reordering the backlog at the Sprint Review? Should the team start on the first two items as asked?
Read the worked answer
Two questions are tangled here: what the Review is for, and who actually holds authority.
On the event: the Sprint Review exists so stakeholders and the team can inspect the Increment and adapt the Product Backlog. The director's input is welcome and useful - he is a stakeholder with real operational knowledge. But the ordering of the Product Backlog is the Product Owner's accountability, and "just start on the first two" is an instruction to the team that bypasses both the Product Owner and Sprint Planning.
On the team: no, the team should not silently absorb it. Work enters a Sprint through negotiation in Sprint Planning; mid-Sprint changes should be decided jointly with the Product Owner against the Sprint Goal.
What I would do in the room: capture the request visibly, hand it to the Product Owner to respond to, and avoid a public protocol argument that makes the team look obstructive. Afterwards, three conversations: with the Product Owner, about whether she has the authority her title implies; with the director, about how his priorities reach the team; and with both together to agree a route. If the director is in practice the decision-maker, the honest conclusion is that the Product Owner role is nominal and either the authority or the person must change - a Scrum Master who only defends ceremony will lose this argument permanently.