Metrics in software development evolve with the project and with the experience gained. What are the most used? Here we answer this!
If a doctor says he has attended 35 new patients, how useful is that piece of information? What does that really mean? Without context or more data to compare it against, this alone does not make much sense. Now, if the same doctor tells us that he has attended 30 patients per month during the last twelve months or that he has attended 35 when his average is 50, there’s a different color to it.
Today, we have a lot of data at our fingertips, but the trick is to identify which of it is important for our business and measure it regularly. Only then we will understand where we are so that we can make the best decisions.
Did someone say metrics? What is that?
A metric is defined as a standard of measurement by which efficiency, performance, progress, or quality of a plan, process, or product can be assessed. In other words, metrics are a set of numbers that give us information about a product, process, or activity, in terms of quality, cost, schedule, complexity, etc. For example, a deviation metric can tell us where we stand compared to the established schedule.
In some way, metrics tell us about the history of how we were yesterday and what our current position is, helping us see if things are going well or not and if we are reaching our goals. The latter is fundamental: the metrics that we choose must be aligned with our objectives. When we do that, the team keeps focused on the things that are important to us.
Metrics serve several functions:
- They help us better understand our products and processes, facilitating communication and reporting.
- They evaluate products and processes based on our standards and goals.
- They provide information to control
- They help predict future behaviors.
A key aspect to keep in mind is that measuring metrics is not a goal by itself but continuous improvement through measurement, analysis, and feedback. Knowing how they are going to be used and what they are for is what really gives them their true value.
Metrics as a fundamental tool for continuous improvement
To establish improvement goals during the software development process, you must understand its current status. If it is not measured, there is no way to determine whether or not it is improving.
What we must do then, first of all, is to select the metrics that are more relevant and that add value to our project, according to its nature and context. Usually, it’s difficult to start from scratch, so a good practice is to have a database of standard metrics to choose from.
For example, at Hexacta, we have defined a set of standard metrics, based on our own experience and best practices in the software community: Percentage of rework, Testing Efficiency, and Bugs injected per hour, among others, are some of the metrics that are included in it.
Additionally, we have specific metrics for Scrum projects, such as Story Points Deviation, and Velocity, as well as for Kanban projects where we use Cycle Time and Lead Time. For other kinds of projects, based on RUP and CMMI, we use Progress Percentage and Progress Deviation, to name a few.
It is important to emphasize that each project can add their own custom metrics that are useful for it, according to its particular context.
Continuing with the analogy of the doctor, the metrics are somewhat similar to a blood test: Drawing conclusions from a single value is ill-advised. It is important to evaluate all values as a whole. Metrics relate to one another, and having one measurement out of range may not be a problem by itself when there are other metrics measurements that compensate for it or justify its value.
It is also important to keep the number of metrics low in order for them to stay manageable and test different combinations when we detect that some are no longer useful. Businesses change and are better understood as the project progresses; hence, it is essential to review your metrics selection periodically to ensure they are measuring what we really want.
Lastly, it is paramount to share the gathered information with the team in order to detect potential problems and areas for improvement.
Metrics and Scrum
If you consider metrics as bureaucratic paperwork (the archenemy of Agile), you would be wrong. One of the pillars of the Agile spirit is the empirical adaptation and continuous improvement of our processes. This is exercised during the Retrospective meeting, a ceremony explicitly used for that purpose. It is during that meeting where processes are analyzed, and adjustments are made in order to improve them after each Sprint.
If you do not have a tool to effectively assess if the adjustments that you make have the desired impact, you will be walking in the dark, left alone with nothing more than a subjective feeling of whether your processes have improved or not.
Content related: Say no more “Buts” and stops asking yourself why Scrum is not working
To sum up
The use of metrics is not a goal by itself but an analysis in order to continuously improve the way you work. It is very important that the whole software development team is aware of them to determine what actions to apply in order to correct what is wrong or better yet, to propose improvements.
Additionally, metrics evolve with the project and with the experience gained by the team, so it is not expected that they remain static throughout the lifecycle of the project: they should evolve along with the development processes.
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.
