Changing Your Priorities

The what, how, and why of prioritizing development work

This article first appeared in agile-thoughts

What should we do next? What’s the most important thing? What’s the most urgent thing? What’s the riskiest thing? What’s the surest thing? What’s the quickest thing? What’s the thing that is likely to have the greatest long-term financial return on investment? What’s the thing that creates the most opportunities? What’s the thing that most likely generates the greatest revenue in the short term? What’s the thing that will most benefit the development team? What’s the thing that is currently of most interest to our customer? What’s the thing that we should already have done but haven’t? What’s the thing we can do now that we couldn’t before? What’s the thing that we keep putting off?

And so on.

That’s a lot of questions.

And they are all different. Some of those questions may share similar answers, but others may be quite divergent. Many people try to collapse this diversity into a single tidy concept to organize the timeline of their development: priority.

Such an approach, however, often does more harm than good because the way priority is often used is based on misunderstandings, miscommunications, and oversimplifications. Prioritization is often debated, but rarely clarified. A remarkable amount of energy has been spent on creating and following different prioritization schemes — from MoSCoW to Kano to a variety of numbered systems — but much of this energy is misdirected, promoting a false sense of precision in the absence of meaningful accuracy.

Priorities form a landscape, not a line

Priorities can be cast with respect to quite different criteria, each of which may be valid and sensible to consider, but each of which may be also in competition with another. For example, urgency is time sensitivity in the present, but not necessarily the future. One thing that is more time sensitive than another thing is not necessarily more valuable in terms of revenue. Derisking by doing something early may offer valuable feedback to the development as a whole, but may not itself have much financial value. In recognizing that priority is not a singular concept, we should not be looking to make it one just for the sake of linear ordering. Priorities form a landscape, not a line.

To make sense of this, we need to change the way we talk about prioritization. Unless the context has already made it clear, we should shift from plain prioritize to prioritize with respect to…, stating what criteria we are considering. Once we know what we’re talking about, we can determine the paths through the landscape we can take and the ones we should avoid — roadmaps are only interesting or useful when they have more than one road. We may find that one person’s idea of prioritization is radically different to another’s. And, even when seemingly similar, we may find that seemingly subtle differences are bigger than they first appear.

Take, for example, the popular but vague recommendation to prioritize with respect to business value. Although well intentioned, there is no specific and actionable recommendation here. What do we mean by business value? Do we mean valuable for the business as a whole, for part of the business, for the team, for the product owner as an individual (yes, any position of influence can easily get wrapped up in politics and personal ambition), for the owners of the business…? Do we mean value in monetary terms or in terms of utility or in terms of opportunity or…? Do we mean short term or long term? Business value can be many things, all of which make sense, but all of which are different. The lack of concreteness is an opportunity for clarification that should be welcomed rather than glossed over with handwavium.

But clarification is not the only issue confronting prioritization by business value: the biggest obstacle to such prioritization is that it is impossible to do. This is a matter of physics rather than methodology. Unless you have a time machine, it is not possible to determine the business value — whatever we have chosen to mean by that — of a feature or a product you have not yet developed, let alone deployed. Only once you have built it, shipped it, and then determined a time frame over which you are considering it, can you state its value with any confidence. This isn’t to say you don’t have a good idea of its likely or possible value (although humans are notoriously overconfident and error prone in this…), but estimated value is not the same as actual value. Our language should reflect honest caution rather than suggest unwarranted confidence. We can prioritize with respect to estimated value but we cannot prioritize with respect to value.

What if…?

We’ve seen the ways in which we can prioritize, but we should turn our attention to the elephant in the Zoom: Why are we prioritizing? Is it so that we can answer the question this article opened with: “What should we do next?” Maybe… but not always… and not necessarily.

A simple thought experiment will help us see past the veil of our assumptions. Thought experiments let us turn the dials up to eleven and engage in hypotheticals without cost — as well as break the laws of physics.

I want you to imagine for a moment that our teams have infinite development speed. In practice, this means not only that it takes zero time to develop a feature, but that it takes zero time to develop all the features (and, in fact, zero time to develop all the features beyond all the features… you get the idea). The moment you want it, it’s done. How much prioritization did you have to do? None. How much time planning did you have to do? None. (Don’t get too excited and ask where to sign up for this process model — remember this is a thought experiment.)

OK, so let’s slow things down a bit. Every piece of development takes some time, but not much. For convenience, let’s say that each piece of work takes the same amount of time, a fraction of a second, and there is no variance. (Again, cool as it sounds, this is still not real. I won’t be offering certified training.) Quite literally, we need to ask what happens now and what happens next? We have no challenge in getting all the work done for a feature, a release, or a whole product, but we now have to consider how we sequence our work. We cannot do everything simultaneously, so there must be some kind of ordering. There is something we do first, something we do after that, and so on. Are we prioritizing yet? No. There is no sense that one piece of work must necessarily take precedence over another, but we have to respect the passage of time. Our work must have some kind of ordering, and we have a choice in that.

