The PO Who Cannot Decide
A Scrum Master supports a team building an internal claims-processing tool. The Product Owner is a former business analyst who is well liked but has been in the role for eight months without ever saying no. The Product Backlog has 340 items, roughly 60 of them marked 'high priority.' The team routinely pulls items the PO ranked as low because 'the PO won't mind,' and twice in the last quarter the team built features that the PO later said were 'not what I meant.' Sprint Reviews have become demo sessions where stakeholders add new requests, and the PO leaves each Review with 15-20 new items and no removals. The team's average Sprint carries 9 items; 3 are typically unfinished and roll over. The PO tells the Scrum Master, 'I don't want to be the bottleneck - the team should self-organize.'
1. The PO is invoking 'self-organization' to justify not making ordering decisions. Explain why this is a misreading of Scrum, referencing the accountabilities of the Product Owner and the Scrum Team.
Read the worked answer
Self-organization in Scrum concerns how the team accomplishes its work - who does what, how they collaborate, how they solve technical problems. It does not transfer the what and why.
- The Product Owner is accountable for maximizing value and for ordering the Product Backlog effectively. That is a single-person accountability precisely so that there is one source of priority. It is not a committee decision and not delegable to the team by default.
- The Developers are accountable for creating a usable Increment each Sprint and for their own plan to meet the Sprint Goal. They self-organize around the work, not around product priority.
- The Scrum Team as a whole is cross-functional, but 'cross-functional' means it has the skills to deliver, not that priority is diffuse.
When the team pulls low-priority items 'because the PO won't mind,' the team is filling a vacuum the PO created. That is not self-organization; it is an accountability gap. The PO's fear of being a bottleneck is real, but the remedy is delegation with clear boundaries and transparency, not abdication of ordering.
2. Identify the specific symptoms in the setup that a weak ordering practice is producing, and explain the causal chain for each.
Read the worked answer
Four symptoms, each traceable to unclear ordering:
- 340 items, 60 'high priority.' When everything is high priority, nothing is. A backlog this flat gives the team no basis to choose, so they choose by convenience. Cause: no forced ranking / no clear 'next.'
- Team pulls low-ranked items. With no credible top of the backlog, the team infers intent. Cause: ordering not treated as a decision with consequences.
- 'Not what I meant' twice in a quarter. The PO is not clarifying items before or during refinement, so the team builds to its own interpretation. Cause: insufficient shared understanding at the point of commitment.
- Reviews generate 15-20 additions and zero removals. The Review has become a request-collection channel rather than an inspection of the Increment against the Sprint Goal. The PO absorbs every request without ordering or saying no. Cause: no explicit trade-off conversation with stakeholders.
Rollover of ~3 of 9 items per Sprint is the downstream effect: the team is committing to work it did not understand well enough to size, because the PO's ordering and refinement haven't created clarity.
3. Give the Scrum Master a concrete coaching plan for the next two Sprints, aimed at the PO specifically, with at least one measurable indicator of progress.
Read the worked answer
Coach the behavior, not the person; make the trade-off visible.
Sprint 1
- Work with the PO to reduce the backlog to a single ordered top ~20 with an explicit 'not now' list. The 60 high-priority items collapse into a ranked top set; the rest move to a parking lot. (Coaching move: 'Which one would you drop first if capacity halved?')
- Institute refinement with acceptance criteria for the next 2-3 items before Sprint Planning, so the team builds to a shared understanding.
- Reframe the Sprint Review: the PO opens by stating the Sprint Goal and asks stakeholders to react to the Increment, then explicitly names what will not be added this Sprint and where new requests go.
Sprint 2
- Coach the PO to say no in public at least once per Review, with a reason tied to the current goal. Rehearse it beforehand.
- Introduce a simple trade-off artifact: for every new request, the PO states what it displaces. This converts 'yes to everything' into visible cost.
Measurable indicators
- Backlog items marked 'high priority' drops from ~60 to ≤15.
- Rollover falls from ~3 items per Sprint toward ≤1.
- Number of 'not what I meant' reworks in the quarter trends to zero.
- Review additions are matched by an equal number of explicit deferrals or removals.
Address the 'bottleneck' fear directly: the PO is not being asked to decide everything, but to set boundaries within which the team can decide - that is delegation, and it scales.