Product Backlog : Order v Priority

The PO should order by value, based upon the current product goal which should help the organisation move forwards towards their product vision.

So, what's stopping the PO from ordering the list by priority?

Perhaps nothing, not a darned thing. A PO can order the Product Backlog by priority, value, ROI, urgency, dependencies (business or technical) or any combination of these or other matters. He or she may take into account the advice provided by others, including Developers during Product Backlog Refinement.

So, what's stopping the PO from ordering the list by priority?

The Scrum Police of course.  

Seriously, as @an Mitchell says, nothing at all. Order can be derived by a large number of criteria.  And, in my opinion, that is why the word "ordered" was chosen over "prioritized".  For example something that is the highest priority to the product and company success might be ordered below some technical debt work that will make it possible to do the high priority work.  One could argue that the technical debt is higher priority because of the dependency but others would say that the feature is higher priority because it has revenue implications. 

In the end, the message is to make sure the Product Backlog is arranged in a manner that will allow the Scrum Team to deliver the value that is needed by the organization in a manner that benefits the most.

Nothing is stopping the Product Owner from ordering the Product Backlog exclusively by priority. However, this probably isn't the best way to order it. Transparency is one of the pillars of Scrum, and the Product Backlog is transparent to stakeholders. Someone should be able to look at the Product Backlog and have a good idea of what the next things that the Scrum Team will do will be, based on their current understanding of the world, and use this as a basis for conversations with the Product Owner regarding the ordering of items. Ignoring things like technical dependencies, value, and risk doesn't do the stakeholders or the team any good when understanding what the next things to do are.

In that case the Stakeholders would be those who own the business case and I don't know if they negotiate the backlog order or even if they realize they can negotiate it. Way above my pay grade :)

This might help, https://www.scrum.org/resources/ordered-not-prioritized#:~:text=To%20us….

Thanks for this link, Joshua. It's really good.

Long story short 'prioritization' is just too narrow. It's like the subset of 'Ordering'. 'Ordering' is broader. - not only sorting things but also arranging them, making order from disorder. For example, the story map, it is not just simply the prioritized list, it is the arrangement, which increased understanding.