5 tangible metrics for the speed of software engineering teams

Introduction

Firstly, since we want to discuss the topic of metrics, what does it mean for a software engineering team to perform well anyway? For the purpose of this post let us take the following metrics for a given software engineering team as the fundamental one:

• Speed of development (try to maximise)
• Number of bugs (try to minimise)

This model is clearly over-simplified, however in favour of keeping this post brief, we will use it in this writing. Further we are concentrating on the technical perspective here. Alignment of business and engineering is crucial for success, however it is a topic for another post.

So now that we have defined the basis metrics we want to optimise, how can we actually measure them?

Measuring number of bugs is rather easy. We can literally count the number of bugs that the team produces per unit of time, e.g. number of bugs per month. Speed of development however is not trivial to measure.

Why Scrum Story Points Might Be a Bad Metric

First thing that may jump into mind are scrum story points. The problem here is that, if one wants to use this metric, you are assuming that A) the evaluation of the stories is somewhat precise and B) the evaluation of the stories does not change over time (similar stories get the same points). In my experience both assumptions are highly speculative. Story points could be used as a metric to some extend but they are not sufficient and do not draw the full picture. Further some teams are not using them anyways.

At the same time you cannot improve something you do not measure. To know that you are going in the right direction you need some concrete, hopefully easy to understand, metrics.

The Proposed Metrics

Without further ado, here are 5 simple metrics startups, scaleups and even larger companies could use to measure speed of development in their software engineering teams:

1. Days a code review stays open – code is the main output of a software engineering team, and code reviews are a beautiful log of how the code gets written. You could look into the velocity of code reviews.
2. Days it takes to configure the development environment for a new developer – teams welcome new members over time, hence if you want to gain speed you could think about your development environment. How easy it is to configure it for a new team member?
3. Time it takes to build the code and run the tests – the speed of your tests influences how fast you can experiment and develop.
4. Number of uninterrupted hours a developer has for coding per day – context switching is a severe efficiency-killer, lower number here might be a reason for slower speed of development.
5. Turnover of developers in the team in the last 6 months – as we have already mentioned, getting an engineering team in the performance state takes some time. If developers have not concentrated for a longer period of time on the given project, it is likely that the speed of development of the team will be low, since each new engineer becomes productive only after understanding the codebase and the business domain.

Conclusion

Admittedly, these metrics alone will not be sufficient and they are actually proxy metrics for the speed of development. The topic is rather complex and there is the need to consider multiple factors for a more precise evaluation. Also it is of significant importance to interpret the metrics correctly regarding the context of the given environment. Overly relying only on some metrics might actually be counter-productive, it is important to have a holistic approach.

Nevertheless these easy to measure metrics might shed some light on the current state in a software R&D team in some of the dimensions. More interestingly, once measured, one can think of ways how to improve them and see what the effects would be.

Do you have any questions about this article or just want to discuss the topic? We have developed a DevOps Benchmark which includes besides the herein mentioned also few other metrics. Do not hesitate to contact us for more information.

— — —

We put a lot of effort in the content creation in our blog. Multiple information sources are used, we do our own analysis and always double check what we have written down. However, it is still possible that factual or other mistakes occur. If you choose to use what is written on our blog in your own business or personal activities, you do so at your own risk. Be aware that Perelik Soft Ltd. is not liable for any direct or indirect damages you may suffer regarding the use of the content of our blog.