Fundamental metrics in software development
In this article we assume that a software development process is good, if it maximises the following three fundamental metrics:
- Speed – a faster development will deliver more services and richer products to customers. If the team is in the prototyping phase and does not have customers yet, it could also benefit from higher speed. If the team is faster it will make more experiments and more iterations and in this way raise its chances of finding a good product-market fit. All in all the speed of development is crucial for the innovation readiness of the team and hence also of the company.
- Quality – delivering software fast is not sufficient, it needs to be of good quality. Good quality will have different meaning for different projects and domains.
- Team Happiness – software development team consists of people. A good development process will contribute towards maximising the people’s happiness.
Alignment between customer needs and the development team is of course also crucial for success, however we consider it out-of-scope in this writing.
Can software development teams improve among all fundamental metrics? Or one should compromise and make trade-offs? In Perelik Soft we firmly believe that teams and companies can improve on all three metrics simultaneously. No trade-offs.
At the same time:
If you cannot measure it, you cannot improve it.
Peter Drucker, William Thomson
So how can we measure how good a software development process is in regards to Speed, Quality and Team Happiness?
We have already presented some measurable metrics for the quality of a software engineering process and in this blog post, we will expand further the list.
Albeit not entirely thorough, the presented metrics can be used to self-assess and gain some insights in the current state of the development process in a given team.
Measurable metrics for the efficiency of a software development process
In the following table one can see 11 easy to measure metrics, which could shed some light on the current development process. When a metric is a series of data points (e.g days a code review stays open) one can take the median. Median is better than average because average can be too heavily influenced by outliers.
|Days a code review stays open [days]
|Days for the first comment in a code review [days]
|How many people from the team review the code reviews [%]
|Uninterrupted hours per day a developer has for coding [hours]
|Days it takes to configure the dev environment for a new developer [days]
|Days it takes to deploy a new ready release to PROD [days]
|Time it takes to build the code with all tests [minutes]
|Code coverage [%]
|Number of major issues in production in the last 6 months [integer]
|What is the discrepancy between commitment and done per sprint in the last 6 months [%]
|Number of Devs who have left the team in the last 12 months / number of Devs right now [float]
This brief article presents 11 concrete metrics for the assessment of a software development process. Every metric can be measured easily, so one can gain some real number representation for the somewhat vague concepts Speed, Quality and Team Happiness.
It could be interesting to assess the metrics in regular time intervals, in order to understand better the effects of changes introduced to the process.
Further it is important to note that looking on metrics in isolation might not yield sensible results (it can be even damaging). One needs a holistic approach.