Your Product Owner says everything in the sprint is top priority and refuses to rank the backlog. How do you handle it?

Diagnose before you act

"Everything is priority one" is a symptom, and the useful first move is finding out which cause you are dealing with, because the response differs entirely.

The PO may be under external pressure and unable to say no to a stakeholder, in which case the real problem is upstream and your work is to give them cover. They may not believe the cost is real, assuming the team can absorb it all with enough effort. They may lack the authority the role nominally grants, which is an organisational problem masquerading as a behavioural one. Or they may genuinely not know how to compare items with incommensurable value, which is the most tractable case because it is a skills gap you can help with.

Ask directly and privately, not in a ceremony. "When you say all eight are top priority, is that because a stakeholder has committed to all of them, or because you are not sure how to rank them against each other?" is the question that actually opens the conversation.

Make the cost visible rather than arguing

Arguing about priority in the abstract is unwinnable, because "this is important" is not a falsifiable claim. Shift the conversation to arithmetic, which is.

Put the team's demonstrated capacity next to the ask. If the last three sprints delivered roughly 30 points and the proposed sprint contains 62, the sprint is not a prioritisation disagreement — it is a plan that cannot happen. The point to land, calmly, is that the choice is not whether to prioritise but who does it: either the PO orders the backlog deliberately, or the team ends up ordering it accidentally through whatever they happen to pick up, or worse, nothing finishes because everything is half-done.

That last consequence is the persuasive one. Work in progress that does not complete has produced no value at all while consuming the full cost, and showing a cumulative flow diagram or a count of items carried over for two or three sprints makes it concrete in a way that an opinion cannot.

Use a mechanism that requires ordering

If the PO cannot rank by discussion, give them a structure where ranking is the only possible output. Several work, and picking one and driving it is better than offering a menu.

Forced sequence. Ask not "what is most important" but "if we could only ship one of these by Friday, which one?" then repeat. People who cannot rank a set can almost always answer a pairwise question.

A stack rank with a hard limit. The backlog is a single ordered list with no ties permitted. Two items cannot both be first, and the constraint does the work that persuasion could not.

Cost of delay. For each item ask what happens if it ships a month later — a lost contract, an accruing compliance risk, a mildly annoyed user. This reframes priority as consequence rather than preference and often exposes that two of the eight had no real deadline at all.

WSJF or RICE if the organisation already uses them. The number matters less than the fact that a shared formula depersonalises the decision, which helps a PO who is avoiding the appearance of choosing between stakeholders.

Respect the accountability boundary

Do not rank the backlog yourself. It is tempting, it appears to solve the problem, and it is the wrong move — prioritisation is the Product Owner's accountability, and taking it removes the pressure that would otherwise force the role to function while making you the person stakeholders negotiate with. Interviewers listen for this specifically, because a Scrum Master who quietly absorbs the PO's job is a common and damaging anti-pattern.

Your accountability is that the process works. That means facilitating the decision, making the constraints visible, and coaching the PO in how to make the call — not making it for them.

Escalation, and when

Escalation is a legitimate step, but it is a late one and it needs evidence. If after a sprint or two the pattern persists and delivery is measurably suffering, take it to whoever the PO reports to, with data rather than complaint: carried-over items, cycle time trending upward, capacity versus commitment, and the specific consequence to delivery. Frame it as a systemic impediment you are raising as part of your role rather than as a personal escalation, and tell the PO you are doing it before you do it.

If the root cause turns out to be that the PO has no real authority, escalation is not optional — that is an impediment only management can remove, and no amount of facilitation will fix it.

Preventing the recurrence

Agree a standing rule that the backlog is always strictly ordered with no ties, and that refinement ends with a ranked top slice rather than a discussed pile. Introduce a work-in-progress limit so parallel starts become visibly impossible rather than merely discouraged. And bring the stakeholders into the sprint review, because a PO who is shielded from the tension between competing stakeholders will keep resolving it by promising everything.