5 Agile Metrics to Track and Improve Your Dev Team’s Performance

Discover important Agile metrics to benchmark and monitor in order to improve the performance of your development team.

5 Agile Metrics to Track and Improve Your Dev Team’s Performance

February 15, 2021
By Alexandre Walsh
Reading time 🕒 7 min

Are you committed to improving the performance of your development team? Great! Now you’re looking for a starting point to benchmark and monitor your progress? In this blog post, I share with you the importance of some of the metrics you need to monitor to make progress.

Relying solely on your intuition and experience is to risk missing out on important elements. Using data is essential to focus your next interventions and rely on facts! There is a wide range of Agile metrics and while many of them are relevant, others don’t matter. As I explore some of these metrics, I’ll share with you what I believe greatly influences software development teams’ delivery performance.

Metrics Based on Speed

Cycle Time

Cycle time refers to the time between the start of a task and its end, i.e., the time when it is considered complete (Done). When a developer assigns himself a task, for example in Jira or Azure DevOps, the timer starts. As soon as he brings it to “Done”, the timer stops. 

This is a fairly simple metric to measure and it speaks volumes about the team’s process, as it captures all the downtime, meetings, unforeseen events, servers that suddenly stop working, etc. If you’re new to measuring cycle time, our Agile Coach Antoine Lefrançois shared some insights in this blog post.

Cycle time screen capture in Axify

 

In general, you want a stable or decreasing trend for cycle time. In the example above, the management team might interpret that a task takes about 5 days to complete. Note here that we are considering 5 days and not 5 working days. This is because contingencies, variations in task complexity and weekends are all factored into cycle time. The advantage of this metric is that it allows better communication between developers and stakeholders.

Throughput

This metric simply illustrates the number of completed elements for a given period. Please note that this is the number of items, not to be confused with the number of story points. For example, when a task is completed, a bug or a user story, we add an item to the flow. I like to inspect it weekly. Again, if measuring throughput is a new habit for you, here are a couple of tips from our Agile Coach, Antoine Lefrançois.  

Throughput screen grab in Axify

 

Here, we are looking for a stable or increasing trend. Again, throughput metrics capture any contingencies, team changes, etc. Surprisingly, you will find that in many cases, variability does not affect throughput as one might think.

The throughput metric can be useful for the management team to predict delivery dates. Therefore, a Monte Carlo simulation will be used rather than the average. Software development is not a deterministic industry, so we cannot expect to get the same result every time we repeat the same experiment. This is why probabilities allow us to make predictions in the future to have more stable and predictable teams.

For example, we could determine from a simulation that we have a 60% chance of meeting a delivery date X if we have to produce 20 items. I often like to use a weather analogy to compare. As much as it is impossible to guarantee 100% sunny weather next Saturday, we use probabilities to try to guarantee a delivery date.

Moreover, when we use the concept of probability, the discussion becomes rather interesting: we can introduce the notion of risk in our strategy. We can also ask ourselves questions as a team. For example, do we want to be more aggressive and bet on a 60% chance of meeting our delivery date or do we aim for a higher level of confidence, such as 85%?

Expected Level of Service

This metric is my favourite because it mirrors the predictability of the team. It gives us an indication of the random nature of item delivery.

Service level expectation print screen in Axify

 

The metric is obtained by inserting all data related to cycle time into a graph like the one above. In the example, we can see that 85% of the tasks are completed in 4 days or less. This percentage represents the 85th percentile. The use of the percentile concept is very interesting because it is not diluted by statistical outliers.

For the management team, every decision necessarily impacts the team’s predictability. The outcome of the team’s performance is reflected here. So be aware that the more random the delivery of items, the more negative the impact on the predictability of your deliveries, and thus your roadmap.

This is why we aim for stability in the development team: to have a high level of confidence in delivery dates and ensure that they are not random.

Metrics Focused on Team Morale

A company’s culture has a direct impact on team delivery performance. That’s why I suggest you continuously ask each member of your teams about their morale, anonymously, using a standardized scoring scale. The questions should be about their stress level, their motivation or their alignment to the project, for example.

Team morale overview in Axify

 

In the example above, while the team seems to have good morale, I can look for reasons why people seem less aligned or more stressed. These metrics help the Scrum Master as well as the company target their next interventions.

For example, if the roadmap is not regularly shared with the team, the direction the project is taking is unclear and stress can increase. In such a case, the development team will have difficulty prioritizing emergencies and will find itself at a loss to define the scope of tasks. The result? Longer development time, since developers don’t understand what is necessary (must-have) and what is not (nice-to-have).

Measuring the pulse of an Agile team goes a long way toward drawing connections between increased stress or lack of alignment and its impact on velocity and quality metrics. For many software developers, it’s tempting to always say yes to overtime and be a hero. But don’t forget about the impact this reflex can have on team performance.

Balancing Metrics Based on Speed With Quality Metrics

While team velocity is important, maintaining a steady pace consistently is paramount. That’s why we also use quality-based metrics.

Google’s DevOps study highlighted the four key metrics that predict better software delivery performance. As such, turnaround time, deployment frequency, mean time to recovery (MTTR) and change failure rate would measure team performance.

However, keep in mind that these metrics do not directly measure quality. To improve these four metrics, you will inevitably need to introduce more quality into your operations. It is also essential to invest in the automation and infrastructure of your software development to improve it. These metrics are very interesting and can be useful to compare our performance to other players in the field.

I realize that every organization is different and that some of these metrics will speak to you more than others. What I like about the metrics described above is that they make my life easier when talking to business leaders or managers, because suddenly we’re speaking a common language. So these metrics promote seamless communication within the team. Since I’m talking more in terms of time and probability, and less in sprints and story points, I sound a little less like an outsider living on another planet. 👽 

Feel free to contact me at awalsh@nexapp.ca if you have any questions or leave comments! You can also share this post with people who are looking to introduce metrics tracking into their organization and may want to learn more about Axify.

See you in the community!

All the charts in this blog post are from Axify, a platform that integrates easily and quickly with tools you already use.

Stay up-to-date on all things Axify

Receive articles and insights to help you stay up to date with all things software development directly in your inbox.

Axify-Produits_Section-5
Related blog post

Software development metrics: to rely on your projections with confidence

Find out why it's essential to measure the team's progress and stabilize its workflow, plus some insights to do it yourself.

Software delivery performance

Teamwork visibility vs. individual performance: a new way of thinking about productivity

We need to broaden our perspective on productivity to focus on well-being, social connections and collaboration, and the innovation they bring to support business success.

Related blog post

How to Measure the Quality of a Software Development Process?

Lean manufacturing and the DORA research program inspired us to go back to basics. And it all starts with measuring your process!