Discover important Agile metrics to benchmark and monitor in order to improve the performance of your development team.
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 key performance indicators you need to monitor to make progress.
Relying solely on your intuition and experience means 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; while many 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.
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 style this blog post.
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.
This key performance indicator 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.
Here, we are looking for a stable or increasing trend. Again, throughput metrics capture any contingencies, team changes, etc. Surprisingly, you will find that variability does not affect throughput in many cases 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 confidence level, such as 85%?
This key performance indicator is my favorite because it mirrors the predictability of the team. It gives us an indication of the random nature of item delivery.
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.
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.
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 and the company target their next interventions.
For example, if the roadmap is not regularly shared with the team, the project's direction is unclear, and stress can increase. In such a case, the development team will have difficulty prioritizing emergencies and find itself at a loss in defining 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 performance indicators. For many software developers, it’s tempting to always say yes to overtime and be a hero. But don’t forget about how this reflex can impact team performance.
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, failed deployment recovery time 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. Investing in the automation and infrastructure of your software development is essential 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@axify.io 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!
