Priority by whoever shouted most recently

Separate two things that are currently fused: changing the order and changing it arbitrarily. Agile ordering should change when evidence changes. Here it changes when someone complains, which is a different signal entirely.

Make the criteria explicit. Agree a small, published set - for example expected value, cost of delay, risk/uncertainty reduction, and dependency/sequencing. Nothing needs to be numerically precise; the point is that any stakeholder can see why item A is above item B and argue with the reasoning rather than with the PO's inbox.

Attach a hypothesis to the top items. Each high item states the outcome it is expected to produce and how that will be observed. "Rebuild the reporting engine" cannot be prioritised against anything because it promises nothing measurable.

Stabilise the near term, flex the far term. The top 1–2 Sprints' worth should be genuinely stable - the Developers are building it. Below that, reordering is cheap and should be routine. Reordering the top during a Sprint is a sign the criteria are not being applied upstream.

Record the reason. A one-line rationale per ordering change costs seconds and converts "priorities changed" into an auditable decision. It also gives the PO an answer at the next Sprint Review.

Keep it honest. The model is not a formula. When a genuinely new, high-cost-of-delay fact arrives, the order should change immediately - and the rationale line shows why.

Diagnosis. An item that has been at the top for five months with six months remaining is not a backlog item; it is a project. It cannot be ordered against other items, cannot be finished within any meaningful horizon, cannot be evaluated at a Sprint Review, and cannot be reordered when evidence changes - because the whole thing moves as a block. It is also almost certainly the reason "their" item keeps slipping: one item is consuming the roadmap.

What to do. Slice it into thin vertical increments, each capable of delivering observable value or removing a specific uncertainty:

• A single report for a single user group, read-only, on one data source.
• One data source connected end-to-end with acceptable freshness.
• The existing engine instrumented to show which reports are actually used - this may change the plan entirely.

Sequence the slices by value and risk. Early slices should be the ones that answer the biggest open question (do users want new reports, or faster existing ones?).

What this buys. The item becomes orderable, finishable inside a Sprint or two, demonstrable at a Sprint Review, and cancellable part-way. It also lets the PO say something concrete to the four stakeholders: here is what is coming first, and here is what evidence would move the rest.

Watch for. The team may resist slicing because the architecture "needs" a rebuild first. That may be true for part of the work - in which case make the architectural slice explicit and time-boxed, but do not let it become an unbounded block again.

Name the structural problem. If four people hold a veto, the Product Owner is not ordering the backlog - they are brokering between four orders. That is why the order flips three times a Sprint. The PO's accountability for maximizing value is being exercised by nobody.

Clarify decision rights, in writing. Stakeholders inform the order; the Product Owner decides it. This is not a power grab - it is the only arrangement in which someone can be accountable. The PO should say this explicitly to all four, and to their managers if needed, rather than behaving as though it were true and hoping.

Give stakeholders real influence through a channel that scales.

• Bring the criteria and the ordered backlog to the Sprint Review, so all four see the same picture at the same time. Sequential one-to-one calls manufacture the conflict.
• Ask each for the outcome they need and the cost of delay, not the item they want. Four different requests often collapse into one underlying need.
• Where there is genuine, irreconcilable disagreement about value, that is a management/strategy decision above the PO - escalate it as a decision to be made, not as a queue to be juggled.

Expect a test. One stakeholder will escalate to prove the veto still works. The response must be consistent: where is it in the backlog, and what would move it up. Inconsistency here reinstates the old system immediately.