November 11, 2021
In this series, we’ve been presenting some of the KPIs that can help technical leaders answer these questions. Here are some KPIs that will help you optimize engineering processes.
Check out part 1 to learn about investment metrics to track. In part 2, we discussed quality metrics for engineering leaders. In this post you’ll find some KPIs that will help you optimize engineering processes.
What are the Most Important Software Engineering Process KPIs?
Few technical leaders today would argue with the notion that speed to market – that is, delivering product quickly and efficiently – is paramount to success in the world of software. If you’re already confident that your team is building the right things and that those things can continually deliver their intended value to your customers, you’ve got a good base on which to seek efficiencies in process that will allow your team to move faster and increase predictability of the delivery of your commitments to the go-to-market team. Delivering code faster is where most vendors and vocal members of the tech community focus. But delivering predictably is important to set proper expectations, drive alignment across functional teams, and allow for better execution and therefore better penetration of the market for that value your organization has worked so hard to build.
There is no perfect measure of delivery speed, team efficiency and productivity, or predictability. As such, these engineering process KPIs will not be all-encompassing or perfect. Instead, they will highlight trends and therefore give a better understanding for how any process or tooling changes have affected the activity and health of your team. We’ll cover: Cycle Time, Deployment Frequency, and Task (or other unit of work) Resolution Rate Over Time.
Cycle Time
Cycle time is a common metric touted by Agile aficionados and for good reason. It measures the amount of time that elapses from the start of work on a particular task until that task is complete and ready to be shipped. Simply put, cycle time measures the time it takes to complete work on a task. By keeping track of cycle time, you can compare planned work with similar tasks that the team has completed in the past and provide an estimate for the delivery of that functionality. It will help you better predict how long features will take to build and therefore when they should be expected to ship.
Cycle time is also a common metric to gauge how process or tool changes are impacting the speed with which you can provide new functionality to customers. The faster your cycle time, the quicker you are delivering value. Of course, shorter cycle times can also be an indication of smaller chunks of work, which is why understanding the trends over time among similar types of work is more important. It can also be an indication that teams are more singularly focused on delivering certain functionalities – hopefully those that are highest value to your users and your company.
Deployment Frequency
Tracking how often your team does deployments can be extremely useful for understanding and improving on the speed with which you can deliver value to customers. Deployment Frequency is one of the 4 DORA metrics, and in true DevOps fashion, the goal is to do smaller deployments as often as possible. Small deployments will make testing and releasing easier, which will in turn drive down the time it takes to get new functionality in the hands of users. This allows for a more iterative approach to delivering value by giving more opportunities for faster feedback from your users which you can then incorporate into future deployments. Ultimately, measuring deployment frequency will help drive this process to increase the overall value that you are able to provide customers, and make the delivery of that value faster.
Task Resolution Rate Over Time
With most projects being broken down into smaller bits of work that can be handled by and assigned to one engineer, it can be useful to measure how many of those pieces of work are being completed over time versus the number that have been created (resolution rate) over time. Many teams use a common framework where an “issue” is a basic unit of work, a group of issues is an epic, a group of epics is an initiative, and so forth. In that terminology, measuring issue, epic, or initiative resolution rate gives a sense for how well your team is handling the work being assigned to them, how fast they can generally complete this work, and whether changes need to be made.
It’s important to recognize that tasks are not a standard size. Some issues will take a day to resolve, while others will take two weeks simply due to their scope. That’s why we suggest measuring the resolution rate, and monitoring it over time to identify trends. By understanding how your resolution rate is trending you can be quicker to respond to problems that arise in the development process, and measure changes in efficiency when making changes.
The metrics discussed here do not represent an exhaustive list of engineering process KPIs to track, but if you can track all these, you’ll be well on your way with the data you need to provide continuous value to your customers and your company. In our next post, we’ll look at KPIs for tracking and forecasting deliverables.
Want to learn more about which metrics and KPIs you should be tracking? Check out our eBook: 10 KPIs Engineering Leaders Should Track
