Understand Engineering Throughput

Use Case. Share it with the roles that have interest in that.

Track trends in overall delivery output across all teams/projects. Identify how engineering capacity aligns with business goals.

It can be done from two perspectives: Quality and Quantity.


1️⃣ Quality

Relevant metrics

➡️ 1. PR failure rate


➡️ 2. Sonar Source code quality metrics

  • Include great SonarCloud/SonarQube metrics in your Custom Dashboards.
  • If you need other metrics from Sonar Source as well, please let our team know.

➡️ 3. PR review time

  • PR review time reflects how quickly pull requests are reviewed. Shorter times often indicate clear, well-documented code, while consistently long times across the team may suggest broader process or communication issues. Always interpret this metric alongside others or team benchmarks.
  • Where to find it:

Data Interpretation

Engineering metrics need context—their meaning depends on team culture and dynamics. Use benchmarks to tell whether trends reflect individual growth or broader issues.

For example:

  • Junior engineers may naturally exhibit higher churn or PR failure rates, as they are still developing familiarity with the codebase and workflows.
  • Senior engineers, on the other hand, may show longer time to merge from PR open to completion, often due to the increased complexity or impact of the features they work on.

Optional

You can also create an "Engineering Throughput" Custom Dashboard having the following useful metrics:

  • Traceability
  • Churn
  • Average time to merge from open (open to review + review to merge times)
  • PR Failure rate
  • Trendline graphics to have a better understanding of the metrics' evolution


2️⃣ Quantity

Measuring output quantity is inherently subjective and should align with the goals of the team or organization. There are many ways to approach this, and the choice of metric depends on what you aim to evaluate.

Tools like Team Insights and Contributor Insights can be valuable for tracking these metrics. They provide clear, quantifiable data about individual contributions, helping surface activity without requiring extensive interpretation.


Relevant metrics

  • Impact (e.g., on business or product outcomes)
  • Story points completed (if the team uses effort estimation)

Optional

Other commonly used metrics include:

  • Number of pull requests
  • Number of commits
  • Lines of code
  • Cycle time
  • Total number of tickets resolved