Get some examples of méticos for development teams
Metrics are important points in IT management because they make possible goal setting and team analysis from a more comprehensive point of view. In addition to IT metrics, which evaluate the performance of all processes, indexes are also applied to development teams. These indicators analyze from the quality of the codes to the number of interruptions to which the developer is submitted.
In this post, we shall comment on some of these metrics and how they affect the final product quality. Keep reading!
Concept of metrics for development teams
Before suggesting metrics, it is critical to characterize them. First, an indicator should be easily collected. It should also belong to a small set of indexes, since, in this way, control and follow-up are more efficient.
Its collection should be frequent so that the actions related to its results are also quick. In addition, measurements that can be altered without necessarily increasing productivity must be avoided.
Here are some examples of development metrics:
Number of Interruptions and changes in focus
Every interruption must be accounted for along with task changes. It occurs due to dependence on key personnel. Interruption is detrimental because it brings a delay in resumption of the main task, which causes delays and errors due to lack of attention in the line of reasoning.
Delivery speed is useful only when the company already has a standard. Therefore, it is not the speed that is measured but its variation. This variation is observed when developers enter and leave teams. It serves mainly to calibrate the estimates. This metric also expresses the number of final releases launched on time.
Bugs or code quality
There is usually a trade-off between code/bugs speed and quality. The incidence of bugs should be measured during development and at the time of use by consumers and developers outside the team.
Task cycle time
This is the time it takes the developer to perform a task assigned to them. Basically, it is the period in which they get busy with a task, taking into account delays and interruptions. Thus, this metric is more useful to identify non-productive activities than to define a time to perform tasks.
Number of release candidates (RC)
Release candidates are the finished versions submitted to the quality sector for approval. They are products with potential to become end products. By counting the RC number, management can gauge how well the development team is doing.
Metrics from developers’ point of view
One should remember that metrics are required from top to bottom, that is, managers who examine developers’ efficiency. In a research carried in 2014 by Tasktop and summarized by Techtarget, there is a change by developers themselves in how productivity should be measured.
This study pointed out that developers prefer to be evaluated as follows:
- 27% — Occupation time;
- 17.7% — Complete activities;
- 16.5% — Value of tasks;
- 15.7% — Time per task performed;
- 14.5% — Number of change of focus and interruptions.
As can be seen, most developers do not want to be measured by a particular task but rather by the state of occupation. In that same survey, developers still mentioned what is or is not productive.
The highlight of a productive action, as might be expected, is the programming itself, with 72%. As for 58% of them, they have pointed to meetings as the greatest source of non-productivity.
Using simple and easy-to-follow metrics, always taking into account the developers’ opinions, without using them to rank employees, IT management becomes simple and agile as it should be.