Queue Management
Queues are hidden WIP—and they're everywhere in software delivery.
1Queues Are Hidden WIP
Every queue is work in progress that's not being progressed. Queues are where work goes to wait.
Obvious queues:
- The product backlog
- The PR review queue
- The QA testing queue
- The deployment schedule
Less obvious queues:
- Tickets "assigned" but not started
- Code waiting for CI to complete
- Decisions awaiting approval
- Questions waiting for answers
Queues are sneaky. They look organized—after all, the work is tracked and prioritized. But they're WIP. Every item in a queue adds to lead time. Every queue is a place where work waits instead of flows.
The Backlog Problem
A large backlog feels like you're organized. In reality, it's inventory. Most items in a large backlog will never be built, become stale before they're reached, or require significant re-discovery. Small backlogs aren't a problem—they're a feature.
2Why Queues Grow
Queues grow when arrival rate exceeds departure rate.
If work arrives at a rate of 10 items per week and the stage can complete 8 items per week, the queue grows by 2 items weekly. After 10 weeks, there's a 20-item queue.
Near capacity, queues grow exponentially. At 80% utilization, queues are manageable. At 90%, they grow faster. At 95%, they explode. This is queuing theory—mathematically proven.
The trap: Managers see a queue growing and think "we need to work faster." But often the problem isn't speed—it's overload. The arrival rate exceeds capacity. Working harder doesn't fix the math.
Solutions:
- Reduce arrival rate: Say no to more work. Be more selective about what enters the system.
- Increase capacity at the constraint: Cross-train. Automate. Add resources where the queue forms.
- Limit WIP: Prevent work from entering until there's capacity to complete it.
The last option—limiting WIP—is often the most practical. It doesn't require hiring or major changes. It just requires discipline to not start more than you can finish.
A product backlog has 800 items. The team completes 10 items per sprint. At current rate, clearing the backlog would take 80 sprints (3+ years). Most items are stale. The backlog isn't a plan—it's a graveyard of good intentions.
A team limits their backlog to 2 sprints of work (~20 items). New ideas are captured but not added until space opens. Items that sit too long are reviewed and often deleted. The backlog stays fresh and meaningful.
3Classes of Service
Not all work is equal. Some items are urgent. Some are standard. Some are time-fixed (must ship by a date). Managing queues effectively means handling different types differently.
Classes of service define categories of work with different treatment:
Expedite: Drop everything. This must flow immediately. Very rare (1-2% of work). Often for production emergencies.
Fixed date: Has a deadline. Needs capacity reserved or special tracking.
Standard: Normal work. Flows through at normal pace.
Intangible: Improvement work. Tech debt. Low urgency but important. Often scheduled as a percentage of capacity.
The mistake is treating everything as expedite. When everything is urgent, nothing is. Expedite lanes only work if they're rare.
Classes of service help manage queues by:
- Ensuring truly urgent work flows fast
- Protecting capacity for deadline work
- Preventing urgent work from crowding out important work
- Making trade-offs explicit
The Expedite Test
If more than 5% of your work is 'expedite,' you don't have an expedite lane—you have a chaotic system. Either things aren't really expedite, or something is structurally broken upstream.
- Queues are hidden WIP where work waits instead of flows
- Near capacity utilization, queues grow exponentially
- Limit arrival rate or increase capacity—don't just work faster
- Small, fresh backlogs are better than large, stale ones
- Classes of service help manage different work types appropriately