Developer Metrics

Developer Metrics  

This widget provides a unified view of developer activity over a specified timeframe to ensure a healthy balance of both code contributions and reviewing others’ work–as both are required for productivity and predictable software delivery. Developer metrics provide visibility into the selected developer activities, the team/group’s activity, and the organization as a whole.This insight enables you to identify overall trends and have data-backed conversations about great performance that needs to be recognized or any imbalances, gaps, and improvement opportunities. For all metrics areas, teams and individuals should strive to fill the outside of the graph–as proximity to the perimeter indicates trending in the right direction. 

That said, you know your team, their roles, and their focus areas best. The distribution will look different based on role and seniority–e.g., a junior dev will likely have more coding time and PRs opened rather than high numbers in reviews or review depth. While a senior developer or architect will likely be the inverse. Be sure to consider this when preparing for conversations with your team.

Like Development Experience, these values use KPIs from the Metrics Dashboard and reflect the Metrics Calculation method you’ve selected in Company Settings.

Reviewer

Reviews: Shows you the number of conducted PR reviews. While junior devs may have fewer reviews and more opened PRs, they should still conduct reviews regularly to uplevel their skillset.

Review Depth: Indicates how thoughtful and thorough a developer’s reviews are. Depth is a measure that takes into account both the size of PRs and the number of comments added to that PR. 

Pickup Time: How quickly PRs are picked up after being issued (for any reviewer to pickup) or after being assigned to the developer you’re looking at.

Submitter

PRs Opened: How many PRs a developer opened over the specified timeframe. The goal should be to have a steady flow of PRs–though pay attention to WIP and working days (in Activity) as these are burnout indicators that should be kept at manageable levels.

PR Size: One of the best leading indicators of efficiency, quality, and overall engineering health. Small PRs are picked up faster, reviewed more quickly, and usually benefit from more thoughtful reviews–resulting in lower cycle time, higher deployment frequency, fewer issues when deployed to production, lower CFR, and reduced MTTR. 

PR maturity: This metric measures the “back and forth” on PRs between submitter and reviewer(s). Generally speaking, small PRs (<250 lines of code changes) that provide reviewers with more context up front (language, estimated review time, testing) and assigned to the right reviewer will result in more maturity as they usually don’t require lots of handoffs. Automation will prove invaluable for increasing PR maturity.