Skip to main content

Avg Member Review Time

From the reviewer side: average time a member takes to act on PRs they're reviewing — first comment, commit, or approval.

Avg Member Review Time, as it appears in the Team Overview tab, measures the reviewer side of code review: how quickly this person reacts to other people's open PRs once those PRs exist. It's the per-member lever on review pickup latency.


​

What it measures


​

For PRs in the period where this member is not the author, Leanmote finds the earliest action this member took on the PR — a comment, a commit on the PR's branch, or an approval — and computes the gap from PR creation to that earliest action. The metric is the average of that gap across all such PRs.


​

How Leanmote calculates it


​

earliest_action(member, pr) = min( first_comment_by(member, pr), first_commit_by(member, pr), first_approval_by(member, pr))
avg_member_review_time(member) = sum((earliest_action - pr.created_at) / 3600) / count(prs where member acted) with member != author, in period


​

  • Aggregation — straight mean of per-PR durations.

  • Unit — hours.

  • Working vs calendar hours — calendar hours. Working-hours mode does not apply.

  • Self-review — excluded. PRs the member authored don't contribute.

  • Bots and drafts — bot accounts are not auto-excluded. Use team mapping if needed.


​

Other "review time" view in the app


​

A different per-person review-time number lives inside the Bottleneck Insights modal. That view measures the author perspective — how long the author waits for someone to respond to their PRs — and is computed differently. The two numbers can disagree for the same person and that's expected; pick whichever side of the question you're asking and stick to one place.


​

How to interpret it


​

  • Lower is better — fewer hours from PR open to this member's first action.

  • Compare against the team median. A member persistently 2× the team median is worth a workload conversation before any other conclusion.

  • Read alongside Reviewer load (Reviewer metrics → Sharing Index) to separate "slow on a heavy queue" from "slow on a normal queue".


​

What to do about it


​

  • If pickup is consistently slow for one member, redistribute the review queue or coach toward dedicated review windows.

  • Set explicit team SLAs for review pickup so expectations are shared.

  • Auto-assign reviewers from a rota — passive review queues are the most common cause of high Avg Member Review Time.


​

Related metrics


​

  • Reviewer metrics

  • Avg Member Time to Merge

  • Avg Member TT First Approval

Did this answer your question?