Imagine never fixing that bug, never releasing that feature and never improving your onboarding experience — all you have to do is prioritise!
A Story of Infinite Priorities
Let me set the scene: a fast-growing software company uses JIRA to manage development but, for some mad reason, whoever setup the account decided not to use its default priority field and opted for a custom number field instead, expecting a number from 1–10.
Their backlog is growing and it’s becoming harder to determine which item should be worked on next. In lieu of a Product Manager, as is common in startups and SMEs, CXOs determine priority almost ad hoc and whoever screams the loudest gets their favourite items done.
Then it happens. Something big. Suddenly all other work must stop because now we have a work item so important it transcends the 1–10 scale. That’s right, this item’s priority is 11.
Dial it up to 11 and rip out the field from the Copy of Default Screen screen in the Default Screen Scheme 2 that’s assigned to that particular issue type
Fast-forward a few months and we’ve had a few more 11’s come through, but then something else happens and everyone concedes the 1–10 scale doesn’t work and everyone agrees a 1–100 scale, with larger numbers and more granularity, will make it easier to put things in the “right” order. Except for anything that was “prioritised” by the old system that now sits at the bottom of the barrel.
Fast-forward again, substances are flowing through fans and creeks alike, emails with exclamation marks in the subject are being sent, and we have an item for which priority=101.
I’ll spare the rest, you can see where this is going. It got to, and I yank your leg not, 1,000,001. One million and one. Now that’s a high priority JIRA ticket.
If you’re not careful, highest-priority items get done and everything else gets forgotten.
— Me, just now
The point is that in a world of ever-increasing priorities, older items just don’t get done; and therein lies the problem.
But our priority system isn’t numerical
It’s highly unlikely your situation is that ridiculous, but I’m willing to bet that many a software management tool has this sort of prioritisation system. If it encourages us to think it possible for an item to be low-priority then it allows us to create something that may never get done. Alternatively, if it steers us towards priority being a measure of something else then does it really guide us to answer the question “What next?”.
The fundamental problem is that we think of “priority” as a measure of something, some sort of unit or scale, a metric that refers to one thing and one thing alone – but it doesn’t have to and if it does then it’s either useless at best or detrimental at worst.
JIRA’s default priorities don’t help:
- Highest
- High
- Medium
- Low
- Lowest
The default description for the lowest priority is “Trivial problem with little or no impact on progress”. Does that sound like something that you’ll ever care about enough to do?
If your priorities measure a single metric then unless you’re micro-managing you’re simply identifying items that will never get done.
– Me again, saying pretty much the same thing in a different way
If we allow a measure like this to determine when things get done then by the time one Highest or High item is done there’ll be another to take its place before any other priority is considered. Or we ignore the field and prioritise something Medium or lower first, in which case we have to question the point of the field in the first place.
Someone’s created an item, spent time specifying the detail, it may even be part of an Epic that relates to a product initiative, and we’re just going to say “Nope, not happening, don’t know why you bothered”?!
Prioritisation is categorisation not sorting
Try this idea on for size: “Priority” doesn’t have to be a scale of a single attribute. Furthermore, it should not be what determines the order in which items are done, but it should guide Product Managers to select the order in which items leave the safety of the Backlog and venture out into To Do.
Here are the priorities I use and their descriptions:
- Blocker: Worthy of halting all other work for
- Critical: A serious item that should be prioritised
- Normal: Default. Average. Most things. 90% of everything.
- Trivial: Small problem with an easy fix or workaround
Why these? I’m glad you asked:
Blocker
A blocking issue is business-critical. It means something is seriously whiskey tango foxtrot and needs to be done ASAPPP (As Soon As Physically Possible Please). Would you be happy if all other work stopped to focus on this issue? If yes, it’s a blocker; if no, it’s not a blocker — and if you have more than a few of these a year you’ve probably got bigger problems.
I should add that in practice you probably wouldn’t halt all business operations but you would pull people from other tasks to swarm on a blocker.
Critical
This can mean one of two things: a critical path item that’s necessary for the success of a project or an important issue that’s not worth halting other work for but should be done before non-critical items.
For example, it may be an infrastructure item that’s likely to bite you in future or just something with a real-world cost attached and unless it has a very real cost in time, money or opportunity associated to it then it shouldn’t be this priority.
Normal
Pretty much everything. Like 90%, maybe 99% of all items. Like if not this then you better have a good reason why. Like seriously what does this even mean? It’s just a work item, don’t stress over its priority.
Trivial
Not trivial in importance but trivial in time/effort/complexity/whatever. The sort of item you prepare for 4pm on a Friday. It’s quick, it’s easy, it may be low-impact but it needs to be done anyway.
Under another prioritisation system, it just wouldn’t get done. But you should always always always have several of these on-hand. They also make great training tasks for new hires.
How to guide development
Like I said earlier, priority “should guide Product Managers to select the order in which items leave the safety of the Backlog and venture out into To Do”. Obviously blockers should be worked on first but how many do you actually have? One a month?! If I were seeing a new blocker every month I’d permanently be a donkey on the edge.
When it comes to the order in which things actually get developed we have to look at other things that depend on your methodology (Scrum, Kanban, etc.) but when it comes to “What should I queue up for devs?” you need to provide a mix of priorities!
My current thinking is taking me away from Scrum and closer to a hands-off Kanban in which I provide an environment in which developers can own work from coding to delivery and that means ensuring there’s always something someone can do next.
If someone finds themself at a loose end at half three on a Friday, they can pick-up a Trivial item. If they’ve just had a coffee and they’re all fired-up and ready for something important, grab a Critical.
If you’re a normal human being and it’s a normal day and you’re in a normal mood then do a normal item because like 90% of them are normal. And if there’s a single Blocker then f*ck everything else and do it amirite?!
How do developers know what to work on next?
I’ll cover this in a separate post. How’s that for an ending?