Our company became determined to control such panic-driven prioritisation, and had four simple levels of importance, P4 up to P1, a predictable conveyor belt delivering work.
Equally predictable was the later addition of P0. Followed inevitably by P-1. Sadly the company was bought out before we learnt whether the underlying datatype was a signed short or a long...
I've seen good success with having an entirely different pipeline for rushed/rapid/panic tickets. The rapid pipeline reduces some of the ticket and procedural bureaucracy of the normal pipeline, and only lasts a sprint. That obviously comes with risk, so putting something in the rapid pipeline needs to be weighed properly.
The somewhat untold benefit of this system, is it makes the product manager or client decide between "I want to control this ticket" and "This needs to be done as fast as possible". That seems to naturally filter out tickets that are only superfluously high priority.
A standard ticket pipeline might look like this:
Backlog > Review/Estimate > In Progress > Internal Review > Testing > Client Review > Feedback > Testing > Release
But the rapid pipeline will be more like:
Create Ticket > In Progress > Testing > Release
This leaves the ball almost entirely in the developers court, and removes any step that requires waiting for feedback from the client or even the Project Manager.
So you can see the risk factors pretty quickly, with no review steps what if the developer gets it wrong? So that leaves the Project Manager some important questions: Is this ticket concise enough to be rapid? No room for back and forth discussions or muddy details. Is this ticket small enough to be rapid? Can't be a big new feature that's just being framed as urgent but could realistically wait. Can I trust the developer to get this right with no review? If you can't, then it's probably best it goes through the standard pipeline with the review steps anyway.
In big enough teams it can help manage workload, you can leave a specific developer intentionally under-utilized so that they have space for rapid tickets. During their under-utilized time they can be open for mentorship/learning/pair-programming until a rapid ticket pops up.
That is so familiar that I seriously wondered if we had crossed paths at a previous job. The only difference being our priority was the other way around P4 being the highest.
Basically all tickets would naturally migrate to P4. Eventually when someone started working on 'the wrong thing' another level was added.
In my current job we use Jira and the backlog has things at the bottom which have been just added, things at the top which we thought were priorities at some point and a whole bunch of crap in the middle which is unordered.
I keep thinking about some kind of system where people would rate the priority of one ticket against each other rather than against an arbitrary scale.
That’s the whole point of that backlog. The order should reflect the priority of everything relative to everything else. You drag stuff up above other stuff that is lower priority and part of everyone’s job is to groom that list so it reflects reality.
While that may be true in theory in practice it is difficult. A big improvement would be if new things needed to be inserted into the backlog at an appropriate place but I don't know if it's possible to do that in Jira.
This, I think, is exactly why everyone I know who is happy with their backlog management does it in an Excel spreadsheet or Google Sheets.
I'm fine with ticketing systems for handling immediate work in progress. Which, incidentally, is what they're meant to be used for. Every time I've ever seen people try to juggle business priorities and long-term goals in a ticketing system, though, the end result has always struck me as being something of a failed experiment to develop a product that works well as both an ice cream topping and an engine lubricant.
That ticket comparison idea is awesome. You could have it for one person, or do it democratically.
I bet there'd be circular comparisons (A>B>C>A) a surprising amount of the time. Not a huge deal, you could just show the pairings back again in a different order until they resolve.
I wrote a toy app when learning iOS that took the items in a todo list and showed you two at a time. You’d swipe the less important one off the screen. It built a hierarchy and you’d end up with the “most important” item to focus on. It remembered previous choices (or you could start over) to make finding the next item quickly, with just a few more choices.
It connected with the Reminders app and the Wunderlist API. I wonder if I could revive it with more services…
We've been doing that for a few years now. Basically we have two queues: The queue for escalated defects, and an ordered queue of about 10 prioritized enhancements that we've ordered based on what we think is most important comparatively. There is also a backlog of ideas/garbage work.
It works fine, except that the product is complex and old enough (and the team has too few developers so) that the bug queue rarely gets to zero.
This works well in theory, until managers urge you to treat every task as "P-0" and you suddenly need to prioritize within the P-0's (we would jokingly use negative numbers instead).
Equally predictable was the later addition of P0. Followed inevitably by P-1. Sadly the company was bought out before we learnt whether the underlying datatype was a signed short or a long...