Is your project on track to meet all the expected deadlines? Are teams working on tasks that directly align with the business goals? Can your engineering organization accomplish more and be more efficient with the same staff? These are inevitable questions that other execs will be asking you.
To answer these questions, you need to keep track of all the moving parts in an engineering project — but this might be challenging. The trick is to use engineering KPIs (key performance indicators) and metrics to stay efficient and aligned with business needs.
This article will define engineering KPIs and provide a list of 12 KPIs you can use to measure progress of projects, gauge the efficiency of your teams, and stay aligned to business goals.
Table of Contents
- Engineering Metrics vs Engineering KPIs
- Types of Engineering KPIs
- Top 12 KPIs for Engineering Teams
- How to Build a Custom Engineering KPI Dashboard
Engineering Metrics vs Engineering KPIs
People often think metrics and KPIs are the same. Although they serve similar functions, they’re used in different contexts.
Just keep this in mind: every engineering KPI is a metric, but not every engineering metric is a KPI.
Many metrics can help you and your engineering managers monitor and report on your software delivery pipeline. They’re valuable for day-to-day management, but they aren’t the crucial metrics you should be communicating to your executives.
You need to narrow down your metrics to engineering KPIs that communicate how well your engineering organization is achieving defined business objectives. These KPIs should measure things that the rest of the business cares most about: experience, tempo, and alignment.
Types of Engineering KPIs
When evaluating your teams’ progress or performance, you can use several types of key performance indicators. Here are the different categories of engineering KPIs and some examples:
Source: Makeameme
Quantitative Indicators
Quantitative metrics are a straightforward method to evaluate performance. They’re represented by continuous or discrete numbers, such as whole numbers, percentages, and ratios. Examples in engineering include DORA metrics like lead time for changes.
Qualitative Indicators
These indicators aren’t expressed numerically but through feelings or opinions. Qualitative data evaluates performance through feedback. For example, employee retention, developer experience, and the employee net promoter score (eNPS) are all qualitative indicators.
Leading Indicators
Leading indicators are metrics that can help spot trends over the long term and potentially forecast a project’s future success or failure. So let’s say you’ve introduced a new service or product, you’ll use leading indicators to try to predict how successful the venture will be. Examples include PR size and PR review depth.
Lagging Indicators
Lagging indicators like cycle time and deployment frequency enable you to assess the success or failure of an action after it has already taken place. These metrics measure past performance or examine the effects of a management decision. Lagging indicators only show what has already happened, so it can be too late to use them to make up for shortcomings once they’re revealed.
Input Indicators
Input indicators assess the number of resources required for a project or process. They’re especially important for large projects with many moving pieces, but projects of any size can benefit from them. Resource and people effort are two examples of input indicators in software engineering.
Process Indicators
Process indicators enable you to monitor the health of a process and help implement any necessary adjustments. Some typical process indicators for development teams include merge frequency and mean time to restore.
Top 12 KPIs for Engineering Teams
Since each organization has unique goals and objectives, the 12 KPIs listed below aren’t set in stone. But these engineering KPIs cover various software development metrics related to managing people, processes, and projects.
1. Lead Time for Changes
This quantitative metric is a measurement that tracks the time from when a user story is ready to be implemented to when it’s ready for delivery. This time can also include discussions about the user story, how long it was waiting in the backlog, and how much time it took the story to move from pickup to release.
If your lead time for changes is too high, it’s a clear sign of a roadblock somewhere in your processes, causing items in the backlog not to move along. Ideally, you want to keep your lead time low, as it shows your teams are quick to adapt to feedback and deliver on their goals.
2. Deployment Frequency
Deployment frequency tracks how often your teams deploy code to production. It’s a good measure of the value your engineering teams can deliver to customers. However well-oiled your workflow may be, it can fail to deliver sufficient value if you’re not deploying frequently enough.
High deployment frequency shows that your team can make frequent changes to code and make it live — with little fuss and delays. Consequently, this lagging indicator shows that your development teams are efficiently adopting continuous integration and continuous delivery (CI/CD) practices, deploying small pieces of code frequently, and having a solid grasp of the infrastructure.
3. Change Failure Rate (CFR)
Change failure rate measures the percentage of failed deployments to production. This lagging indicator can give you a clear view of software quality and stability. To calculate it, determine the number of deployments that caused failures, and divide it by the total number of deployments.
By monitoring this metric over time, you can get a good idea of how much effort goes into addressing problems and how much goes into releasing new code. When it’s above 15%, your teams are probably spending too much time fixing problems. This means they could be more productive elsewhere, or one of their processes could stand to be improved.
4. Mean Time to Recover (MTTR)
Mean time to recover is another lagging indicator that shows you how quickly a service can resume normal operation after an interruption. To determine this KPI, calculate how long it takes to deploy a patch after an issue is reported.
Even the best DevOps teams experience unanticipated downtime and issues from time to time. You can’t stop failures from happening — but you need to know how long it takes to get things back up and running after they do.
When your company’s recovery period is short, you’ll likely be more willing to experiment and innovate within reasonable limits. As a result, your company gains an edge over its rivals and sees an increase in profits. This engineering metric is crucial because it motivates developers to create more reliable systems.
5. Cycle Time
Cycle time is a lagging indicator that can give you clear insight into a team’s productivity in software development. Cycle time measures the amount of time from the first commit to release to production. In other words, it measures how quickly an engineering team delivers features to the customer. A short cycle time is ideal for any development team.
Lower cycle times result in greater efficiency and profitability. When development managers keep an eye on cycle time, they can see any potential snags in the delivery process before they become major delays.
This is one of the best engineering KPIs for communicating efficiency and tempo to the rest of the business.
6. Pull Request (PR) Size
PR size is a measure of the total number of lines of code modified in a pull request. Developers are less likely to introduce errors or bugs when pull requests are small and easy to understand, making this process indicator easy to implement. And what happens when you reduce pull request size? They become simpler to test and evaluate, allowing team members to provide more extensive feedback. This also increases the chances of detecting bugs.
Ideally, PRs shouldn’t take more than a single session to review and merge. When your teams’ PRs contain hundreds or even thousands of lines of code, it should be a major red flag — they’re too big and you need to split them up.
Source: Created using imgflip
7. Review Depth
This process indicator provides insight into the standard of reviews and their level of detail. PR review depth is measured by the average amount of comments added to each pull request review. To spot and fix all quality concerns, you must review the code before merging or deploying it.
To determine this metric, take the total amount of comments on PRs made during the iteration and divide it by the total PRs made. Too few comments may indicate your teams have gotten too comfortable with “seems good” feedback, whereas too many shows that your code quality is suffering.
Watch this snippet of the Interact 2022 conference that highlights how dangerous PRs can be to your productivity if you don’t do them right.
8. Merge Frequency
Merge frequency is a top-level developer experience metric that makes a big impact on developer satisfaction and retention. Merge frequency is a process indicator that measures the number of PRs or merge requests a team merges during a given timeframe.
Since merges are usually the bottleneck where pull requests get stuck, they significantly affect the overall cycle time. A high merge frequency shows that team members communicate well and are eager to provide constructive feedback on one another’s work. When you improve this metric, customers will receive value faster, and you’ll ensure a good developer experience.
9. Planning Accuracy
Planning accuracy is the ratio of planned and completed issues or story points out of the total issues or story points planned for the iteration. Planning accuracy is a top-level metric that helps you reflect on your roadmap delivery and its alignment with the business needs.
This process indicator provides a snapshot of project trends, allowing teams to more accurately gauge their abilities, set realistic goals, and forecast whether or not they’ll meet their commitments.
LinearB studied nearly 2,000 teams in our Engineering Metrics Benchmarks study and found that accuracy in sprint planning was below 50% on average. This means promised delivery dates are usually not met.
But LinearB helps you correlate data from all of your platforms, so you can pinpoint problems that could delay delivery time — namely unplanned engineering work or tasks carried over from a previous iteration.
10. Investment Profile
An investment profile will help you know whether your engineering teams are putting their time and energy into the right types of tasks. You need to know how much resources your teams spent on each issue category, and this input indicator shows exactly that.
Investment profile gives you a visual idea of the time spent on user stories versus fixes and infrastructure work. And this helps you know where your effort is going — and why it’s going there.
When developers place all their attention on completing user stories but ignore the infrastructure behind them, code quality suffers, and rework will be more likely. This makes it harder for your teams to fix bugs in subsequent cycles and meet future deadlines for new features.
11. People Effort
People effort is an input indicator that measures the number of people invested in a project over time. Three values are relevant to people effort:
- Percentage of team members contributing to the project out of all the people currently working on projects
- Users contributing to the project over the relevant timespan
- Total number of people contributing to the project in each iteration
You must keep tabs on how much time and effort employees put into software projects. Otherwise, you won’t know whether the highest-priority projects are getting the most focus. And this way, you’ll reassure stakeholders that resources are going into the most important goals, ultimately leading to better customer satisfaction.
12. Resource Allocation
With the help of resource allocation, you can find out how much of your teams are dedicated to each individual project. This input indicator will help you ground discussions of your teams’ capacity into hard data.
The following factors are crucial when gauging resource allocation:
- Which developers have put in work on the project during the given period
- How many people were involved in the project during each cycle
Executives will appreciate this metric since it clearly demonstrates whether engineers are focusing on the company’s most crucial goals. Resource allocation, like the investment profile, offers the foundation for productive conversations about balancing several objectives with a fixed amount of resources.
How to Build a Custom Engineering KPI Dashboard
Keeping tabs on your engineering KPIs can be tedious. And time is a resource most engineering leaders simply don’t have. This is where building a custom engineering KPI dashboard with LinearB can help.
LinearB correlates data from your Git, project, release, and incident management tools to give you a consolidated executive dashboard for engineering KPIs. This way you get the metrics you need to make your next check-in more productive.
