Developer productivity metrics

learn about 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 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 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 benefits of smaller pull requests enables easier reviews and faster feedback generally, larger pull requests require more time to review and are more difficult to assess this can negatively affect downstream metrics such as time to merge and code review velocity, and diminish development team efficiency industry standard guidelines suggest a pull request size of 200 to 400 lines of code the actual threshold should be set by your organization and used as a baseline in assessing development teams 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 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 note pull request data is captured only for pull requests that have been succesfully merged pull request 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 release manager role is required to view developers a maximum of 10 developers can be selected note 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 the code review velocity dashboard widget is bounded by the pull request dates on the x axis and the number of code reviews on the y axis, and it displays the average duration of all code reviews as a header 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 speed 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's reviews are above and below average in duration hover over each data point to display the following details 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 release manager role is required to view developers a maximum of 10 developers can be selected note 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 note 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 release manager role is required to view developers a maximum of 10 developers can be selected