Two Ways for Product Owners to Prioritize a Backlog

While executing Agile development projects for large organizations, we often run into a few of the same challenges no matter the type of client. A common challenge is the “everything is critical” scenario when trying to prioritize work. Sound familiar?

For these projects, an Agile Product Owner is typically provided by the client. And to level-set, this does not reflect poorly on the Product Owner. The theory of backlog prioritization operates under the assumption that priorities are clear, but reality is rarely that nice. The more common scenario is that the Product Owner has multiple objectives (or superiors) to account for, each with a different agenda. Net impact is that, depending on which objective/boss you want to satisfy, priorities are different. The result is a Product Owner trying to juggle multiple and competing priorities while still providing a clear path forward.

So what can be done about it? We have a simple and practical way of addressing this issue.

Solving the complex political challenges of negotiating between superiors and/or competing agendas is an idealistic objective—not a realistic one. And there is an easier way: change the context of the conversation.

When everything is a priority, you need to provide your Product Owner tie breakers.

What is the next level of sorting? To avoid the political quagmire, it is best to keep this as objective as possible. Give Product Owners a defensible methodology to determine which objectives we achieve first. Defensibility is key, since the typical reason why your Agile Product Owner can’t provide clear priorities is that somebody (namely a superior) is not going to be getting what they want. You need to empower the product owner to prioritize a backlog by making definitive and defensible decisions. First line of defense is distinguishing the MVP from the MMP. This is a start, but rarely the finish.

Celerity’s go-to prioritizing solution is order-of-operation. We typically build large-scale solutions that support complex business operations. So, in the business process, what is step one? What needs to be built for that step? It is an easy black-and-white way of breaking the tie. We build in order. Specifically, we build the minimal viable product (MVP) to get to the next step. If it is a car, it would drive…but not have a body, turn signals or anything else outside of what is absolutely needed to make it go. Those come later.

But what if order isn’t clear? Or multiple components have to be developed for each step of the business process?

The second tie breaker we lean on is complexity. We want to fail fast, so that means taking on the hardest tasks first, as those are the ones that will make or break a project. Whatever the highest point-value task is in the backlog (determined by story point estimation), that is done first. Constructing this component represents the highest risk and effort. Once this is out of the way, it is easier to adapt the smaller/lower complexity items to this component than vice-versa.

When needed, we can use a third tie-breaker: risk. When components are equally challenging, which of them involves the greatest amount of risk? Using Fail Fast, that comes first. The subjectivity here is that Risk can take on multiple forms: it could be the number of downstream components impacted, the criticality of the component, or reliance on outside dependencies.

How does this work:
Say we are building a car. I don’t know enough about automobiles to get into details, so our car will be the Flintstones Mobile.


This car has wheels, frame, steering wheel, seats and a cover broken down as follows.

ComponentPriorityWhy it is critical
Wheels1Can’t drive without wheels
Frame1Holds everything together
Steering wheel1Can’t steer without it
Seats1Nowhere to sit without them
Cover1This is our market differentiator, can’t sell it without it

So now everything is a priority. Differentiating Viability from Marketability is a start.

ComponentPriorityWhy it is criticalV or M
Wheels1Can’t drive without wheelsV
Frame1Holds everything togetherV
Steering wheel1Can’t steer without itV
Seats1Nowhere to sit without themV
Cover5This is our market differentiator, can’t sell it without it.M

That didn’t get us very far. Where to go from here: What is needed first? Frame first as it holds everything together.

ComponentPriorityWhy it is criticalV or MOrder
Wheels2Can’t drive without wheelsV2
Frame1Holds everything togetherV1
Steering wheel2Can’t steer without itV2
Seats2Nowhere to sit without themV2
Cover5This is our market differentiator, can’t sell it without it.M

Making progress, but still have some ties to deal with. What is the complexity? Chiseling the stone is the hardest amount of work, so that happens first. Both wheels and seats look like stone. Follow-up the stone work with carving the steering wheel. That puts us here:

ComponentPriorityWhy it is criticalV or MOrderComplex
Wheels2Can’t drive without wheelsV21
Frame1Holds everything togetherV1
Steering wheel4Can’t steer without itV22
Seats2Nowhere to sit without themV21
Cover5This is our market differentiator, can’t sell it without it.M

Almost there. Between the Steering Wheel and Wheels, the Wheels involve more risk. We need to do those first. With that last tie-breaker, we have now helped out Product Owner sort and order how to build our Flintstones car. If Fred is called into Mr. Slate’s office, he can now explain and justify his reasoning.

ComponentPriorityWhy it is criticalV or MOrderComplexRisk
Wheels2Can’t drive without wheelsV211
Frame1Holds everything togetherV1
Steering wheel4Can’t steer without itV22
Seats3Nowhere to sit without themV212
Cover5This is our market differentiator, can’t sell it without it.M

In summary, when prioritizing by business value fails, turn to the tie breakers of: 1) what comes first; and 2) what is most complex. Between those two tie breakers, we have rarely had problems in prioritizing our backlog in Agile development methodologies. Keep it simple and defensible, so your Agile Product Owner can do their job and keep the powers that be happy.

Subscribe to be notified of new Celerity Insights