Pickup Time Metric

Definition

Pickup Time measures the amount of time between when a pull request (PR) is created and when review begins.

A PR is considered “picked up” when the first review activity is recorded on the PR (for example, a review comment or an approval).

Why This Metric Is Useful

Pickup Time reflects how quickly code review starts after work is submitted. High Pickup Time often indicates:

• Review bottlenecks or unclear ownership
• Delays in assigning reviewers
• Capacity constraints (review load exceeds availability)

Reducing Pickup Time helps maintain delivery momentum by preventing PRs from waiting in a queue.

How to Use It

Use Pickup Time to:

• Detect review-start delays by team, repository, or contributor.
• Identify periods where review capacity is insufficient.
• Validate process improvements (review rotation, ownership rules, review SLAs).

Examples for Context

• Pickup Time spikes after a team reorg → reviewer ownership may be unclear.
• Pickup Time is high for a specific repo → that repo may have too few eligible reviewers.
• Pickup Time drops after introducing review rotation → process change is working.

Data Sources

Pickup Time is computed from PR timeline events, including:

• PR creation timestamp
• First recorded review activity timestamp (for example, the first review comment or approval)

Calculation

Per PR:

Pickup Time = Timestamp(first review activity) − Timestamp(PR created)

Normalization

Pickup Time is shown as a time duration (for example, minutes/hours/days).

If your dashboard supports percentile/aggregation selection (for example AVG / P50 / P75 / P90), the headline value reflects the selected statistic across the selected time range and filters.

How the Metric Is Displayed in the Dashboard

The metric card displays:

1. Headline value (based on the selected statistic, such as AVG or P75)
2. Time-series chart showing Pickup Time per time bucket (based on the selected granularity)

Hovering a point in the chart shows the Pickup Time for that bucket and enables drill-in (“Inspect metric”) when available.

Tunable Configurations

Pickup Time depends on how “review start” is defined and captured by your Git provider (for example, whether the first review event is a comment vs. an approval). If your organization supports configuration of review-start semantics, align it with your internal review policy to keep interpretation consistent.

Benchmarking Guidance

As a general guideline, Pickup Time should ideally be under 1 business day.

Error Margins and Limitations

• “Review start” may be represented differently across Git providers and workflows, which can affect comparability.
• PRs with atypical review flows (for example, approvals without comments, or tool-driven events) may shift the apparent pickup point depending on what is recorded as review activity.
• If review-start semantics differ across teams, cross-team comparisons may be misleading unless the workflow is standardized.

Stakeholder Use Cases

• Managers: Ensure PRs are assigned and picked up quickly; detect review capacity issues early.
• Developers: Understand how quickly submitted work gets attention and where review delays occur.
• Team Leads: Identify systematic pickup delays by repo/team and improve review ownership and routing.

Related Articles

• Reducing Pull Request Pickup Time
• Coding Time Metric
• Cycle Time Metric