How to Convince the Product Owner to Prioritize the Backlog?

"scrumnoob" has a problem in the Scrum project he is working on. The product owner (P.O.) is unwilling to prioritize the product backlog. "scrumnoob" writes:

The PO is great in terms of product knowledge, business management etc and buys into the sprint ideals/demo's and retros. He calls the product backlog grooming and prioritisation for release planning a bit pure and will not buy into it. Rather his approach is we need all these must haves by this date, no point in prioritisation.

What should "scrumnoob" do in this situation?

"woynam" suggests managing the dysfunction by asking the product owner to order the backlog around factors other than customer value:

If *everything* in the backlog has to be delivered (doubtful), then there are other ways to prioritize the backlog.

One could prioritize based on technical risk, which certainly affects business value. Are there features that are tough to implement, or have a high level of uncertainty? Implementing these first reduces the risk of surprises down the road when it may be too late.

The backlog could be organized by theme. Stories in a single functional area should be implemented together so that if you have to pull the plug early on the project, you have cohesive sets of features.

Are there interim deliverables? Is there a trade show that requires a demo version? If so, what makes sense to have in the demo?

Dave Rooney suggests using the quality-versus-time pressures that naturally arise in software projects to help persuade the product owner:

[...] prior to adopting Scrum, did the organization use a traditional process with a boatload of system testing in the last phase? If so, was that phase ever "squeezed" in order to get more features into a release? If so, how was the quality, or perhaps the better question is how much testing and rework effort had to go into getting the release shippable? With this information, you could ask the PO what features he would like done prior to the crunch period at the end where quality takes a hike.

Peter Stevens recommends framing the problem of prioritization within a larger business perspective:

You know, it is such a classic pattern: Business can not/will not/does not set priorities, so someone in the development group (usually a 2nd line manager) steps in and does the dirty work. It's not really good for optimizing value, but it means prioritization does happen (and business is spared the heavy lifting and can blame development for doing it badly). Is this where your organization wants to be? Do you want to continue this pattern with Scrum?

Dave Rooney makes a case for the development team to set backlog priorities themselves, but to do it badly in the hope of goading the product owner into action:

Do you have a reasonable idea of items that *should* be prioritized higher? If so, perhaps say to the Product Owner: "OK, then we're going to do these things first". Choose the lowest priority items first. Then say, "We'll leave these to the very end." Select the highest priority items.

Another possible strategy is to completely randomize the order of the backlog items.

The Product Owner will suddenly have a better idea of what's a higher priority. ;)

But David Koontz doesn't think much of this idea:

I wouldn't suggest working on the low value items to get attention—this is spiteful and not productive to the relationship or the team's success. The team is responsible, if the PO doesn't play the part—proxy for them the best everyone can. The team many understand the value of the stories as well as the PO—they should do the best they can in priority order.

No matter what solution is pursued, though, Charles Bradley recommends having the ScrumMaster treat this problem like any other Scrum impediment:

Whose decision was it to go to Scrum? What process did you use before?

Who will get upset if you deliver zero stories next sprint?

Who does the PO report to?

Who do you report to? Are you the ScrumMaster?

My questions are along the lines of treating this issue as an impediment, so the ScrumMaster should work at resolving this, probably mostly outside of the team.

It sounds like you need to find the right decision maker to resolve your impediment, or to at least get "cover" for the impediment if it blows up in their face later.