The Product Owner Who Is Also the Boss
In a 40-person division, the person acting as Product Owner for two Scrum Teams is also the line manager of most of the Developers on those teams. She sets Sprint priorities, conducts annual performance reviews, approves leave, and decides who works on which team. She is competent and well-liked, but the teams defer to her on technical decisions, rarely push back on scope, and have never once declined a request to add work mid-Sprint. A developer told the Scrum Master: 'If I argue about the Sprint Goal, it goes in my review.' The division has missed its last two release commitments. The Scrum Master reports to the same manager.
1. What structural problem does this create for the Scrum Team, and why does it matter for empiricism?
Read the worked answer
The Product Owner holds two incompatible accountabilities: maximizing product value (which requires the team to push back, negotiate, and say no) and evaluating individual performance (which punishes exactly that behavior). When the same person sets priorities and writes reviews, 'no' becomes career risk, so the team stops surfacing trade-offs.
This matters for empiricism because transparency collapses. If the team never declines scope, the Sprint Backlog and the Sprint Goal stop reflecting reality - they reflect what the boss wants to hear. The missed release commitments are the predictable result: forecasts are made under pressure and never corrected by honest inspection.
2. The Scrum Master reports to this same manager. How should she proceed?
Read the worked answer
The Scrum Master's position is genuinely constrained: she cannot fix a structural conflict of interest by coaching the team to 'speak up' when speaking up is penalized. She should:
- Name the conflict directly and privately to the manager, framed around the missed commitments rather than blame: 'The team isn't telling us what's true, and I think it's because pushing back carries a performance risk.'
- Propose concrete separation: e.g., performance reviews handled by another manager, or the PO role rotated to someone outside the reporting line for one team.
- Escalate if needed, recognizing her own reporting line is part of the problem. She may need to raise it with the manager's manager or HR, which is a legitimate use of servant leadership - protecting the team's ability to be honest.
She should not run a 'psychological safety' workshop as a substitute for changing the structure.
3. Until the structure changes, what can the Scrum Master do to make trade-offs visible without exposing individual Developers?
Read the worked answer
Shift the risk from individuals to the system. Concretely:
- Make capacity and WIP visible on the team board so mid-Sprint additions show up as a trade-off ('adding X means Y slips'), not as a developer's objection.
- At Sprint Planning, have the team forecast against its Definition of Done and past velocity, and record explicitly what is being deferred when scope is added.
- At the Sprint Review, present the impact of mid-Sprint changes as data - e.g., 'three items were added after Planning; two committed items moved out' - so the cost is discussed by stakeholders rather than absorbed silently.
- Coach the PO to ask 'what should we drop?' rather than 'can you also do this?'
This does not remove the conflict of interest, but it makes the consequences visible and gives the Scrum Master evidence for the structural conversation.