Who Owns Backlog Prioritization?

Question

I recently had a meeting with several executives/managers wherein we determined that what the Product Owner had communicated, and the Product Manager had prioritized in the backlog, was no longer what was important from the perspective of the business. The PM wanted more features and minor fixes, so the backlog was prioritized accordingly. It was determined in this meeting however, that stabilization efforts were the priority. These include several pieces that will boost performance dramatically, limit errors and issues, and hopefully improve customer satisfaction (stabilization).

Where I have worked previously, the PO owned the backlog, and the Product Manager would prioritize the backlog. From the result of this meeting, in my experience, it should've been the PM that re-prioritize the backlog. If the technical debt piece was too obscure to be able to understand on their own, the PM would enlist the help of whoever they needed to in order to prioritize, but it still ultimately fell on them.

Today I was told that the Dev team actually owns the prioritization of the backlog with respect to technical debt/stabilization pieces. This to me yells red flag, in that we now functionally have co-owners of the backlog, and the source of truth it once was, is no longer. At any given time you may have incorrectly prioritized stories/tasks/bugs based off of two competing interests.

Am I off base? Am I thinking too black and white? I know we are all responsible for contribution, but the backlog is owned by the PO; the more tactical piece is owned by the PM; and execution is owned by dev.

Answer 1

Mark, you are absolutely correct that the PO has final say on the backlog and execution is owned by the development team. This doesn't mean that the development team doesn't have input or say. They should absolutely advocate for things they think are important. However, the Scrum Guide is very clear that:

"The Product Owner is the sole person responsible for managing the Product Backlog."

It also has this to say about the product owner:

"The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner."

This is specifically meant to address the problem you are raising.

Now, it's worth calling out that there is no Product Manager in Scrum. That means you've modified the formula a bit at your company. I'm not going to suggest that this is taboo or anything. In fact, I've worked on plenty of Scrum teams where we did modify Scrum to suit our needs. However, when you do you have to replace the mechanisms you remove. In this case, you have added multiple people with say over backlog priority. Without some other clear mechanism to address conflicts of interest between those people, you're going to have problems crop up. Because it's a "house rule" so to speak, there isn't a right answer on what that mechanism should be. It's whatever solves the problem for you.

Answer 2

The PO should have the final say over priorities and what items on the backlog get put into a sprint. In Scrum there is no PM. It doesn't really matter what you call the person performing the PO role but it is obviously important that there is a clear set of decisions.

The only significance of prioritisation is that it helps the team to decide what to discuss during the next sprint planning meeting. Team members can suggest other things to be taken into the sprint if they wish but the PO has the final say during sprint planning. Once the sprint has started the prioritisation is unimportant. All backlog items are expected to be completed by the end of the sprint so there should be no need for further prioritisation at that stage.

Answer 3

Just to add to the other answers; whilst the backlog is technically owned by the PO, the order of the items isn't down to them. Any/all stakeholders should be advising the business value of their epic/feature/story/bug, so the higher value/priority work floats to the top of the list.

Without this, the development team go into sprint planning assuming the top x work items can be pulled in based on y velocity. They then get to sprint review 2-3 weeks later, and present what they've done. You can imagine the stakeholders surprise when a low-value item has been delivered, and it's up to the development team to justify why.

This is why backlog refinement sessions are useful. You get to ask questions like "Is it ready?", "Have we estimated it?", "What is its business value?" etc...