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 maximize)
• Number of bugs (try to minimize)

This model is clearly over-simplified, however, in favor of keeping this post brief, we will use it in this writing. Furthermore, 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 basic metrics that we want to optimize, how can we actually measure them?

Measuring the 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

The first thing that may jump into mind is 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 anyway.

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, scale-ups, and even larger companies could use to measure the 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. The 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. The 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 the 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 of 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.