> whether a ticket was “critical” or merely “high?” or truly a blocker

Wait until they start adding additional categories like critical blocker, high blocker, severe blocker, exceptionally severe blocker, etc. etc.

Now apply that category soup to tracking both priority and severity.

Infinity blocker, infinity + 1 blocker

I certainly have, but I have rarely regretted spending the time to prioritize my work before starting my work and/or discussing the same with my team. Like pretty much all work of all kinds, there is variance in how long it takes and how effective the outcome is per person-minute.

These categories on ticket have little to do with me prioritizing my work. There are thousands tickets in each of those categories.

>spending the time to prioritize my work before starting my work and/or discussing the same with my team

And in the past, I did regretted opening unnecessary discussions quite a few times. I learned not to do it, because it ended in endless bike shedding or conflicts and there were no special gained insights. Turns out, I can do trivial decisions by myself.

This seems like a highly dysfunctional state of affairs. Maybe I've never worked at an organization big enough to suffer from this kind of thing.

Exactly, there’s a fine line between prioritization and bikeshedding.

If ticket priority does not matter, then why do you care? Set them all to single priority and don't think about it.

If priority does matter, then why "waste"? Lets say you get rid of tickets.. then your statement becomes:

"You've ever wasted a few minutes on whether a bug you found is worth mentioning in release notes? Or if it truly should cause revert of deployment?"

When said this way, doesn't seem like "waste" to me, rather a regular part of the job. If the person working the bug doesn't know how bad it is, then who does?

> If ticket priority does not matter, then why do you care?

Because when you have a ticket priority system, there is often someone external who cares deeply about ticket priority. And reporting requirements around ticket priority. And metrics about ticket priority over time.

If you've never been pulled into a meeting with Comms and Legal to discuss retoractively whether a (completed) ticket should have been labelled High or Severe... count yourself lucky

> You’ve never wasted a few minutes on whether a ticket was “critical” or merely “high?” or truly a blocker?

Calling "deciding on how to spend your time" a waste of time seems a misnomer.

But ... that person is not deciding how he will spend time. He is deciding which labels to put on ticket. What he will do is not directly related to that.

What's a priority but a way to decide what to do next? The fact it's stored as a label on a ticket doesn't seem particularly relevant.

The discussion over what priority label to put on a ticket has very rarely changed my opinion on what the actual importance of the ticket is, and I'm generally going to pick what to work on based on that, not based on the label.

It is a way to categorize tickets. It somehow influences what is going to be done next, but it is only one of many factors.

One project manager in our company started to actually use it for prioritization, the higher the priority the sooner it was done. Soon after, literally everything ended to labeled critical.

People shouldn't be able to label their own bugs/features' severity or importance. They should be able to label it with severity or importance to them, and the team responsible should be allowed to triage accordingly.

Absolute priority quickly becomes washed out - everything gets shoved to one end of the range.

A useful priority scheme might be, insert the ticket in the list of open tickets by urgency and importance. Something like that, that you can actually make arguments about and compare.

Almost every software company I've ever worked with had this insidious "priority inflation" that couldn't be stopped. It works like this:

We start out with some sensible definition of priority for bugs: P3 = nice-to-have, P2 = low-priority-but-ship-blocking, P1 = emergency-fix-this-now. Bug intake goes on for a while under this system. Some bug filers don't feel their P3 or P2 bugs are getting worked on, so they "promote" those bugs to P2 and P1. That'll show those engineers my bug is important! Now we seem to have more and more P1 emergencies going on, and the team is struggling to just get through those. Nobody knows which ones are actual emergencies, and which ones are just "somebody being passionate about a bug".

Soon, we get an actual pants-on-fire production emergency. This emergency is more urgent than any P1, so we call it P0! Now we finally have a way to mark real emergencies, because the bug database is now overflowing with P1s. Soon people realize they can deem their favorite bugs as really-really-important, so they promote them to P0. Eventually, the database is now overflowing with P0s, and nobody knows what's really urgent. Then another real pants-on-fire production emergency happens...

I worked at a shop with P0, and then there were too many P0 tickets, and then you just worked on whatever the CTO told you was the _actual_ highest priority ticket when he stopped by your cubicle for a chat.

No one got fired for making something a P0. That's the problem.

Seems like an easy fix.

1) Allow developers to change the priority, i.e. downgrade P0 to P1 or P2, with all subscribers notified. Optionally, always downgrade to the lowest possible priority.

2) Shame people for inappropriately using P0. After a few strikes, remove their ability to do so.