Reading tip: The latest issue of the German magazine Java aktuell (Nr. 05/2021) features a guest article by our Richard Fichtner.

Under the title "Metrics for Agile Software Development Teams", he presents the metrics that we at XDEV have designed for our processes in order to make the metadata of our work accessible to all team members in a visualized form. After all, the better we understand our own work, the better we can make meaningful and sustainable adjustments to processes within the development team.

Richard writes: "In the context of Scrum, there are already some metrics and visualizations that are widely used and discussed in the community. These include metrics like Velocity, which indicates how many story points a team accomplishes in a sprint, and visualizations like the burndown chart. Basic questions about agile software development can be answered via common metrics. However, we need different metrics for our questions." In the article, Richard then presents three specific metrics in detail:

Team Homogeneity (TH)

Here, the team is examined for its work or task homogeneity. Knowledge of team homogeneity can be used, for example, to predict "knowledge bottlenecks" that lead to the team having to skip tasks or wait because specific knowledge only exists in one place in the team. Team Homogeneity also allows conclusions to be drawn about James Coplien's metric known as the "Bus Factor" or "Truck Number": "How many (or few) would have to get run over (or quit) by a truck before the project fails?"

Sprint-Profile (SP)

The sprint profile is intended to show in which types of tasks (features, bugs, hotfixes, meetings) the team has invested how much time in the sprint. This not only makes sprints comparable in the "task type" dimension, but also makes them easier to plan for the future.

Team Time Commitment (TTC)

This metric provides the answer to the question of how much time was contributed by the development team. (Not to be confused with the Velocity metric). TTC shows the extent to which the team was able to work or not work on the sprint and helps to better plan sprint capacity in the future.

In conclusion, Richard states in his article, "The presentation of the metrics was often the impetus for a lively discussion that allowed deep insights into the team's working reality. Personal opinions on various metrics vary widely, but it became apparent that just talking about metrics is very fruitful. This is where we see the true value. Numbers always come with assumptions and inadequately represent reality. However, the conversations that were stimulated by the numbers still helped many teams move forward. So I can only encourage talking about metrics and, true to the agile motto "inspect and adapt," exploring what comes out of it."

The complete article is available here in German as a PDF: