If you want to understand PR cycle time by team, start with a simple rule: measure the full path from pull request opened to merged, then break it into the stages that explain where time is spent. For engineering managers, that gives you a clearer view than a single average number.
In practice, the most useful question is not “What is the team’s cycle time?” but “Where did this team spend more or less time in the last window compared with the previous one?” That comparison helps you see whether review, waiting, or handoffs are changing.
engineering intelligence for GitHub PR delivery
What PR cycle time should include
PR cycle time is easiest to use when you define it consistently across teams. For GitHub-based team measurement, start with the PR’s lifecycle and focus on the parts that are visible in GitHub PR metadata.
- Opened to merged: the core cycle time measure.
- Open time before first review: useful for spotting review latency.
- Time in review: shows how long the PR waits between review activity and merge.
- Time from approval to merge: helps reveal queueing after review is complete.
- Rework after review: useful when changes requested slow the path to merge.
If you want a broader framing for delivery metrics, see /docs/metrics and /docs/choosing-delivery-metrics.
How to compare teams without misleading averages
Team averages can hide a lot. A few large PRs, one release freeze, or a batch of long-lived drafts can distort the picture. For that reason, compare teams over the same window and look at both the central tendency and the shape of the distribution.
- Median cycle time for the typical PR.
- Percentiles to show the slower tail.
- PR count so small samples do not get overinterpreted.
- Trend direction across the last two windows.
When you compare two windows, note what changed: did the median move, did the long tail shrink, or did the team just ship fewer PRs? Those differences matter more than a single headline value.
Break cycle time into stages that managers can act on
To make PR cycle time useful for coaching, split it into stages that match how work moves through GitHub. That makes it easier to tell whether the bottleneck is before review, during review, or after approval.
1. Waiting for review
This stage shows how long a PR sits before someone looks at it. If this grows, the team may have review coverage gaps, uneven ownership, or too many parallel requests.
2. Review and iteration
This is the period where comments, fixes, and rechecks happen. Longer time here can point to unclear requirements, larger diffs, or too much context switching.
3. Approval to merge
If approved PRs still sit open, the issue is often merge coordination, release timing, or an avoidable queue after the work is done.
For more on team-scoped views, see /docs/teams-and-repos and /docs/team-analytics.
What to watch in the two-window comparison
When you review team cycle time in one window against the prior one, focus on change, not perfection. The most useful readout is a short list of observed shifts.
- Faster median, same tail: the team is improving typical flow, but a few PRs still take too long.
- Stable median, slower tail: the team may have one or two complex work items that need attention.
- More PRs, longer cycle time: volume may be outpacing review capacity.
- Fewer PRs, shorter cycle time: smaller batches or lower complexity may be helping.
This kind of change report is more useful than a static chart, especially in staff meetings where the goal is to decide what to do next.
How to make the metric useful in GitHub
In GitHub, the cycle time view is one that stays close to the source data and reflects the actual team boundary. That means mapping the right repos to the right team and then reviewing the same metric consistently each week.
- Use the team and repo scope that matches how the team works.
- Keep the definition stable across reporting windows.
- Check the trend chart before drilling into individual PRs.
- Use milestone markers and snapshots to anchor discussion around known events.
You can see the setup details in /docs/setup, the product workflow in /docs/how-it-works, and the limitations to keep in mind in /docs/limitations#pilot.
Common mistakes when measuring PR cycle time by team
Most problems with cycle time reporting come from inconsistent scope or incomplete interpretation. A few avoidable mistakes show up often.
- Mixing teams and repos without a clear mapping.
- Comparing small samples as if they were stable trends.
- Using a single number and ignoring the long tail.
- Overreading short spikes caused by a single large PR.
- Changing the definition from one meeting to the next.
For a deeper practical guide, review /docs/guides/pr-lead-time-teams and /docs/guides/pr-flow-engineering-teams.
FAQ
What is the right single metric for PR cycle time by team?
The starting point is median time from PR opened to merged. It describes the typical experience without being overly distorted by a few slow PRs.
Should I track review time separately from total cycle time?
Yes. Total cycle time tells you how long delivery takes overall, while review time helps you identify whether delay is happening before or during review.
How many PRs do I need before comparing teams?
Use enough volume to make the window meaningful. A small team with only a handful of PRs can swing sharply from one period to the next, so pair the metric with sample size.
What if one team works on much larger PRs?
Then compare the trend within that team first, and use the breakdown into stages to understand whether the slowdown comes from larger diffs, more review time, or merge queueing.
How often should managers review PR cycle time?
Weekly review works well for operational coaching, especially when you compare the current window with the previous one and use the same definition each time.
If you want a scoped view for your teams, you can get started at /app/onboarding.