Developer productivity metrics
Developer productivity metrics
Learn about DevOps Intelligence support of developer productivity metrics, and their critical role in fine tuning your developer processes.
Developer productivity is highly dependent on the processes that govern activity. Most developers perform at very high levels within the boundaries of their organization and the processes that govern those activities, but their productivity can be limited by those boundaries. In that context, it's important to acknowledge that creativity is an integral but understated element of strategic software architecture and tactical coding--and that creativity is challenging to measure.
The final outcome of software development is often thought of similar to the same way people think of assembling a jigsaw puzzle. That there is a model participants work toward, with a certainty of what the final outcome will be—the photo on the box. It's a well defined picture that developers work toward in which the final form is predetermined. The reality is that it's more like a Lego set that can be used to build something that has a specified utility, and for which the final form is not entirely certain.
Kyndryl has determined that, at a minimum, the following metrics are critical to assessing the progress of the development effort:
- Commit Frequency:Tracks the number of Commits integrated into the main branch by each developer per day.
- Pull Request Size:Quantifies the volume of code changes submitted in a single pull request.
- Pull Request Time to Merge:The time span from the creation of a Pull Request (PR) until it is merged into the main branch.
- Code Review Velocity:Measures the time it takes for code changes or pull requests to be reviewed and either approved or rejected.
- Code Review Efficiency:Measures the ratio of new defects found during a pull request review to the total number of known defects not yet resolved.
To review Developer Productivity metrics, navigate to DevOps Intelligence →
DevOps Performance Metrics
, and click the Productivity Metrics
tab.Commit Frequency
Commit frequency measures how often a developer or team Commits code to a project's main branch. It is calculated by dividing the number of Commits by the length of the time period. It is a proxy for how many features are shipped, and it indicates a team's ability to integrate new code. A high Commit frequency can mean a team is productive and merging code frequently. By contrast, a low Commit frequency indicates challenges with deploying code changes. Frequent committing helps in early detection of issues and reduced chances of conflict between developments. Tracking is enabled at both the application level and developer level.
The Commit Frequency dashboard widget is bounded by Commit dates on the X axis and the number of Commits on the Y axis. The widget defaults to a multi-line graph that tracks either application Commits, or developer Commits depending on your filter selection. Each line represents a specific application or developer and is color coded to distinguish applications and individuals. A black line shows the average number of Commits for each date for both applications and developer team members, and the graph is shaded grey below the average to highlight those applications and developers who are above and below average in Commit frequency. Hover over each data point to display the following details:
- Developer or application
- Number of Commits for the developer or application on that date
- The number of technical services
Click the expansion arrow in the upper right corner of the widget to navigate to the details page, containing a table with the following details:
- Commit ID: A hot link to all four metrics for that Commit in the form of graphic displays.
- Application: The application associated with that Commit.
- Technical Service: The service that was updated.
- Commit date: The date on which the Commit occured.
- Message: Messages submitted with the Commit.
- Linked PR:The Pull request associated with the Commit.
- Created By: The ID of the developer who executed the Commit.
A filter to select individual applications or developers is also available with two caveats:
- The DevOps Intelligence release manager role is required to view developers.
- A maximum of 10 developers can be selected.
Pull Request Size
Pull Request Size indicates the extent or magnitude of the modifications made by a developer and has two components:
- Line of code modified (added or deleted)
- Number of files modified.
The Pull Request Size dashboard widget is bounded by the Pull Request dates on the X axis and the number of files modified on the Y axis. The widget defaults to a multi-line graph that tracks either by application or developer depending on your filter selection. Each line represents a specific application or developer and is color coded to distinguish applications and individuals. A black line shows the average number of Pull Requests for each date for both applications and developer team members, and the graph is shaded grey below the average to highlight those applications and developers who are above and below average in Pull Request Size. Hover over each data point to display the following details:
- Developer or application
- Lines modified
- Date of pullrequest
- Tool engine
- Technical services
- DevOps Intelligence release manager is required to view developers.
- A maximum of 10 developers can be selected.
Click the expansion arrow in the upper right corner of the widget to navigate to the details page, containing a table with the following details:
- Pull Request number:A hot link to all four metrics for that Pull Requst in the form of graphic displays.
- Application:The Application associated with the Pull Request.
- Technical Service:The service that was updated.
- Status:The status of the Pull Request.
- Message:Any message posted with the Pull Request.
- Created On:The date the Pull Request was created.
- Merged On:The date and time of the merge.
- No. of Files modified:The number of files that were changed within the Pull Request.
- No. of Comments:Code line comments accompanying the Pull Request.
Pull Request data is captured only for Pull Requests that have been succesfully merged.
PullRequest Time to Merge
Pull Request Time to Merge is calculated from the time of Pull Request creation to merge, including any time it was in draft status. A low Time to Merge is associated with a higher success rate for Pull Requests and a shorter cycle time. A high Time to Merge can indicate that a team is managing too much work in progress, which can lead to bottlenecks and increased context switching, whereas a low Time to Merge indicates Team Efficiency; Collaboration Insight; Enhanced Code Quality.
The Pull Request Time to Merge dashboard widget is bounded by the Pull Request dates on the X axis and the merge time span on the Y axis. The widget defaults to a multi-line graph that tracks either by application or developer depending on your filter selection. Each line represents a specific application or developer and is color coded to distinguish applications and individuals. A black line shows the average number of Pull Requests for each date for both applications and developer team members, and the graph is shaded grey below the average to highlight those applications and developers who are above and below average in merge time.
Click the expansion arrow in the upper right corner of the widget to navigate to the details page, containing a table with the following details:
- Pull Request number:A hot link to all four metrics for that Pull Request in the form of graphic displays.
- Message:Any message posted with the Pull Request.
- Created On:The date the Pull Request was created.
- Merged with Main Branch On:The date and time of the merge.
- Created By:The Developer who initiated the Pull Request.
- Time To Merge:The merge duration time.
- No. of Comments:Code line comments accompanying the Pull Request
- No. of Lines Changed:The total number of lines that changed in the submitted code.
- No. of Files modified:The number of files that were changed within the Pull Request
A filter to select individual applications or developers is also available with two caveats:
- The DevOps Intelligence release manager role is required to view developers.
- A maximum of 10 developers can be selected.
Pull Request data is captured only for Pull Requests that have been succesfully merged.
Code Review Velocity
Code Review Velocity measures how quickly code changes are evaluated and integrated into the main codebase, often indicated by the average time taken for a pull request to be reviewed and approved. This metric assesses the efficiency of the code review process by tracking the duration between submitting a request and receiving feedback. The following upstream metrics are used to calculate Code Review Velocity:
- Track Submission Time:Record the time when a pull request or code change is submitted for review.
- Track Feedback Time:Record the time when the initial feedback is provided.
- Calculate Duration:Subtract the submission time from the feedback time to get the review duration.
- Average Duration:Calculate the average review duration over a specific period, for example, weekly or monthly, to get a meaningful metric.
- Developer or application
- Number of Pull Requests
- Number of code reviews
- Date of code review
- Tool Engine
Click the expansion arrow in the upper right corner of the widget to navigate to the details page, containing a table with the following details:
- Pull Request number:A hot link to all four metrics for that Pull Requst in the form of graphic displays.
- Summary:The description that explains the changes made in a pull request.
- Raised On:The date and time the Review was requested.
- Merged On:The date and time of the merge.
- Developer Requested:The developer who requested the review.
A filter to select individual applications or developers is also available with two caveats:
- The DevOps Intelligence release manager role is required to view developers.
- A maximum of 10 developers can be selected.
- The review time does not depend on whether PR was accepted or rejected.
- Pull Request data is captured only for Pull Requests that have been succesfully merged.
GitHub and other tools integrated by way of the
Bring Your Own Tools
DevOps feature are supported for capturing these metrics, to accommodate your team's approach.Code Review Efficiency
Code review efficiency measures how effectively the code review process identifies defects before the code is merged into the main codebase. It helps ensure that the code quality is high and reduces the number of defects that are introduced to production. It is calculated as follows:
- Find the the number of inline comments in the code submitted code for the pull request review (brownfiled deployment).
- Find the number of defects identified by defect number during the review (greenfield deployment).
- Find the sum of the brownfiled and greenfield defects that remain unresolved.
- Find the ratio of unresolved conflicts in the pull request review to the resolved conflicts in the codebase.
- Divide the sum by the number of total defects.
This metric provides insights into the development activity at both the application and individual developer levels, enabling teams to optimize their workflow and improve efficiency. Using this insight, development managers acquire the following benefits:
- Improved Code Quality:Efficient code reviews help identify and fix defects early, leading to higher quality code.
- Reduced Rework:By identifying issues early, the amount of rework required is minimized, saving time and resources.
- Increased Productivity:Efficient reviews streamline the development process, allowing teams to deliver features faster.
- Enhanced Collaboration:Regular reviews foster better communication and collaboration among team members.
A filter to select individual applications or developers is also available with two caveats:
- The DevOps Intelligence release manager role is required to view developers.
- A maximum of 10 developers can be selected.
Do you have two minutes for a quick survey?
Take Survey
