4 ms·

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 b

by 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

by ehnto 6y ago

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