In an effort to deal with the number of “top priority” tickets, management has come up with a new priority level, “urgent”, to help differentiate between tickets that are “top priority” and tickets that are actually “top priority”.

So as you can guess all tickets are now codified as “urgent”.

I’ve suggested management downgrade some tickets back to merely “top priority” as we’re clearly right back where we started with it being difficult to determine which order to do tickets in.

They’ve ignored my request as the bletherings of a clearly unenlightened peon, and have instead came up with a new priority, “mission critical” which will be reserved for the most hallowed of emerg— oh no wait everything is now “mission critical” who would have guessed?

So “Top priority” is the now lowest priority a ticket can have…Naturally.

Once upon a time, when I worked in a software house, I was on a call with my boss and a client. The client sent an Excel file with a list of bugs to fix and some small changes to add to the system, all of them marked as priority 0 (the maximum one).

Boss: - I see every task here has the same priority. Can you prioritize them properly, please?

Client: - Oh, everything there is urgent and should be done as soon as possible.

My boss insisted on his demand and the client gave about the same answer again.

Boss: - Ok. Then we will start from the top and will work it down the list--

Client: - No way! We need this task on line XX to be done first, then the task on the line YY could be the next--

Boss: - So there IS some tasks more important than others, then?

(A moment of silence)

Client: - Yes...

Boss: - Then could you prioritize them for us?

(Another silence)

Client: - ok, I'll do that

----------
And this, my friends, is how you get your priorities sorted out :D

If you have time (and the will) to help them sorting the tasks, I suggest you to use an Insertion Sort, so your manager only have to look at one task at time and compare with the list that will come out sorted at the end.

You can do it directly in one column of the kanban board.

@tokenguy nice

I’m impressed by their ability to come up with such creative names for new priorities and I would love to see how it would continue.

@Lensflare My money is on “Platinum Megatron 6” next.

Just a wild guess.

If more than one ticket has maximum priority, then you can choose which one you want to do next based on personal preference and what priority the ticket should have in _your_ opinion.

Nothing to complain here. Accept your freedom.

Order tickets by: type > priority > timestamp > title

type: hotfix > bugfix > feature
priority: high > low
timestamp: old > new
title: in natural sorting order

@SuspiciousBug Software has a purpose. What is important and what isn't, depends on the needs of the user - which often change over time. It often happens, that bug fixes are less important than new features (especially at the start of an application's lifecycle).

So if you want to order tickets, try to go for current user needs primarily. You should become able to automate that at roughly the same time as you become able to automate the requirement extraction from the customer and the actual coding...

Task priority misnaming mirrors economical inflation so perfectly! Words just go by losing value over time in pace with how those who use those words lose confidence from labour and suppliers.

I would start buffering even-higher priority terms, those will be necessary exponentially faster.
In increasing order of urgency, starting from your examples:

Top Priority
Urgent
Mission Critical
Platinum
Platinum Megatron
Platinum Megatron 6
Diamond
Black
Advantage
Premium
Prime
Neo
Diamond Advantage
Premium Black
Neo Prime
Exponential
Unlimited
Unlimited 2.0
Unique
Unique 2.0

Don't forget to compute the geometric progression, you might end up needing a new term before even using the current one. Welcome to hyperinflation!

@JsonBoa Great idea! Implementing this is now priority “Unique 2 Electric Boogaloo”

@Oktokolo
Sorry, what I meant was: when multiple tickets have the same prio, just start with the oldest ticket.

As to "bugfix > feature": What good is a feature that does not work? Don't clog your backlog with tickets that are never going to be resolved; delete or archive them. It might resurface, it might not. It all depends on the sprint (which is already a prioritization of tickets).

@SuspiciousBug "archiving" or deleting tickets that likely will never be resolved is okay - if they aren't actually bugs. Never do what the big browser creators do: Cleaning unloved bugs away to make the bugtracker look good. The ticketing system shouldn't be a PR tool.

It is perfectly normal to have hundreds of tickets representing bugs and minor improvements of which a lot likely will never get fixed/implemented. But normally, they are actually meant to be done - there just isn't enough dev power available to do so.

Obviously, that doesn't go well with Scrum's backlog - which is supposed to not be massive. But you can group your minor GUI bugs and put "Minor GUI bugs" into your Scrum backlog instead. "User wants the system to act and feel less confusing" is a valid story. Having rather loosly defined bughunt sprints makes sense. You actually should have generic code improvement sprints too - but i get, that that will forever be a dream in almost all companies...

I actually think top-limited priority systems are detached from the way people determine priority. You will never have a task that is "less important than 20 other levels of importance". You will have tasks which are more important than some specific group (sometimes everything else) and you will have tasks at the bottom whose importance isn't strictly ordered and so bumping into a lower bound for priority isn't an issue. This is especially the case if you represent priority inversion or the time margin using the priority numbers, both of which can cause huge spikes in the priority of certain tasks.

Itil has solved this problem long ago. Look up at itil's definition of severity and impact.

Works like you wouldn't believe!

Not a single ambiguous priority in the 3+ years I worked by it

When will management learn: if every thing is the highest priority, nothing is high priority

You could bet with your colleagues (if any) to see what will be the name of the next “toppest” priority.

I suggest “Do this NOW or EVERYONE DIES”.