5 ms·

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 de

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...

ehnto 6y ago
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.
- dataduck 6y ago
  This seems interesting but I'm having trouble visualising it. Would you care to elaborate?
  - ehnto 6y ago
    Sure! 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.
    - sethammons 6y ago
      That is how all our tickets work. We have a lot of autonomy in that regard, put the product owner still sets the priorities
VBprogrammer 6y ago
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.
- jschwartzi 6y ago
  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.
  - VBprogrammer 6y ago
    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.
    - mumblemumble 6y ago
      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.
- travisjungroth 6y ago
mytailorisrich 6y ago
This does not mean that having priority is not useful, this just means that they did it badly. Everything is prioritisation. I'd say that prioritisation is one for the key skill of people leading organisations. People who can't do it will fail whatever tools they use.
vincentmarle 6y ago
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).

ehnto 6y ago

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.

dataduck 6y ago
This seems interesting but I'm having trouble visualising it. Would you care to elaborate?
- ehnto 6y ago
  Sure! 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.
  - sethammons 6y ago
    That is how all our tickets work. We have a lot of autonomy in that regard, put the product owner still sets the priorities

VBprogrammer 6y ago

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.

jschwartzi 6y ago
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.
- VBprogrammer 6y ago
  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.
  - mumblemumble 6y ago
    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.
travisjungroth 6y ago

mytailorisrich 6y ago

This does not mean that having priority is not useful, this just means that they did it badly. Everything is prioritisation. I'd say that prioritisation is one for the key skill of people leading organisations. People who can't do it will fail whatever tools they use.

vincentmarle 6y ago

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).