Allocating a Thin Review Team Across Two Release Trains
You lead a 6-person review team supporting two release trains. Train A ships in 9 working days and has 41 open change requests, 12 of them touching a shared authentication module. Train B ships in 24 working days and has 58 open change requests, 30 of which are documentation-only. Your team's measured throughput is 11 change requests per person-week, but only 7 per person-week for changes touching the shared module because each requires a second reviewer. One reviewer is on planned leave for the next 5 working days. The product owner for Train B has asked for 3 reviewers for the full period, arguing their volume is higher. No overtime is permitted, and skipped second reviews on the shared module have caused two production incidents in the past quarter.
1. Compute the realistic review capacity for each train over the next 9 working days and state what the product owner's request would cost.
Read the worked answer
Available reviewer-days in the next 9 days: 6 reviewers x 9 days = 54, minus 5 leave days = 49 reviewer-days, or 9.8 reviewer-weeks.
Throughput split matters: shared-module changes run at 7 per person-week, everything else at 11.
- Train A shared-module work: 12 changes / 7 per week = ~1.7 reviewer-weeks (~8.6 reviewer-days).
- Train A remaining 29 changes / 11 per week = ~2.6 reviewer-weeks (~13.2 reviewer-days).
- Train A total: ~21.8 reviewer-days.
- That leaves ~27 reviewer-days for Train B in the same window, which covers 27/5 = 5.4 reviewer-weeks x 11 = ~59 changes - roughly Train B's full 58, but only if nothing else intervenes.
The product owner's request for 3 reviewers for 9 days = 27 reviewer-days, which is exactly the entire remainder. Granting it consumes all slack and leaves zero buffer for the 12 shared-module changes that must be double-reviewed. The correct answer is not 'yes' or 'no' but a staged allocation: front-load Train A's shared-module work, and give Train B 1-2 reviewers now, scaling to 3 after Train A ships.
2. The Train B owner proposes waiving second reviews on shared-module changes to speed things up. Evaluate this against the evidence in the situation.
Read the worked answer
This is a classic pressure trade-off, and the setup gives you the data to refuse it.
- Incident history. Two production incidents in one quarter trace to skipped second reviews on the shared module. That is an observed failure rate, not a hypothetical. Waiving reviews re-opens a known failure mode.
- Blast radius. The shared authentication module is used by both trains. A defect there does not stay inside Train B's schedule; it can block Train A's 9-day ship date, which is the tighter constraint.
- The math doesn't support the shortcut anyway. Shared-module work is only 12 of Train A's 41 changes. Waiving second review saves ~4 reviewer-days at most (12 changes at the 11/week rate vs 7/week = ~4.3 days saved). That is not enough to rescue a 27-reviewer-day request. The proposal trades real risk for a marginal gain.
- Better levers. Documentation-only changes (30 of Train B's 58) can go through a lighter single-reviewer path with a checklist, freeing senior reviewers for the shared module. That captures the speed benefit without touching the high-risk path.
Recommendation: reject the waiver, document the decision and the reasoning, and offer the doc-only fast path as the counter-proposal.