When I started, there was P1, which was only used if production was effectively down, P2, which meant it had to go in the next release, and P3 and on down.
Of course everybody had issues they really wanted fixed - more than we could do. People realized that P3 bugs stood a good chance of missing the release - and might not get fixed for the better part of a year if they did.
So almost all bugs started becoming P2.
This obviously didn't work, so to supplement that, we had a system of "Shadow priority" - that is, there'd be P2 tickets that "important" managers really cared about and thus had to get done. This got a bit tiring because of the number of managers and their shifting priorities. I remember a spreadsheet where the rows highlighted in green were "true" P2s.
Thus we created a new priority field, "relative importance", because everything was P2...
And guess what, the process repeated; everything became high relative importance.
By the time I left - and I did send an email complaining about this to my boss - I think we were up to 5 different places to look for priority, including a spreadsheet that would be shown at meetings but not circulated. The logic for figuring out priority was incredibly complicated, since certain types of priority overrode others. There might be P3s that were more important than P2s because they were the pet issue of a certain manager, for instance. There was a separate notion of "QA Priority" and "Manager Priority" (manager priority, on the spreadsheet, even had P0)
Of course, what developers thought never was a big consideration.
For the longest time, I just thought it was the inevitable result of bureaucracy, and yet, here I sit at a job where, for almost 5 months, we've had a backlog that we all are involved in creating; the priorities and rationale are explained to us... and best of all, the most important things are at the top! That's all I need to do, look at the top of the backlog.
And somehow I spend almost no time waiting on requirements, and none waiting on "database" (which isn't even a team). Fixes I make get reviewed a week later at the absolute latest.
I'm not sure why, exactly, this is. Clearly our situation is more desirable - so why did the old one happen at all? I don't feel like any of the teams at my old company were incompetent, evil, or stubborn. It was just the way we did things.
(:With the possible exception of the sworn enemies of the dev team, ProdOps née SOC AKA the SysAdmins. But then, the inter-team rivalry was more of a symptom than an actual cause.)
Edit: Although I do think there needs to be a way to handle simple things - wait for it - simply. "Oh, this field is broken, I know why, I can fix it in 15 minutes" should be enough - no need to have people estimate with too many metrics.
Going metrics crazy can slow things down pretty badly, too.