We take a look at how the software development process can be effectively gauged through software development performance metrics.
If you turn to your average developer for a definition of their trade, chances are you’ll be hearing the word “art” a lot. Software engineers — especially senior ones — do tend to liken their work to the process of creating artistic forms and this comparison is quite justified in many cases. Without imagination and a creative approach to every challenge, building complex, innovative systems is nearly impossible.
As a business owner or CTO, you still need to develop an unbiased, data-based approach to assessing the performance of engineers. After all, you don’t judge a painter by the number of brush strokes or the breadth of their color gamut, right? So what are the software development KPIs that may work for those engineers without denying the presence of an artistic x-factor in their work?
Software development metrics to ditch
Compared to traditional manufacturing, the software development industry is still very young, which explains why there is no single, agreed-upon method of measuring the efficiency of individual developers or units. The approach largely depends on the company’s type, size, cultural code, traditions, types of projects it works with, and a multitude of other factors.
However, it is already evident that the software development metrics that were used some 20-30 years ago no longer apply to modern agile processes and understanding of software product development. One of the key reasons was that the old KPI’s is that they used to measure throughput or output, not results, and focused primarily on individual performance, not that of a workgroup of team.
For example, the number of lines of code (LOC) written per hour or day used to be a staple software development KPI for decades. With time, it became apparent that this metric was no longer a credible indicator of an individual’s performance. As companies and programmers made a drastic turn toward value-driven and team-based development, lines of code ceased to mean anything. Are 200 lines of code better than 50 if they do the same? Does the number of lines tell you if you are making good progress or is it just an abstract metric without a context? The short answer is no, of course, but this dilemma made software companies look for other options.
Software developer performance metrics by category
Modern technology companies extensively use agile methodologies that strongly rely on teamwork in many aspects: from work planning and task estimation to development, testing, and deployment to the production environment. Under these circumstances, it is hard to effectively single out the contribution of individual team members — instead, it is the combined effort of the entire group of engineers that matters.
With this in mind, software development metrics had to be changed as well. In general, KPI metrics for software development can be roughly broken down into various categories:
- Formal metrics — lines of code per day and similar KPI’s, almost irrelevant today.
- Operational metrics — statistical KPI’s like mean time between failures and mean time to recover.
- Developer productivity metrics — KPI’s related to the elements of individual effectiveness of software engineers, such as code churn, scope of work, etc.
- Agile-related metrics — KPI’s specific to the agile process used by the company, such as lead time and team velocity, among many others.
- Test-related metrics — metrics based on code coverage, number of unresolved issues, test automation, and such.
- Customer satisfaction metrics — metrics reflecting the customer satisfaction level.
KPI examples for software development from our practice
To give you an example, we at Softage adopted several software engineering KPI metrics that we consider to be relevant, meaningful, and effective in our case. They were picked from a number of KPI categories listed above:
- Lead time – time needed for a feature to go all the way from a user request to deployment to production.
- Deployment frequency — shows how often code is deployed to the production environment.
- Commit size — smaller packages are easier to track and troubleshoot.
- Team velocity — the speed of the team in story points or other agreed-upon units.
- Change fail percentage — the percentage of code commits that gets rolled back due to various issues.
- Issue open/close rate — the rate at which issues are entered into the system and closed as fixed.
- Mean time to restore — the time required for an issue to be resolved.
All of these software development KPI values reflect how quickly and effectively the team reacts to defects and service requests entered into the system and how well QA is performed. We believe that these 7 metrics are the most objective indicators for our development model, as they enable us to quantify parameters that directly affect the speed of feature delivery. We work with these metrics during retrospects to analyze mistakes and tweak our processes accordingly.
These are just software development KPI examples, but hopefully they will give you an idea of what to look for in your own organization. The basic rule here is that all of your KPI’s are supposed to have the following characteristics:
- Easy to understand
- Easy to compare
- Expressed in a meaningful way, such as a rate or ratio
- Enforceable — that is, affecting the way you work
Make sure your KPI’s match these criteria and you’ll be off to a good start on a journey to improve the performance of your development team. Chasing wrong KPI’s, on the other hand, will be a major distraction that may affect the team’s motivation and business on the whole.
Bottom line
When it comes to defining software development metrics for your company, there is no software developer KPI template and no cookie-cutter approach to accomplishing this task. You need to analyze multiple factors, pick the metrics that are best aligned with your processes, and work with your team to continuously use them to implement valuable changes. There is a good chance that your own list of KPI’s will be dramatically different from ours, and it’s a perfectly normal thing.
