Who Makes the Final Decision on Ordering the Product Backlog

Your Product Owner must captain the backlog, not just hold the wheel. Crew input counts, but if everyone grabs the wheel, the sea takes over.

Who Makes the Final Decision on Ordering the Product Backlog?

The Product Owner makes the final decision on ordering the Product Backlog because they’re tasked with maximizing the product’s value. They’ll listen to input from the team and stakeholders, but they decide. Still, many organizations struggle to fully empower Product Owners with that authority.

Scrum outlines decision rights for each role, but implementing them is where many organizations stumble. Daniel Mezick stresses that enforcing these decision rights is critical for true agility. Without this, teams often get tangled in indecision, stalling progress and undermining the whole framework.

“For Product Owners to succeed, the entire organization must respect their decisions.”

- Scrum Guide

Captaining a ship sounds simple until everyone thinks they know better. One person needs to hold the wheel, but you’ll veer off course when twenty others try to grab it. The captain must steer, yet also listen—taking in the voices around them without losing their grip. It’s a fine line: you can balance assertive leadership with the humility to hear others out. Without that balance, you’re not sailing—you’re just drifting.

“The Product Owner is one person, not a committee.”

- Scrum Guide

When decision rights are shared, priorities blur, and direction falters. Too many voices lead to a muddled path, with everyone pulling in different directions. The focus gets lost, and instead of progress, your team will be stuck in place, adrift without a clear course.

Product Owners often find themselves in a daily struggle to uphold the authority tied to their role. It’s exhausting, and some days, it might seem easier to give up. But they push on because their accountability isn’t just about making decisions—it’s about maximizing value.

What Is the Importance of Properly Ordering the Product Backlog?

Correctly ordering the Product Backlog maximizes value by prioritizing the most impactful items, helping align efforts with business goals. Poor prioritization can lead to wasted resources and misaligned outcomes. Yet, the true measure of value extends beyond features, touching on areas teams often overlook.

Imagine you’ve got a treasure map in your hands. It’s tempting to think the shortest route to the treasure will cost the least and yield the most. And that’s often how teams approach prioritization—picking what looks like the quickest win. But here’s the catch: that direct path could be littered with icebergs, hidden costs, and unseen risks. And let’s not forget, there are three red Xs on that map. Which treasure holds real value? Which one’s guarded by crocodiles, empty, or filled with fool’s gold? Prioritizing isn’t just about speed; it’s about navigating uncertainties and making decisions with limited information.

When you think about value delivery, it’s more than feature enhancements. You have to maintain a healthy code base and manage technical debt to keep it easy to continue to make changes in the future. At times, value will come in the form of avoiding negative consequences like fines associated with being out of compliance with regulations. Usability is also a consideration that might not be readily apparent.

Delivering value is about more than shiny new features. Think of your code base like a living thing; it needs care to stay healthy. Tackling technical debt isn’t glamorous, but it keeps the doors open for future changes. Sometimes, the value lies in what you don’t see—like sidestepping fines from non-compliance or ensuring users can easily navigate your product. Usability might not grab headlines, but it’s the quiet force that turns a decent product into a great one. We don’t base value solely on what’s added; we also want to avoid, refine, and preserve things.

The challenge is weighing these competing priorities against each other—how do you determine what truly deserves to be at the top of the backlog?

What Criteria Should Be Used to Order the Product Backlog?

The following criteria should be used to order the Product Backlog:

• Perceived Value: Prioritizes high-impact items.
• Risk: Addresses potential issues.
• Time Criticality: Meets deadlines.
• Dependencies: Optimizes task order.
• Strategic Alignment: Aligns to business goals.

Balancing these criteria isn’t always straightforward.

Each of these elements might seem simple enough to evaluate on their own, but things get tricky when you start comparing them against each other. What if you’ve got a high-value item that doesn’t align with strategic goals? Or an item that carries significant risk to the company, but the likelihood of it happening is low—do you invest effort in reducing that risk, or should that time be spent advancing a strategic goal instead? And then there are deadlines. Some tasks lose all value if not completed on time, like preparing for a once-a-year event. Do those jump to the front of the queue, or are they skipped altogether if there’s a slim chance of meeting the deadline?

Some techniques, like MoSCoW, tend to gloss over the complexities and say, “We’re never going to get it exactly right, so why bother overthinking it?” Instead of fine-tuning every priority, MoSCoW buckets tasks into broad categories: Must Have, Should Have, Could Have, and Won’t Have. The idea is to spend less time obsessing over perfect prioritization and more time delivering value. It’s about accepting that you’re not aiming for perfection but for a practical approach that keeps the project moving forward.

Other techniques, like Cost of Delay (CoD) or Weighted Shortest Job First (WSJF), try to put everything on the same playing field by assigning numerical values to each option and then using a formula to compare them, apples to apples. The trade-off? They’re more time-consuming and, despite the effort, still rely on educated guesses. You might spend extra time calculating values, but those numbers can still be off. So, in the end, we might put in all that effort and still not land on the best decision. It’s more scientific, but it doesn’t remove all the uncertainty.

Prioritization is always about finding the right balance between competing needs, and let’s be honest, it’s never straightforward. But how does Scrum help teams navigate this?

Is There a Process for Ordering the Product Backlog in Scrum?

