Software Engineering Team Metrics

When PRs are merged without a review, it gets counted under this metric. Unreviewed PRs can be detrimental. Read all about this metric here.

This metric gives the average size of the PR (or LoC changes).

This metric presents data about the efforts, issues, and/or story points that were promised and how many efforts, issues, and/or story points were completed during the sprint.

This metric counts the total lines of code contributed.

This represents the distribution of effort (based on issues or story points as per selection) based on the type of issue including bugs/incidents/stories/others.

The count (story points or number of issues/tasks based on selection) of Incidents resolved and their breakdown by priority is presented in this metric.

This section gives critical metrics on code quality, and the overall productivity of the work being committed - code churn, productive throughput, and efficiency metrics.

This represents the distribution of tasks/issues completed that were planned vs unplanned.

This metric shows the average number of hours of maker time (focus time that is spent on work without distractions like meetings, etc) by the user or the team.

DORA or DevOps Research and Assessment is a framework developed by Google to measure key metrics that impacted software delivery performance. Our DORA dashboard helps you track these metrics to assess release quality.

Cycle time, also known as lead time, is measured as the delta of time of first commit and time of deployment. Cycle time is most often looked at to understand the engineering teams’ speed.

Code that is edited within 21 days of its first merge is called Code churn. Read more about what it is, and what it means to your engineering teams.