{"slug": "is-there-a-relationship-between-cycle-time-and-pr-throughput", "title": "Is there a relationship between cycle time and PR throughput?", "summary": "DX's Q2 AI Impact Report reveals that the relationship between PR cycle time and PR throughput is significant only for high-throughput organizations, while low-throughput teams show no meaningful correlation. Analyzing data from 500+ DX customers from January to July 2026, DX found that reducing cycle time may not automatically increase throughput for most organizations, as other factors like PR size and organizational context play a larger role.", "body_md": "# Is there a relationship between cycle time and PR throughput?\n\n### There’s a closer relationship between the two in high-throughput organizations. In low-throughput organizations, there are other variables at play.\n\n**Welcome to the latest issue of Engineering Enablement, **a weekly newsletter sharing research and perspectives on developer productivity.\n\nDX’s Q2 AI Impact Report is now available with the latest research on AI’s impact across engineering organizations. [Read the full report.](https://getdx.com/resources/?utm_source=newsletter)\n\nWhen teams reduce the time it takes to complete a pull request, it’s natural to assume they’ll be able to deliver more work, but this relationship is rarely quantified at scale. A customer recently brought this question to DX’s Research team, asking us to look into the relationship between PR cycle time and PR throughput.\n\nKey takeaway:High-throughput organizations are highly sensitive to long cycle times, potentially indicating that bottlenecks like review wait times are particularly acute for these orgs. For lower-throughput teams, there is no meaningful relationship between cycle time and throughput, suggesting bottlenecks exist elsewhere.\n\n### Queuing theory behind cycle time and throughput\n\n[Little’s Law](https://en.wikipedia.org/wiki/Little%27s_law), a theorem from queuing theory, helps explain the relationship between three things: how much work is in progress (WIP), how quickly work gets completed, and how long each piece of work takes. For software teams, we can think of these as:\n\nWIP: the number of pull requests currently open,\n\nPull Request (PR) Throughput: number of pull requests merged over a period of time, and\n\nPR cycle time: how long a pull request takes to move from development through review and merge.\n\nThe equation is straightforward. When the amount and type of work stay relatively consistent, work that moves through the process faster can help a team complete more work over time. This relationship is commonly used to explain how software teams improve flow but it hasn’t yet been quantified in the developer productivity space.\n\n[Research by Maddila et al.](https://dl.acm.org/doi/10.1145/3544791) shows that pull requests often spend significant amounts of time waiting, not being actively coded or reviewed, and implies that cycle time isn’t a fixed metric. Teams can recover some of that waiting time by improving the workflow around development and review, without changing the process of writing code.\n\nTo understand how PR cycle time relates to throughput, we looked at the relationship between median PR cycle time and average PR throughput per developer across organizations using data from 500+ DX customers from January-July 2026, inclusive.\n\n### Cycle time matters more for high-throughput organizations than it does low-throughput organizations\n\nOur analysis suggests that PR cycle time is not a reliable standalone predictor of throughput. In the raw data, organizations with similar review speeds show a wide range of throughput levels, indicating that other factors, like PR size and organizational context, likely play an important role in determining output.\n\nThe median trend is relatively flat across most of the distribution, with throughput beginning to decline more noticeably only at longer cycle times. This indicates that reducing cycle time may not automatically increase throughput for every organization, particularly when teams are already operating within a typical throughput range.\n\nBecause median results can obscure differences across the performance distribution, we also used quantile regression to look at this relationship at the 25th, 50th, 75th, and 90th percentiles of throughput. This approach allows us to look at whether the association between cycle time and throughput changes for lower-, median-, and higher-throughput organizations.\n\nThe results show that the relationship between cycle time and throughput is concentrated among higher-performing organizations.\n\nAt the 25th percentile, there is no statistically significant relationship between cycle time and throughput (p=0.366, β=-1.1).\n\nAt the median, there is a modest but statistically significant negative relationship (p=0.0008, β=-4.0).\n\nAt the 75th and 90th percentiles, the negative relationship becomes substantially stronger and remains statistically significant (p=0.000, β=-11.7; p=0.000, β=-12.8).\n\nIn practical terms, high-throughput teams are the most sensitive to cycle time slowdowns. For teams already in the bottom 25% of throughput, cycle time barely matters. For teams in the top 10%, it matters quite a bit.\n\n## Final thoughts: Speed is a safeguard but not a universal solution\n\nAcross most organizations, throughput stays fairly steady as PR cycle time increases. The relationship between the two becomes more noticeable around 17 hours. Beyond that point, median throughput starts to decline. This makes 17 hours a useful inflection point, not a universal target. For teams below that point, reducing cycle time may not lead to a meaningful increase in throughput. But once cycle times go beyond it, longer review cycles may start to limit teams that have the capacity to deliver more.\n\nThink of the 17-hour mark as a warning sign and not a productivity cutoff. Teams with longer cycle times may benefit from looking more closely at review queues, reviewer availability, PR size, and other sources of waiting. These results show an association, not proof that longer cycle times directly cause lower throughput. Cycle time is most useful when considered alongside quality, work complexity, team structure, and other developer-experience measures, not as a standalone productivity target.\n\nThis week’s featured DevProd job openings. See more [open roles here](https://getdx.com/resources/devex-jobs/).\n\n**Ashby** is hiring an[Staff Platform Engineer](https://jobs.ashbyhq.com/Ashby/0f5dbf59-687b-4d88-88a7-73ee0a66b48d?utm_source=PRgMeEgv1Z)| Remote**Carta** is hiring a[Sr. Software Engineer II, Developer Experience](https://www.linkedin.com/jobs/view/4404135082)| Santa Clara, CA; San Francisco, CA; New York, NY**Figma** is hiring a[Staff Software Engineer, Developer Experience](https://job-boards.greenhouse.io/figma/jobs/5790627004?gh_jid=5790627004&gh_src=db0ijm3x4us)| Remote; US**Mastercard** is hiring a[Vice President, Software Engineering](https://mastercard.wd1.myworkdayjobs.com/CorporateCareers/job/New-York-City-New-York/Vice-President--Software-Engineering_R-286632)| New York**Notion** is hiring a[Software Engineer, Developer Experience](https://jobs.ashbyhq.com/notion/49bdf081-6e20-4323-8c73-6d6b19544ff5)| Hybrid; Hyderabad, India", "url": "https://wpnews.pro/news/is-there-a-relationship-between-cycle-time-and-pr-throughput", "canonical_source": "https://newsletter.getdx.com/p/is-there-a-relationship-between-cycle", "published_at": "2026-08-19 10:01:00+00:00", "updated_at": "2026-08-19 10:12:46.822859+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["DX"], "alternates": {"html": "https://wpnews.pro/news/is-there-a-relationship-between-cycle-time-and-pr-throughput", "markdown": "https://wpnews.pro/news/is-there-a-relationship-between-cycle-time-and-pr-throughput.md", "text": "https://wpnews.pro/news/is-there-a-relationship-between-cycle-time-and-pr-throughput.txt", "jsonld": "https://wpnews.pro/news/is-there-a-relationship-between-cycle-time-and-pr-throughput.jsonld"}}