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. ;)
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.
Know why they want it.
Think of a plane. It needs three key features.
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
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
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. ;-)
Yousef Awad May 16, 2016
Jason McGee of IBM Talks about Open Source Projects and the Interactions at the Collaboration Summit
Jason McGee May 15, 2016
Srini Penchikala May 15, 2016