The ability to show the priority of a given piece of work is pretty important, I think all would agree. But what is the best way of recording and showing this information? Unfortunately the most common method, using a priority flag, is far from the best.

Most users of work-managing software will encounter plenty of priority flags, usually set by some kind of dropdown control. There’s no consistency between systems in terms of the vocabulary or number of choices that are offered; sometimes the choices are mere numbers, sometimes words, sometimes a mix. And even within a specific set of users of a single system it is rare to have universal agreement on what a ‘2’ or a ‘Minor’ actually means, or when each should be applied. One man’s Blocker is another man’s P4, it often turns out.

And this vagueness often (always?) leads to a dangerous phenomenon – ‘priority inflation’, analogous to grade inflation, where far too many tickets end up in the the very top priority buckets, rendering your prioritisation system useless.

This phenomenon is easily explained by simple psychology. When you are entering work into a system, it’s usually because you want it to be done. Let’s say you have 5 different priority levels to choose from; you know that a prio 5 ain’t gonna get done before the Heat Death of the Universe, and probably a prio 4 is in the same boat. So really you’re now choosing between prios 1, 2 and 3. But you know that everybody else thinks that way too, so it’s probably safest to make your task at least a 2 just to be safe. Or if there’s the slightest bit of genuine pressure for that piece of work, in which case the temptation to put a 1 is almost overwhelming.

After all, there’s rarely anything in a priority flag system that limits the number of allowed P1s, such as a “one in, one out” rule. So why not chuck it in the top buckets, as everyone else is doing?

And so priority flags lead to priority inflation. In the worst case virtually everything ends up as a P1 – or perhaps there are so many P1s that it’s utterly unclear what really needs to be done first. So the whole system has collapsed.

What is the alternative? It’s simple; instead of a priority flag, you maintain a priority-ordered list of work, with the most important thing at the top. When a new item comes in (or an existing item is reordered), other items have to move to make room for it. In other words, you have to make a trade-off decision – “sure, this thing can go up …but something else has to go down”.

Trade-off decisions are hard. But prioritisation in a world of limited resource is genuinely difficult, and it’s better to face up to reality than to hide from it. Any worthwhile system for representing priority should force decision-makers to confront trade-offs, rather than allowing a pseudo-decision. In priority-ordered lists, there is no such thing as ‘two items that have the same priority’, so the trade-off decision has to be made. In a priority flag system, by contrast, you can have half your total backlog categorised as a P1, and nothing tells you that you have a big problem – until the customer finds that their deadline has passed and their P1 work never got done.

In the world of software development teams, you do often find priority-ordered lists. They exist at the strategic level, ie the product backlog and/or strategic roadmap. They also exist at the tactical level, the Agile Board, as long as each column on the board is only one-ticket wide. In such a setup, a ticket’s increasing priority is shown by moving it up (the yellow ticket), but the board demands that the necessary trade-off decision is faced up to, and displayed for the world to see – the red and green tickets have to go down.

So one of the advantages of representing your work on an Agile Board with one-ticket-wide columns is that you can show priority the good way – every column is a priority-ordered list. This will turn out, as we will see in a future article, to be a key ingredient in reading the entire board correctly, when we don’t just have to worry about one column on its own, but need to be able to prioritise columns of tickets against each another.