What do 3-day reviews actually cost your team?

#management #productivity #softwaredevelopment #softwareengineering

Most teams don't think much about review time. PRs go up, reviews happen "when people have time," work continues. It feels efficient - nobody's sitting idle.
But there's a hidden cost that compounds quietly in the background.

The "staying busy" trap

When reviews take 3 days, developers do what any reasonable person would: they start the next thing. The problem isn't idleness - it's what happens next.
With 3-day review waits in a 2-week sprint:

Each dev juggles 2.5 items at once on average
Every review return means context switching - "where was I?"
Merge conflict risk increases 38% as parallel work diverges

The devs aren't idle. They're busier than they need to be.

What the math actually says

Let's make it concrete. A team of 5, 2-week sprints, assuming average 2 days of dev work:

With 3-day reviews: 260 stories/year
With same-day reviews: 520 stories/year

Same people. Same skills. Double the output.

"But that's theoretical," you might say. "Real teams have overlap, parallel work, varying review complexity."

Here's the thing: if you reduce cycle time from 5 days to 2.5 days, throughput doubles. That's not a theory - that's Little's Law - that's math.

The overlap and parallel work you're describing? They're already baked into cycle time. However your team works, doubling the time from start to done means half as much gets done.

Need management buy-in? Here's what it costs.

Fixing slow reviews isn't free - it takes process changes, maybe tooling, definitely prioritization. If you need to make the case for investing in this, here are the numbers:

The throughput gap: To match a faster team's output, you'd need to hire an entire second team. That's a $500k+ decision vs a process change.

The hidden costs: At $75/hour loaded developer cost, 3-day reviews create:

37.9 days/year lost to context switching
24.3 days/year lost to merge conflict rework
$37,275/year per team in hidden costs

That's 497 hours of developer time - not building features, just waiting and recovering from waiting.

The question worth asking

Team dynamics vary. Workloads differ. What works for one team won't work for another. But here's a question worth asking: Do you actually know how long your reviews take?

Not a guess. Not "a day or two, usually." The actual median time from PR opened to review complete. Most teams have never measured it. Which means they've never questioned whether it could be better.

Once you can see where your issues actually spend their time - stage by stage - you can decide what's worth fixing. And once you fix the wait states, the throughput gains from Little's Law stop being theoretical.