Skip to main content
Size vs time plots the relationship between pull request size (lines changed) and cycle time (time from open to merge). It helps you see whether larger PRs are taking disproportionately longer to land, which is one of the most common sources of delivery slowdowns.

​
What Periscope tracks

The dashboard shows a scatter plot of merged PRs in the selected time range, with:
  • X-axis — PR size (additions + deletions)
  • Y-axis — Cycle time (hours from open to merge)
  • Each point — an individual merged PR

​
Interpreting the data

​
The expected pattern

In most teams, larger PRs take longer to merge. A visible upward trend from left to right is normal. The question is how steep the curve is:
  • Gentle slope — larger PRs take somewhat longer, but the team handles them well. Review capacity is healthy.
  • Steep slope — large PRs take dramatically longer. This is a sign that big changes create review bottlenecks.
  • Flat — PR size does not significantly affect cycle time. This is unusual and may mean the team is rubber-stamping large PRs or has very fast automated review processes.

​
Outliers

Look for PRs in the upper-right quadrant (large and slow). These are the most impactful to investigate:
  • Were they blocked on review?
  • Did they require multiple rounds of feedback?
  • Could they have been broken into smaller PRs?
Also look for small PRs with unexpectedly long cycle times (upper-left quadrant). These may indicate process issues unrelated to size — slow CI, reviewer availability, or merge queue delays.

​
Setting team guidelines

The size vs time chart helps you set data-informed guidelines for maximum PR size. If you see a clear inflection point where cycle time jumps (e.g., PRs over 400 lines take 3x longer), that is a natural boundary to recommend as a team guideline.

​
MCP tool

Query PR cycle time data (which includes size information) from your AI coding assistant: 
get_pr_cycle_time(time_range: "30d")
Returns cycle time percentiles and sample PRs with their sizes.