If you want a useful view of PR cycle time engineering team performance, start by measuring the parts of the GitHub pull request flow that teams can actually influence. The goal is not a single average. It is a consistent breakdown of where time is spent, how it changes across teams, and what moved between two windows.
This is engineering intelligence for GitHub PR delivery, not a scorecard. For engineering managers, that usually means tracking cycle time alongside review wait, time to first response, merge pace, and team scope. With that baseline, you can compare one team to another, or the same team this week versus last week, without guessing why the number changed.
What PR cycle time should mean for a team
PR cycle time is the elapsed time from PR open to PR merge. For team-level management, that is the headline metric, but it only becomes actionable when you pair it with the parts of the flow that explain it.
- Open to first review: how long a PR waits before someone responds.
- Open to approved: how long it takes to get to merge readiness.
- Open to merge: the full team cycle time.
- Review time by team: whether a team is spending time in review or waiting for review.
If you track only the full cycle time, you can see that things are slower or faster, but not where the delay sits. For a practical definition and related metric choices, see /docs/metrics and /docs/choosing-delivery-metrics.
The minimum metrics to track by team in GitHub
To understand PR cycle time by team, keep the metric set small and consistent. Managers usually get strong signal from a handful of measures rather than a large dashboard of disconnected numbers.
- PR cycle time per team, using the same start and end definition everywhere.
- Median rather than average, so a few long-lived PRs do not distort the picture.
- Time to first review or first response, because waiting often drives cycle time.
- PR volume, so you do not compare a busy team with a team that only had a few PRs.
- Merge count and open PR count, which help explain whether work is flowing or backing up.
When you need to scope these numbers to specific parts of the org, map teams and repos first. That keeps the comparison fair. The setup pattern is covered in /docs/teams-and-repos.
How to compare two windows without overreading the chart
Most useful team comparisons happen across two windows: this week versus last week, or the last 30 days versus the prior 30 days. The point is to see the change, then ask what shifted in the workflow.
When cycle time changes between windows, check these questions first:
- Did the team receive more large PRs than usual?
- Did first review take longer in one window?
- Were there fewer reviewers active on the repo?
- Did one or two long-lived PRs pull the median upward?
- Did the team scope change because repos were added or removed?
This is where trend charts and milestone markers help. You can mark moments such as process changes, staffing shifts, or release pressure, then compare the windows with context instead of memory. See /docs/chart-milestones and /docs/snapshots.
What to look for in the team dashboard
A team dashboard should answer three questions fast: which team changed, how much it changed, and whether the change looks isolated or broad.
The most useful view usually includes:
- a team KPI summary for quick scanning,
- a trend chart for PR cycle time over time,
- a performance table so you can compare teams side by side,
- drill-downs for the underlying PR data, and
- milestones to annotate the period you are reviewing.
That combination helps you move from “the number moved” to “which team, which week, and which part of the flow.” For a deeper look at the chart structure, see /docs/team-analytics and /docs/dashboard.
Signals that help explain why cycle time changed
Cycle time changes are often driven by smaller flow signals rather than one big event. In GitHub, look at PR metadata that can point to review friction or coordination load.
- Time to first comment: delayed response usually extends the total cycle.
- Number of review rounds: more back-and-forth often adds time.
- PR size: larger changes tend to take longer to review and merge.
- Waiting states: long gaps between update events often reveal bottlenecks.
- Assignee and reviewer patterns: uneven load can slow a team down.
These signals are most useful when you are coaching a team or preparing for a staff meeting. They do not replace the core metric; they explain the move. For a related guide, see /docs/guides/code-review-responsiveness.
Reading team performance without turning it into a ranking
Team cycle time is best used as a coaching tool, not a scorecard. A fast team is not always a healthy team, and a slower team is not always blocked. The context matters.
Use the metric to ask:
- Is this team waiting on review more than other teams?
- Are long PRs creating avoidable delay?
- Did the team’s repo scope grow and change the baseline?
- Are there repeated bottlenecks in the same stage of the flow?
For managers who want a practical way to talk about these results with staff, /docs/guides/staff-meeting-metrics is a useful companion. If you need a broader manager-oriented framing, see /docs/guides/github-metrics-for-managers.
FAQ
Should I use average or median PR cycle time?
Use median as your default for team comparisons. It is less sensitive to a few long-lived PRs that can distort an average. If you also track average, use it as a secondary view.
How many PRs does a team need before the metric is meaningful?
More is better, but there is no universal cutoff. Small samples can swing quickly, so compare windows carefully and avoid strong conclusions from a tiny number of PRs.
What if one repo dominates a team’s cycle time?
Split the scope by team and repo so the dashboard reflects the work the team actually owns. That usually makes the trend easier to interpret and the comparison more fair.
Why does PR cycle time rise when review time looks normal?
The delay may be happening before review starts, after approval, or in a few large PRs that take longer to finish. Break the metric into stages to see where the extra time sits.
How do I know whether a change was real or just a short-term spike?
Compare at least two windows and check whether the change repeats over time. A one-week spike can be noise; a repeated shift across several windows usually deserves attention.
If you want to compare PR cycle time by team with scoped GitHub data and clear trend windows, start a pilot at /app/onboarding. If you are evaluating fit or data coverage first, review the setup and limits pages at /docs/setup and /docs/limitations#pilot.