Code metrics

About

Code metrics help you understand how work moves through your development process, from the first commit to merge and beyond. They highlight how long work takes, where it gets stuck, and how quickly feedback is given. Use these insights to improve flow, reduce delays, and ship smaller changes more frequently.

Why does it matter?

Code metrics help teams:

• Identify bottlenecks in development, review, or merge stages

• Improve feedback loops and collaboration

• Reduce risk by shipping smaller changes more often

• Separate development speed from deployment delays

If you’re looking to improve delivery performance, start with pull request cycle time and review metrics, then expand into deployment metrics like change lead time.

Understanding the Code Metrics Page

The Code Metrics page in Swarmia provides a comprehensive view of your team's development process, helping you identify bottlenecks and foster a culture of continuous improvement. This page is designed to provide insights into key aspects of your coding lifecycle, from batch size to review processes. Use these metrics to understand your process and drive meaningful improvements. Focus on trends over time rather than isolated data points to get a true sense of your team's health and progress.

1. Overview

The Overview tab provides a high-level summary of your team's key pull request metrics. It also includes a team comparison table where you can see how your team's performance on metrics like Cycle Time and Batch size compares to other teams in the organization.

• Use Case: Use this view to get a quick pulse check on your team's health and to identify areas that might need a deeper look. The team comparison table is especially useful for spotting outliers and understanding your team's performance in the broader organizational context.

• Pro Tip: When using the comparison table, sort by different metrics to find teams that are excelling and could share best practices. Using percentiles like p90 instead of averages may give you a more realistic view, as averages can be skewed by a few unusually long-running pull requests.

2. Trends

The Trends tab is your primary tool for visualizing how your team's metrics evolve over time. You can track metrics like Cycle Time, Throughput, and Batch Size to see if your process is improving.

• Use Case: Use this view to spot spikes or dips in performance. For example, a sudden increase in Cycle Time might indicate a new bottleneck in the review process or an issue with the CI/CD pipeline.

• Pro Tip: Don't just look at the last week. Expand the timeframe to a quarter or even a year to identify long-term patterns or measure the impact of process changes you've implemented.

3. Cycle Time

This tab offers a visualization to the Cycle Time of your pull requests—the time from first commit to merge.

• Use Case: This view helps you to understand how the cycle times are divided among PRs, and see if there’s some outliers that may skew the average.

• Pro Tip: Use the detailed list of pull requests in this view to investigate anomalies. Click into a PR with an exceptionally long cycle time to understand the context, read the comments, and see what caused the delay.

4. Review

The Review tab focuses on the health and efficiency of your code review process. It visualizes metrics like Time to First Review and the number of comments per pull request.

• Use Case: This tab helps you answer questions like, "Are pull requests waiting a long time for a first review?" or "Are our reviews becoming more or less thorough over time?"

• Pro Tip: Look for patterns of long review times on certain days or for certain types of pull requests. This can help you organize your team's workflow better, for example, by setting aside dedicated time for reviews.

5. Batch Size

This tab analyzes the size of your pull requests, measured in lines of code changed. Smaller batches are generally preferred as they are easier to review, test, and merge, leading to a faster flow of value.

• Use Case: A wide distribution in batch size might indicate that there isn't a shared understanding of what a "small" pull request looks like. Use this view to have a conversation with your team and establish working agreements on PR size.

• Pro Tip: Filter this view to see if larger pull requests correlate with longer cycle times. This data can provide a compelling case for encouraging smaller, more frequent commits.

6. Codebase

The Codebase tab shows you which parts of your codebase are changing and how frequently. It aggregates file changes from pull requests into a tree structure, showing metrics like the number of PRs, lines changed, and contributors for each part of your code.

• Use Case: Use this view to identify "hotspots" in your code—areas that are frequently modified and might be candidates for refactoring. You can also see which teams are contributing to which parts of the codebase.

• Pro Tip: Combine this view with filters to answer specific questions, such as, "Which files have been most frequently edited by AI coding assistants this quarter?" or "Who has contributed to this legacy module recently?".

How to use code metrics?

Code metrics in Swarmia focus on pull request–based measurements.

Pull request cycle time

Pull request cycle time measures how long a pull request takes from the first commit to merge.

In Swarmia, pull request cycle time is the sum of these three components:

• Time in progress — from the first commit or from when the pull request is opened, whichever happens first, to the first review request.

• Time in review — from the first review request (or from when the pull request was opened, if none) to the final approval.

• Time to merge — from the final approval to once the pull request is merged.

You can:

• View aggregate cycle time across pull requests

• Drill down into individual pull requests to understand delays

• Use Pull request insights and overview to identify slow or aging PRs

Review metrics

Swarmia includes metrics to understand how quickly pull requests are reviewed.

Time to first review

• Measures how long it takes to receive the first review after a review is requested

• Indicates how quickly new work gets picked up

Review time

• Measures how long each individual review takes

You can:

• View time to first review in Code overview, Trends, and Review

• Explore review timelines in the Review view

• Analyze review performance across pull requests

Change lead time

Change lead time extends cycle time to include deployment.

• Pull request cycle time: First commit → merge

• Change lead time: First commit → deployment

Use both metrics together:

• Cycle time shows development and review efficiency

• Change lead time shows end-to-end delivery speed

How are draft PRs considered in cycle time?

We consider all PRs the same, regardless of the draft state. Since PR cycle time starts from the first commit (or PR open, whichever happens first), the total cycle time is the same, regardless of whether you open a PR as a draft early or ready to review later.

In other words, we consider the draft status by default to be part of the in-progress time. Our definition is based on the assumption that draft pull requests are used as an early indication of work in progress or to gather feedback before review. We try to catch as much of the in-progress time for pull requests as possible.

If you want to exclude draft PRs from Swarmia until they are ready to review, you can set a "Draft status is Draft" exclusion rule. This can be useful, for example, if you create proof-of-concept draft PRs with no intention to merge or close them. Another option would be to create a dedicated PR label for this and use it in the exclusion rule.

What does good look like?

Pull request cycle time benchmarks

• Great: < 24 hours

• Good: < 5 working days

• Needs attention: ≥ 5 working days

How can we take action?

To improve code metrics, focus on flow and feedback loops.

Reduce cycle time

• Limit work in progress (avoid too many open pull requests)

• Split work into smaller pull requests

• Prioritize reviews and merges

• Define clear ownership for moving pull requests forward

Improve review responsiveness

• Ensure new pull requests are picked up quickly

• Reduce delays in starting reviews

• Identify and address slow or outlier reviews

Use Swarmia to support improvements

• Clean up old or stale pull requests

• Exclude outliers to focus on current work

• Set working agreements (e.g. max PR age, WIP limits)

• Use daily digests to stay aware of aging pull requests

• Review pull request insights regularly as a team

Where does the data come from?

Code metrics are based on pull request and review events, including:

• Commits

• Pull request creation

• Review requests and submissions

• Approvals and merges

Change lead time additionally requires deployment data.

Only pull requests linked to applications with deployments configured are included in change lead time.

Metric definitions

Pull request cycle time = Time in progress + Time in review + Time to merge

Time to first review = Review request → first review submission

Review time = Review request → individual review completion

Change lead time = First commit → deployment

Something looks wrong

Common reasons:

• Very old pull requests skewing averages

• Draft PRs included when they shouldn’t be

• Proof-of-concept or abandoned PRs included

• PRs merged without formal approval → review time measured until merge

• Bot reviews not included in aggregates

Possible fixes:

• Exclude outliers

• Add exclusion rules for draft PRs or labels

• Clean up old pull requests