Now, let’s add more duration. We don’t need to add the complexity of variability, we just need to add enough duration that means we cannot get all of the possible work done by the time we want it. The work has exceeded our capacity. Now we have to prioritize. Now we have to make a decision about what to keep and what to drop in the coming release or time frame. This is where all those different prioritization criteria come into play.

In other words, prioritization becomes significant when we have more work to do than we can handle in a given time frame. Prioritization is about what we give time to (and what we don’t), but it is not necessarily about time ordering. It becomes more strongly entangled with time ordering when we further loosen the reins on our constraints and let variability and uncertainty back into our world. Priorities may inform the order in which things are developed, but they do not necessarily dictate it.

Buggy thinking

We can’t do everything all at once, and we don’t have enough time to do everything. That’s why we prioritize. If we look at any prioritization scheme from a distance, we can see that in practice there are only really three priority categories: we’ll do this now; we’ll do this later; we’ll never do it. There is a brutal truth to the last category that many find hard to accept, but if we observe the dynamics of any system that uses priorities, we will see this play out, no matter how mathemagically clever and intricately numbered our priorities are. Of course, we don’t always know in advance which work won’t get done, otherwise we could cut to the chase and drop those items early. There are, however, some approaches that make it easier to identify such cases in advance.

One thing we have not covered is what to do with our priorities. We may have lists of categories — named or numbered — and backlogs of possibilities, but we are still missing a vital ingredient: time. We have not talked about what the priority of one item over another means in terms of when we do each item. It is a common and unstated assumption that priority order dictates schedule order, but that is only one possible scheduling discipline — and it is often not the best choice. We can better understand this by looking at the underbelly of a software system’s development work: the bug list. It’s not feature work, but it is work, and it is often subject to prioritization.

Many years ago, one manager complained to me that the system he managed seemed to be in steady state when it came to bug fixes. Each month the team would fix about as many defects as were reported that month. Their defects were prioritized numerically, and they always started by clearing the highest priority and working down. What this meant in practice was that older, lower-priority bugs were never fixed, and simply became older with time. Without meaning to, they had implemented what is known as an unfair scheduling algorithm. It is unfair because there is no guarantee that every piece of work will have a chance at being done. If the work to be done does not exceed the team’s capacity to do it, then eventually everything will get done. If it does exceed it, then we can easily identify our we’ll never do it category: anything marked as one of the lower priorities is predestined to be ignored.

A number of things can be done to shake up a system that’s fallen into such an equilibrium, but the simplest is to change the scheduling discipline. I suggested they mix up priority ordering with age ordering. In other words, make reducing the average age of defects in the bug inventory a goal of each month rather than working through bugs strictly by the numbers. When it comes to older neglected defects in legacy systems, sometimes the defect has disappeared, fixed or ironed out by other changes over the course of time. This is a great low-effort result! Sometimes, however, the defect is more resistant to fixing but turns out to be the root cause of many other defects. Fixing one bug fixes many bugs in the past, present, and future. Also a win!

I visited another team with a similar issue, but where the prioritization had unintended knock-on effects on customer satisfaction. They had a full inventory of defects, which they ranked across five priorities, but they only ever consistently addressed defects in the highest two priority levels. This guaranteed a denial of service for the lower-priority levels. The criteria used to prioritize the bugs was less a matter of considered assessment and more about who the customer was and how loud they shouted. This leads to consistent neglect for smaller and well-behaved customers.

Not only is this not a good recipe for customer satisfaction, but it illustrates how easily a quantity can unintentionally behave like a financial instrument. Another common example of this is how story-point estimations can, under pressure, become like currencies, subject to quantitative easing, inflation, and speculative exchange rates. As an aside, it was this particular client that made me consciously aware that one of the main reasons we use priorities is because we have more to do than we can do — not necessarily a bad thing when we are thinking of features, but definitely not a good thing when we are talking about defects.

It’s time to change your priorities

Although there are many rituals and strong beliefs around priorities and prioritization, these are often shallow rather than deep. In popular practice, the notion of priority often conflates a number of important but different demands: urgency, importance, risk, time, etc.

We need to understand the small print, being careful and clear with our language, as well as the deep motivation. And having lists of work prioritized with respect to various criteria is only half the story. Priorities may inform the timing, but they are not necessarily the timing. That is a question of scheduling, and prioritization does not imply scheduling except in the simplest cases.

When we understand why we prioritize and how we enact priorities into work, we may understand that, in many cases, we do not need to prioritize better, but need to address whatever it is that prioritization is compensating for. That might be workload, it might be the drag of unmanaged technical debt, it might be distance between different roles in an organization. It might be time to change how you think about priorities.

TL;DR

1. We don’t just prioritize: we prioritize with respect to one or more criteria.
2. We should explicitly state rather than assume the prioritization criteria.
3. When we talk about prioritizing by business value, we should be clear about what kind of value to the business we mean.
4. When we talk about prioritizing by business value, we should say explicitly that we mean estimated not known business value.
5. The main reason for prioritization is that our work exceeds our time.
6. In practice, all prioritization schemes boil down to three categories: do it now; do it later; never do it.
7. Prioritization is a consideration in scheduling, but it is not the same as scheduling.