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.
| Component | Priority | Why it is critical |
| Wheels | 1 | Can’t drive without wheels |
| Frame | 1 | Holds everything together |
| Steering wheel | 1 | Can’t steer without it |
| Seats | 1 | Nowhere to sit without them |
| Cover | 1 | This is our market differentiator, can’t sell it without it |
So now everything is a priority. Differentiating Viability from Marketability is a start.
| Component | Priority | Why it is critical | V or M |
| Wheels | 1 | Can’t drive without wheels | V |
| Frame | 1 | Holds everything together | V |
| Steering wheel | 1 | Can’t steer without it | V |
| Seats | 1 | Nowhere to sit without them | V |
| Cover | 5 | This 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.
| Component | Priority | Why it is critical | V or M | Order |
| Wheels | 2 | Can’t drive without wheels | V | 2 |
| Frame | 1 | Holds everything together | V | 1 |
| Steering wheel | 2 | Can’t steer without it | V | 2 |
| Seats | 2 | Nowhere to sit without them | V | 2 |
| Cover | 5 | This 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:
| Component | Priority | Why it is critical | V or M | Order | Complex |
| Wheels | 2 | Can’t drive without wheels | V | 2 | 1 |
| Frame | 1 | Holds everything together | V | 1 | |
| Steering wheel | 4 | Can’t steer without it | V | 2 | 2 |
| Seats | 2 | Nowhere to sit without them | V | 2 | 1 |
| Cover | 5 | This 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.
| Component | Priority | Why it is critical | V or M | Order | Complex | Risk |
| Wheels | 2 | Can’t drive without wheels | V | 2 | 1 | 1 |
| Frame | 1 | Holds everything together | V | 1 | ||
| Steering wheel | 4 | Can’t steer without it | V | 2 | 2 | |
| Seats | 3 | Nowhere to sit without them | V | 2 | 1 | 2 |
| Cover | 5 | This 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.