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.
