BT

How to Convince the Product Owner to Prioritize the Backlog?

by Dan Puckett on Dec 13, 2010 |

"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.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Know why they want it. by Chris Matts

It could well be that you are building a BVI ( business value increment formerly known as MMF minimum marketable features ). Without all of the features, no value is delivered to the business.

Think of a plane. It needs three key features.

1. Take-off
2. Fly
3. Land

Without all three, the product has no value. They are not interested in an early delivery of any feature from a business value perspective.

That does not mean that the features should all be delivered in a single lump together at the end. That does not mean there is no value to delivering early. The early delivery could be to address delivery risk or risk to the existing business model. As woynam suggests, the features could be delivered in risk order.

Simply put, try to understand why the features are needed together from a business value perspective.

Not technical risk, but miscommunication risk by Morgan Creighton

I agree with Chris. Even if all the features are of equal business value, the ones that are most likely to be misunderstood should get the highest priority.

Keeping with the plane analogy, our developers deliver a shiny new piper cub on schedule, and the P.O. asks, "What? It's not supersonic?" Oops! If the "fly" feature had been completed in time to generate early feedback, that misunderstanding could have been detected.

The real problem though, is that a P.O that refuses to prioritize (or is too overworked to do so) is perceived by the developers to be shirking. Just as we'd be hesitant to team up with programmers that refused to write unit tests, a P.O. that didn't prioritize should give us pause.

Re: Not technical risk, but miscommunication risk by Chris Matts

Hi Morgan

I agree with your points.

however, we have to be careful that the PO is not simply doing their job properly and the team fail to understand them. The PO may be saying "I want Take Off, fly and Land. Without all three there is no point in delivering any of them." the team can then offer to deliver in a way that reduces the delivery risk ( something that the PO isn't qualified to suggest ). The PO will then probably be guided by the team. After all, the PO knows what they want and have expressed it in the clearest way they know. Its the team and POs responsibility to identify the areas where there is misunderstanding.

As an exercise "Think of a Volkswagon."





I bet you are thinking of a white or blue beetle, just like Herbie in the Disney movies.

I was thinking of a camper van so I could go surfing. ;-)

Language is a great way to misunderstand each other. Which is why stories are a great way to communicate requirements. ;-)

Deployment automation by XebiaLabs XebiaLabs

Dan, we are sorry to hear that “scrumnoob” is having such trouble with his manager and the organization’s backlog. Although poor managerial tactics may be to blame in this particular case, the backlog of deliverables is a problem at almost every Agile organization. Luckily, solutions like deployment automation can help immensely with end-to-end automation for all deployments. With these solutions, operations teams no longer are faced with such lengthy and tedious tasks, and “scrumnoob” can be happier in his workplace! Would you agree?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT