Thirty-Four Items Waiting for QA

The arithmetic

• 34 items in flight with an 11-day wait implies QA throughput of roughly 3 items per day (Little's Law: cycle time = WIP / throughput).
• Halving the wait to about five days requires roughly doubling throughput, so three additional testers on a team of six is unlikely to do it - and it is not obvious that throughput is the true limit.
• Flow efficiency is about 8 of 19 days of actual work, i.e. around 42%. Most of the lead time is queue.

Why hiring is the wrong first move

• The queue exists because a policy says only QA may sign off. Adding capacity to a step whose existence is the problem locks the handoff in for another two years and makes it harder to remove.
• An 11-day feedback delay means developers learn about their defects almost two weeks later, when context is gone. That generates rework, which adds to the queue - a reinforcing loop.
• The 18% flaky rate means roughly 750 unreliable tests. Testers are spending their capacity re-checking false failures.
• Three-week branches guarantee merge pain and make any defect hard to attribute.

Hiring may be a short-term relief valve, but only alongside WIP limits and shifting test ownership left; on its own it buys a few months and entrenches the constraint.

Order: (b) then (a) then (d), with (c) last or not at all

• (b) WIP limits. Cheapest and fastest, and it changes behaviour rather than capacity. Capping the queue stops new work entering a stalled stage, exposes the real constraint, and forces the conversation about who is allowed to test. Caveat: applied alone, it leaves developers idle and will be resented; run it together with flake triage so the limit does not simply convert a QA queue into a developer queue.
• (a) Parallelisation. 6.5 hours is longer than a working day, which is why there is a nightly cadence and a Thursday window. Getting the suite under an hour makes per-commit feedback possible and is a precondition for developers owning tests. It does not fix flakiness; parallelising a flaky suite just fails faster and more often, so quarantine or fix the 18% first.
• (d) Feature flags. Decouples deploy from release, shrinking batch size and removing the need for a four-hour Thursday window and a big-bang sign-off. This is what makes the QA gate structurally unnecessary rather than merely smaller.
• (c) Hiring. Adds throughput to a step you are trying to dissolve, and by the arithmetic above three people will not halve the wait. Defensible only as a bridging measure with an explicit sunset.

Sequencing matters because each step reduces the size of the next problem: WIP limits expose it, suite speed makes feedback usable, flags reduce the risk that justified the gate.

Measure

• Lead time for change from commit to production, reported as a distribution (median and 85th percentile), not an average. The tail is where the pain lives.
• Flow efficiency: proportion of lead time spent in active work versus waiting. Baseline is around 42%; the target is movement, not a number.
• Deployment frequency, and change failure rate as its balancing pair - never one without the other.
• Test suite duration, flake rate, and the count of tests quarantined or deleted.
• Escaped defects, i.e. defects found in production rather than in the pipeline.

Avoid

• Number of tests, as a proxy for quality. 4,200 tests with 18% flake is worse than 1,500 reliable ones.
• Tester utilisation. Driving utilisation to 100% is precisely what creates queues; a team at 80% with a short queue delivers faster than one at 100% with a long one.
• Individual defect counts or 'defects caught' per tester. It rewards volume over prevention and punishes the person who reports the systemic problem.
• Cycle time averages, which hide the items that sat for six weeks and are the ones worth investigating.