DEV Community: Brynjar Jónsson

What do 3-day reviews actually cost your team?

Brynjar Jónsson — Mon, 16 Feb 2026 21:09:59 +0000

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.

What does your typical review wait time cost?

Plug in your numbers. See what the math says for your team.
Try the calculator →

The 3-Day Code Review Problem (And What It's Actually Costing You)

Brynjar Jónsson — Thu, 08 Jan 2026 11:36:26 +0000

"People often take around a week to review my changes... having to wait half a sprint is pretty insane in my opinion."

A developer posted this on Reddit recently. Their team runs two-week sprints. Reviews take a week. They suggested "same or next day" turnaround and got "interesting looks from a couple people, like I was saying something crazy or being unreasonable."

When they asked their teammates how long reviews should take, most said "3-4 days." The thread that followed had over 50 responses.

What struck me wasn't the advice—it was how wildly different "normal" looks across teams.

The gap between what's possible and what's accepted

Some teams operate reviews like this:

"My team does same or next day and favors small, focused change sets as much as possible."

"As a TL, I aim to get a review done within an hour of receiving it. It's built into my job description and it affects team velocity."

"My Jira metrics say under 20 hours for all my client companies (from open to merged), this includes addressing comments, change requests, potential reworks."

Other teams have normalized something very different:

"My old team would have it done same day. Then I went to a team where it would take a week. Now I'm on a team where 2-3 days is normal."

"When I started on my current contract, reviews took 1-3 weeks."

Same industry. Same type of work. Completely different expectations.

The real cost of waiting

One reply laid it out clearly:

"Any wait is bad and costs money in all sorts of ways—context switching, merge conflicts, finding out about bugs a week later instead of 15 minutes after writing it."

The original poster described what this looks like in practice:

"I am faster than my other team mates, so my MRs in this team pile up like train cars... I actually just avoid picking up new tasks to avoid context overload because I need to wrap up what's pending."

Read that again. A developer is intentionally slowing down because the review process can't keep up. They're managing their own throughput to compensate for a broken system.

Another response connected it to broader research:

"It's a major problem, for many organizations, and it pays to solve it (refer: 'Accelerate' by Dr. Forsgren)."

The Accelerate - research shows elite teams achieve lead times—from commit to production—measured in hours, not weeks. If your reviews alone take 3-4 days, you've already blown past what high performers accomplish end-to-end.

What high-performing teams actually do

The thread surfaced several patterns from teams that have solved this:

They treat reviews as blockers, not backlog

"PRs should be treated as blockers and dealt with ASAP."

"In the best teams I've been a part of, the guideline was to start the day by reviewing any pending MR, before producing any additional code."

They have explicit time agreements

"We have a 24 hour turn around time expectation for most code reviews."

"I expect 24 hour turnaround per iteration from required reviewers... 24 hours is when pings start going out."

"Four hours, tops. Then I start DMing people for the review."

They keep changes small and reviewable

"I learned to pair down my commit sizes. Now my commits are less than 100 lines. They are so small that when I ask for reviews, people readily look at my PRs because they know the PR will be easy to review. I routinely get reviews done same day now."

"We review all changes within a day. Though we keep our tickets and changes small so they are easy to read through and understand."

They make reviews part of the job, not an interruption

"We do same day code reviews for all merge requests, with the goal to do them within an hour of being submitted. We all have to have our code merged, so it's really just like we need it done by other people as much as we need it done so it basically averages out."

Making it work without breaking flow

The common objection is that fast reviews mean constant interruptions. But the best advice flips this:

"When you start a work period, do reviews first, then go to coding. When you come in in the morning, get your cup of coffee, and then do reviews. Once reviews are done, start coding. When you come back from lunch, do any pending reviews, then get back to coding. No interruptions, no leaving the state of flow."

Another pattern:

"Code in small batches, and when you're done a batch of coding, reviewing other people's code is higher priority than the next batch of coding."
Reviews don't break flow if you design them as transitions, not interruptions.

Why nothing changes

The most honest observation in the thread:

"The situation is surreal, but it's also disturbingly normal and organizations tend to be very slow to move off their broken process no matter how large the evidence that it works badly."

Teams know long reviews hurt. Many have read Accelerate. They've felt the pain of context-switching back to week-old code. But the process persists because:

No visibility — You can't improve what you can't see. Without data, "reviews are slow" is just a feeling, easily dismissed.
No baseline — What's normal for your team? Is this sprint worse than last sprint? Without tracking, you can't know.
No accountability — A 24-hour agreement means nothing if no one can tell when it's been violated.

The original poster captured the dysfunction perfectly:

"Teams putting processes before people and then claiming to do agile."

Debug your process, not your team

Your reviews take exactly as long as the system you've designed allows.

Reviews aren't slow because developers are lazy. You designed the system work flows through. It's yours to redesign. But like any debugging, it starts with visibility.

When a deploy fails, you don't guess at the cause. You look at the logs. You trace the error. You find the line that broke.
Your review process deserves the same treatment:

How long do items actually sit in review?
Which transitions are slow?
Dev done → In Review?
In Review → Review done?
Review done → In Test?
Is the 24-hour agreement being met?

These questions are all easy to answer—if you collect the data.

The developer who started this thread isn't unreasonable for expecting same-day reviews. They're just on a team that doesn't see where the time goes.

I'm the lead developer of Time In Status by Smart Guess — it shows you how long Jira issues spend in each status—so you can see where work waits, spot review bottlenecks before they pile up, and finally have data for those "why did this take so long?" conversations.

Debug your process, Not your team

Brynjar Jónsson — Sun, 04 Jan 2026 19:27:50 +0000

This is a submission for the DEV's Worldwide Show and Tell Challenge Presented by Mux

What I Built

I built a Jira app that helps development teams debug their delivery process. It combines Time in Status tracking with Flow Intelligence and AI-powered guidance to help teams understand where work gets stuck, predict when it will ship, and fix systematic bottlenecks.

Think of it as a debugger for your workflow, not your code.

My Pitch Video

Mux video

Demo

Try it here:
https://marketplace.atlassian.com/apps/4028833452

The Story Behind It

Every developer has heard the question: "Why is this story taking soo long?"

The answer is usually buried somewhere in the process—work sitting in review, blocked dependencies, testing pile-ups.

Many teams see the same bottlenecks sprint after sprint, but without hard data, pushing for change is an uphill battle. So nothing changes.

I built Smart Guess because I wanted to bring the debugging mindset developers use for code to the way teams work. Instead of blaming people, you diagnose the system. The tagline says it all: Debug your process, not your team.

What makes it different from existing tools is the combination of:

Visibility — see exactly where time goes, right on the issue
Prediction — forecast when work will ship based on actual team history
Guidance — NoEsis, an AI assistant that helps interpret patterns and build the case for change

Technical Highlights

Backend:

Atlassian Forge - Serverless cloud platform with FaaS runtime
Node.js - Backend resolver logic
Forge Storage API - Persistent data layer
Jira REST API & Agile API - Sprint/board data integration
OpenAI Assistants API - AI coaching (NoEsis) with thread-based conversations

Frontend:

React - Component architecture with hooks
Atlaskit Design System - Atlassian's official UI framework
Vite - Modern build tooling and dev server
@forge/bridge - Forge <-> UI communication layer

Why You Keep Explaining the Same Delays Every Sprint

Brynjar Jónsson — Sun, 28 Dec 2025 19:12:57 +0000

Why is this taking so long?

You've heard this question in standups. In Slack. In retros. Every sprint, someone asks. Every sprint, the answer is vague—"it got stuck in review," "we hit some blockers," "it took longer than expected."

So you start tracking Time in Status. Now you have data—3 days in Review, 2 days in QA. But the question keeps coming back. Because knowing how long isn't the same as knowing why.

Most teams collect this data and do nothing with it. Or worse—they use it in ways that hurt morale without improving delivery. Here are the five most common mistakes, and what to do instead.

Mistake #1: Measuring Without Context

You see an issue spending 4 days in “In Progress.” Is that bad? You have no idea. Without knowing what’s normal for similar work, the number is meaningless.

What teams do wrong:

Set arbitrary thresholds (“anything over 2 days is a problem”)
Compare all issues equally (a bug fix vs. a story vs. a sub-task)
React to outliers without understanding why

What to do instead:

Compare cycle time to similar completed work. A 4-day story might be perfectly healthy if your team’s stories typically take 3-5 days. But if similar stories usually take 1 day, that’s a red flag.

The Summary card compares each issue to your team's actual history for the same issue type. Color-coded health tells you at a glance whether something needs attention.

Mistake #2: Treating Symptoms, Not Root Causes

You notice issues pile up in “Code Review” every sprint. So you discuss the issue and agree to try “reviewing faster.” Next sprint, same problem.

What teams do wrong:

Focus on individual issues instead of patterns
Push people to work faster instead of fixing the process
Have the same retrospective conversation every two weeks

What to do instead:

Look for patterns across sprints. Is the bottleneck consistent? Does it happen with certain issue types? Are certain team members being overloaded?

The problem usually isn’t people—it’s the process. Maybe reviews pile up because:

No dedicated review time is scheduled
One person is the bottleneck for all reviews of certain type
Stories are too large to review quickly

Flow Intelligence surfaces patterns across your team—trends, predictability, cumulative flow. Stop asking “why is THIS issue late?” and start asking “why does this KEEP happening?”

Mistake #3: Reporting on the Past Instead of Predicting the Future

Time in Status tells you what already happened. By the time you see a problem, it’s too late. The sprint is over. The stories didn't complete.

What teams do wrong:

Only look at metrics in retrospectives (after the damage is done)
Can’t answer “when will this ship?” with confidence
Constantly surprised by delays

What to do instead:

Use historical data to predict future delivery. If your team’s stories typically take 3-5 days, and this one started 2 days ago, you can forecast when it’s likely to finish.

The Forecast card shows three scenarios based on your team’s actual completion patterns:

Likely — Half of similar work finished in this time or less
Plan for — 85% of similar work finished in this time or less
Worst case — 95% of similar work finished in this time or less

When someone asks, “When will this be done?”—you have an answer based on data, not gut feel.

Mistake #4: Reports That Don't Lead to Action

A report that sits in a dashboard doesn't improve anything. The value isn't in the chart—it's in knowing what to do next.
Your Cycle Time went up 20% this sprint. Your throughput dropped. The cumulative flow diagram shows a pattern forming. What's causing it? What should you try first?

What teams do wrong:

Collect metrics but never act on them
Spend retrospectives debating what the data means
Make changes based on guesses, then don't know if they helped

What to do instead:
Get guidance alongside the data—so you can move from insight to action faster.

Noesis helps you interpret what you're seeing and suggests what to try next. Ask it anything:

"What does this cumulative flow diagram tell me?"
"Why is our cycle time increasing?"
"Work keeps piling up in QA—what should we try?"

You learn to read the patterns while solving real problems. The next time you see a similar issue, you'll spot it yourself.

Mistake #5: Using Time in Status to Measure People Instead of Process

Time in Status becomes a surveillance tool. "Why did YOUR tickets take so long?" Developers get defensive. Trust erodes. People start gaming the metrics.

What teams do wrong:

Use time data in performance reviews
Call out individuals in standups
Create pressure without providing support

What to do instead:

Debug your process rather than eroding trust. The best coaches don't track who's slow—they remove what's in the way and make everyone faster.

When work takes too long, it's usually systemic: too much work in progress, dependencies, or overload in review and test.

The question isn't "who's slow?" It's "what's blocking flow?" Maybe one person is the bottleneck for reviewing a certain part of the codebase. Maybe no one can step in when testing backs up. These are process problems with process solutions.

Don't Repeat Yourself

Measuring Time in Status is useful. But it's just a starting point.
The real goal isn't tracking how long things take. It's:

Spotting patterns before they derail yet another sprint
Understanding why delays happen so you can fix them once
Having better conversations about process, not blame

Fix the root cause. Stop explaining the same delays. Move on.

I'm the lead developer of Time In Status by Smart Guess
— it shows you how long Jira issues spend in each status—so you can see where work waits, spot review bottlenecks before they pile up, and finally have data for those "why did this take so long?" conversations.