In Scrum, ordering the Product Backlog is done through Backlog Refinement. The Scrum Guide names this process but leaves specifics open-ended, allowing teams to tailor refinement to their needs.

“Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.”

- Scrum Guide

If you expect a step-by-step guide on exactly how to order the backlog, the Scrum Guide will let you down. And honestly, why should it be any different? Scrum isn’t about rigid instructions. Paddy Corry described it beautifully as an abstract class. It gives you the structure, but the implementation is on us. We’re the ones who need to take that framework and make it work for our context, and that’s where the magic—or the struggle—really happens.

“Scrum doesn’t, and can’t, offer a one-size-fits-all technique for arriving at the best ordering.”

- Barry Overeem

The lack of a one-size-fits-all is where experimentation comes into play. Look at prioritization techniques like MoSCoW, CoD, or WSJF. Do any resonate? Test it. Did the order feel right, or did you miss deadlines and trip over dependencies? Tweak the method—or ditch it and try something else.

You don’t need to start with a pre-existing process; you can build your own and iterate. Let’s say you begin with something as simple as ordering the backlog alphabetically by item title. If that works, great. There is no need to complicate things. But chances are, you’ll quickly realize it doesn’t make sense—like trying to encrypt passwords before they exist. So, adjust. Maybe you should add a rule for dependencies. Then, stakeholders push back because you’re enhancing the UI instead of fixing bugs. Now, introduce categories of work: prioritize by type, then alphabetically, and finally by dependencies. This iterative approach continues until you’ve built a method tailored to your situation.

As your ordering method evolves, you’ll find that stakeholders often have their own priorities, and these don’t always align with the Product Owner’s decisions. This tension can push the process in unexpected directions, adding another layer of complexity to backlog management.

How Does Stakeholder Input Influence Backlog Ordering?

Stakeholders influence backlog ordering by providing insights into customer needs, market trends, and business goals. The Product Owner uses this feedback to prioritize high-value items. However, balancing competing stakeholder interests can complicate decision-making.

It would be naive to think you can completely ignore stakeholder or customer feedback, but you also can’t let them dictate the backlog order entirely. Even if you try, your stakeholders rarely agree on priorities. So, decisions must be made—knowing not everyone will be thrilled.

In most environments, stakeholders often hold significant sway over backlog ordering. Their insights can heavily influence priorities since they’re closer to the customer or aligned with strategic goals.

However, balancing stakeholder desires with the Development Team’s needs is vital to long-term success.

Can the Development Team Influence Backlog Ordering?

Yes, the Development Team influences backlog ordering by providing input on technical feasibility, dependencies, and sizing. While the Product Owner makes the final decision, they must balance the team’s insights with business goals, which can sometimes lead to conflicting priorities.

It’s not uncommon for Product Owners to have some technical skills. Still, they’re rarely full-time developers who know the intricacies of the codebase or the looming threat of mounting technical debt. That’s where the development team’s feedback becomes essential, and the Product Owner needs to be open to it.

We shouldn’t be so quick to dismiss the value of the development team’s perspective. It’s common to have developers who’ve been with the company far longer than the Product Owner. Years of coding and fixing bugs in the company’s domain give them unique insights into which work items hold the most value.

It’s not just the Developers who might offer unexpected insights. While it’s less common for a Scrum Master to influence backlog prioritization, it’s certainly not out of the question.

Does the Scrum Master Have Any Authority Over the Product Backlog?

No, the Scrum Master doesn’t have authority over the Product Backlog—that’s the Product Owner’s role. The Scrum Master focuses on coaching the team and ensuring smooth Scrum practices. Still, their broader view of team dynamics and processes can sometimes reveal work that drives long-term value.

This chart summarizes the general authority each role typically has over backlog ordering; it’s directionally accurate, though individual organizations may have exceptions.

It’s common for individuals to feel they have more authority over backlog ordering than they genuinely do, leading to tense conversations.

How Should Conflicts in Backlog Ordering Be Resolved?

Conflicts in backlog orders should be resolved through collaborative discussions led by the Product Owner, focusing on value, dependencies, and risks. While the Product Owner has the final say, a clear prioritization framework can help prevent conflicts. Still, frameworks have their limitations.

You’re better off preventing conflicts than resolving them, though I’ve learned you’ll never stop them all—and maybe that’s not even the goal. Conflict often fuels innovation, and avoiding it entirely can stifle progress.

If you can develop a framework for prioritizing the backlog rooted in logic and evidence, and then share that framework transparently with stakeholders and the team, you’re likely to reduce most conflicts. At the very least, you’ll make those conflicts more productive. When everyone understands why you’ve ordered an item where it is, they can either provide the information needed to adjust its position or accept that, given what we know, it’s precisely where it should be. This approach reduces friction and fosters trust and collaboration across the board.

TLDR

Like a captain guides a ship, the Product Owner must navigate the backlog, balancing input without derailing the product’s direction. Prioritization frameworks help, but ultimately, transparent decision-making keeps everyone on course.

Works Consulted

• Scrum Guide
• Who decides who decides in Scrum ?
• Myth 5: In Scrum, the Product Backlog is prioritized
• Prioritizing to Minimize Cost of Delay
• Scrum is an abstract class