56 Examples of KPIs for Agile Software Teams

Key Performance Indicators measure progress toward an intended outcome. For managers, this means having the data to make decisions and understanding how your team is performing.

Here are 56 examples of KPIs you may want to consider if you’re managing a software team.

KPIs to Consider Using in Your Software Team

1. Number of story points completed per period (week/sprint)

Story points are a relative measure of a task’s complexity. They tell you how long a story will take in relation to other stories, but not give an absolute sense of the amount of time (unlike an hour estimate). I explain why you should avoid using time-based estimates later on in this article.

2. Burn rate (in a burndown chart)

Burndown charts show the progression of a project in terms of the amount of work completed v. the total amount of work. Burn rate is the slope (or change) of the line in that chart. Monitoring the burn rate is helpful for understanding whether a project is stalling or on track.

Importantly, burn rates can be impacted by reporting, so it is not a perfect measure in the near-term. Managers should weigh the cost of more aggressive reporting with the benefits of higher visibility (in general, more frequent reporting slows progress)

3. Average time to fix bugs (from report to deployment)

This metric looks at the amount of time that it takes for a bug report to be fixed. I recommend measuring this from the time that a customer opens a support ticket to the solution becoming available to the customer.

4. Average age of unmerged pull requests

The average age of all outstanding pull requests, minus the ones that are marked as a “work in progress”, is a valuable indicator for measuring whether your team is bottlenecked or is poorly allocating time toward releasing existing software changes at the current time.

Occasionally, this measure can be skewed when a lot of discrete components of a product change need to be deployed at once. For example, in a client-server application, a client-side pull request may stay open until the server-side implementation is complete, so the client-side can actually work.

5. Average time between pull requests being opened and being merged

Unlike the previous KPI, the average cycle time for pull requests is a useful measure of team velocity. If pull request cycles take a long time to complete, managers should perform a root-cause analysis to better understand what is going on.

6. Commits made per day

A commit is a snapshot of changes made by a developer. Think of commits as being similar to “versioning” a document: if you create Doc_A, make a bunch of changes, then save those changes as Doc_B, you’re creating a commit.

Commits are a relative signal of velocity and/or traceability of code changes. While looking at the measure in isolation rarely yields any useful insights, it can be useful when comparing a developer against their peers and looking at this measure as a rate-per-story.

7. Number of comments on a pull request

During a code review session, other developers will often leave comments for the pull request author to review. Some are a simple “looks good to me” message acknowledging that a pull request is ready to be accepted, while others provide specific feedback on code changes (see the next KPI for more details).

By tracking the number of comments made on a pull request, a manager can gain some insight into the level of engagement other developers have on a pull request.

Caveat: asking developers to write more pull request comments is not typically helpful. Commenting on obvious or computer-generated code doesn’t provide value. Instead, use this as a starting point to triage which pull requests to look into further.

8. Categorized number of comments on a pull request
Another way to look at comments on a pull request is to break down the comments by category.

Messages like “looks good to me” (approval) indicate something very different than “please ident this,” (correction, code standards) which is different than “rename this function” (correction, naming) or “this would be more efficient if you converted the array to an object first, then accessed its contents using the ID as the key, instead of searching an array each time.” (correction, algorithmic)

9. Average number of iterations on a pull request

In an ideal world, a pull request would follow the process of Open -> Approve -> Merge, without any changes made by the original developer, because the developer perfectly implemented their solution.

In reality, developers rarely write perfect code and the code review process is invaluable for improving the overall quality of code. As such, a manager should watch for pull requests that get rapidly accepted without any changes being made by the developer: sometimes a developer writes great code that needs no changes, but more often it gets accepted because the reviewer didn’t actually review the code.

10. Lines of code removed in a refactor
Although lines of code is not a good measure of developer velocity, it can be a good measure of code quality when it is tied to refactoring. More code typically means more complexity. Removing complexity improves the maintainability of code.

11. Percentage of stories completed in a sprint

This measure is rarely useful on a per-sprint basis, but can be useful to know over the course of several sprints.

If there’s an anomaly in the data, it can tell you that something unusual happened: maybe someone called out sick for a few days, or perhaps a bunch of urgent items made their way into the sprint (scope change).

12. Percentage of story points completed in a sprint

This measure is very similar to the previous one, but it instead looks at the amount of work done (on a relative basis).

Again, this measure is not useful when looked at without historical context. However, if most sprints are left incomplete at the end, it can be an indicator that the project manager is planning too aggressively for the people available.

13. Bug-to-story storypoint ratio

Unless your code is perfect with no bugs, it’s pragmatic to fix issues before adding new features. It’s realistic to balance adding new features (so as to support sales growth) and fixing existing issues (after triaging them, based on their severity).

This ratio gives you an understanding of how your team allocates time – toward fixing issues or towards adding new features.

14. Time between pull request and production release

First, understand your process. Do you have automated tests and a continuous integration/continuous development system (CI/CD)?

What is your approval process like to accept a change? Does merging code automatically deploy it?

15. Lines of code

Be extremely careful with this one. It’s only useful for understanding the maintainability of a project.

Many lines of code do not necessarily indicate good or bad when looked at in a vacuum, but when compared to other projects, it can be an indicator of the complexity of a project.

16. Number of stale backlog items

Stale backlog items are often outdated and may be irrelevant. It’s important that your product manager/project manager regularly reviews the backlog and prunes old and stale backlog items.

17. Number of releases per quarter

How regularly does your team deploy code? In companies like Google, Microsoft, Facebook, and yes, Minsilo, code gets deployed several times a day.

For stable products that rarely change, such as an insurance underwriting model, this number may be close to zero.

For products where rapid, agile iteration is desirable, faster and more frequent deployment cycles are desirable.

18. Number of developers

There is a book that’s almost as old as software engineering itself called “The Mythical Man-Month” (1975) that claims software projects will take longer if you add new people to them after they’ve begun. Brook’s Law, as it’s called, tells us that more isn’t always better when it comes to the size of a development project.

One reason more isn’t better is that having more people can serve to slow everything down.

The cost of communication grows nearly exponentially. The systems that a company uses have a significant impact on this, but no system can eliminate the reality that more people means more complexity and the diseconomies of scale become more pronounced.

This KPI is worth tracking, especially in terms of velocity. Does your development team actually slow down as it grows (graph this metric against a velocity metric to check).

19. Average team size

It’s often useful to look at team size when considering how to allocate talent. The general rule of thumb is that a team reaches peak efficiency at around 7 people and that efficiency quickly declines off as the team grows.

Prefer having smaller, more focused teams instead of large teams whenever possible.

20. Variance of estimated story points to actual story points

This KPI tells you how good your estimates are. If you see a significant discrepancy between your estimates and the amount of effort it actually takes to complete a story, you may want to spend time working to improve your team’s estimation skills.

21. Percentage of unplanned tasks/stories per sprint

After starting a sprint, do you end up adding new tasks/stories to the sprint?

Pay close attention to this and the percentage of story points completed. It can help you to identify underplanning (where you assign too few stories in a sprint) or it can help you to identify shifting priorities (especially if you end up increasing the size of the sprint, without completing the original work of the sprint).

22. Percentage of stories being reopened

Ideally – but not necessarily practically – a story should not be shipped until it’s complete. If a lot of stories are being reopened after launch, this can indicate inadequate scoping or specification writing. It can also indicate sloppy coding practices or inadequate tests, especially if the stories are being reopened because of bugs.

23. Average time between initial release of a story and revision

How long does code last for in your project? Do you go through a major overhaul of a feature frequently or is it infrequent?

It can make sense to prioritize rapidly releasing features, even if you expect to change them in the next 6-18 months.

24. Code coverage

How many lines of code are executed by automated tests? Believe it or not, writing tests can actually speed up development in the long run, by reducing the number of regressions that are uncaught until after changes are released.

25. Number of known security vulnerabilities in a code repository.

There are a number of automated tools for identifying known security vulnerabilities in libraries that your project is using. GitHub, for example, even has this built-in to their platform.

Not all security vulnerabilities are relevant to your team, however. A particularly nasty remote code execution vulnerability for a Javascript library, for example, may have no relevance to your React client-side project (since there’s no remote machine to attack).

26. Number of critical severity security vulnerabilities in a code repository

While all security vulnerabilities require diligence, not all security vulnerabilities are equally bad. Critical severity vulnerabilities, in particular, require immediate attention as they can pose a significant risk to the security of your customer’s device or their data.

27. Number of third-party dependencies

Knowing how many third-party dependencies you have in a project can be an important indicator of how brittle your project may become. While third-party dependencies are not inherently bad (in fact, they’re the best way to move quickly and deliver more maintainable software), relying on third-party libraries may mean your team will need to replace one or more of those libraries in the future.

28. Number of first-party dependencies

How many other projects does your codebase depend on? If you have a lot of projects, managing them can be time-consuming and difficult.

Too many first-party dependencies can indicate that there’s a lot of “not-invented-here” going on within your projects. In general, third-party dependencies should outnumber first-party ones.

29. Lines of code based on origin: first-party v. third-party

Depending on the language, your project should have more third-party code in it than first-party. Having a lot of first-party code can be a sign that you’re implementing too much functionality from scratch, rather than benefitting from standard libraries to accomplish the same outcome.

30. Code bundle size/app size

For mobile and web applications, the size of your application is important. Larger bundles and app downloads can turn away certain users, cause your application to seem slow, and hurt your company’s SEO.

31. Lighthouse score

Google’s Lighthouse score is a useful way to measure the performance, accessibility, usability, and overall quality of your web application. Lighthouse is also a key metric used in determining search ranking (SEO).

32. Service availability (%)

Downtime is expensive and unnecessary in 2021. With modern DevOps tools and infrastructure, it is possible to continuously roll out changes with little to no downtime.

33. Average per-user service cost to deliver your app to customers.

This KPI includes server costs, costs of third-party APIs and services, as well as anything tied to delivering your software. This metric is valuable in helping your team understand the unit economics around the software you offer.

34. Frequency of merge conflicts

Merge conflicts occur for one of three reasons. The first happens when two developers are working on exactly the same code simultaneously, and they end up creating conflicting code. While it is generally a good practice to not have two developers working on the same exact code in parallel, this issue can arise when two developers are pair programming on two separate computers and then one of them tries to push their changes.

Another reason for merge conflicts is slow merge cycles. If pull requests stay open for a long time, it is possible for old code changes to conflict with recent updates.

A third reason is a lack of discipline around pulling down code and communicating changes with other developers.

Given that merge conflicts are time-consuming and error-prone to resolve, engineering managers should work to mitigate scenarios where merge conflicts regularly occur.

35. Percentage of code that is documented

Documentation is an important step to increasing code maintainability and improving collaboration in a software development team. There are a number of tools used for generating documentation based on in-line comments on classes, methods, and functions.

That said, documentation should focus on the non-obvious aspects of a program. Architectural decisions, application interfaces, and components consumed by others are good candidates for documentation. At the same time, developers should focus on writing self-documenting code for the inner workings of a program.

36. Number of tests cases

Testability is critical in modern software development. Although test cases should be thorough and comprehensive, there is no general rule about the number that should be written. Managers should pay careful attention to projects that have an abnormally low number of test cases.

37. Frequency or total number of user-facing bugs and crashes

Not all bugs are created equal. Bugs and crashes that impact the user experience, especially those that cause the user to lose progress or data, require particular attention.

A high frequency of user-facing bugs is typically a sign of poor QA testing prior to shipping code.

38. Number of deployments per sprint

The approach your team takes to deploying code should align with the frequency that you release code. For teams that follow the “continuous deployment” model, multiple deployments should be made every sprint. Other teams release code less frequently, sometimes as infrequently as once every sprint.

Teams that deploy code less often than once per sprint needs to reassess whether they’re truly agile. Simply having cycles called “sprints” does not make your team agile. Agile development compresses the software development lifecycle into a single sprint by reducing scope, which means they go through each stage during a single sprint, including deployments.

39. Cyclomatic complexity

From Wikipedia: “Cyclomatic complexity is a software metric used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program’s source code.”

The more complexity your projects have, the harder they become to maintain. Hard to maintain code drastically impairs velocity and makes it difficult for your team to implement important changes.

40. Open pull requests

Code review is an important part of modern software development. As such, before code is merged into a project, it should be reviewed by other developers.

As such, managers should ensure pull requests are quickly reviewed by other developers, in order to prevent delays in merging code (which prevents merge conflicts) and deploying changes.

41. Number of WIP pull requests

A high number of these types of pull requests indicate that a developer is being pulled into too many directions or does not finish a task before starting a new one.

Often include terms like “WIP”, “Draft”, or “DO NOT MERGE” in their title.

42. Percentage of stories that address technical debt

Technical debt is inevitable in software development. Left unmanaged, technical debt can dramatically slow down a project, cause performance issues with an app, and introduce bugs. Teams should allocate some time per week to “pay down” technical debt.

43. Average time spent per sprint on technical debt tasks

While it’s good to address technical debt, it’s important to understand the volume of technical debt work that’s occurring. I generally recommend engineering managers allow their team to spend as much time addressing technical debt related to the work they’re doing (i.e. by refactoring code that they’re adding new features to, if there’s considerable technical debt).

This KPI is particularly relevant when looked at over a period of time. There should generally be a flat or positive rate of change (that is, there should be less technical debt over time).

44. Commit size

One common mistake inexperienced developers make is infrequently committing code. This usually manifests itself in few, very large code commits. Large code commits are often a reflection of the mindset a developer takes towards committing code.

Sloppy developers write commit messages right before they push their changes to their branch, which includes all of the changes that they’ve made to that point. They see the purpose of committing code being primarily so they can share their work with other developers.

Savvy developers write commit messages to document their changes and provide clarity about what they changed. They write smaller commits that can easily be reversed and audited. They also end up writing better commit messages because their small code changes yield excellent commit messages

45. Average size of a pull request (in terms of commits)

When a developer commits code frequently and meaningfully, the number of commits in a pull request can be a valuable metric for understanding the logical complexity of a change.

Since each commit should reflect a single, meaningful change (with a message like “add index for displaying all KPIs on a team”) this can be a useful way to sort high complexity pull requests from lower complexity ones.

New features and major refactors should have a higher number of commits than a bug fix. If a bug fix has a lot of commits (say more than 3 or 4), then it’s important to ask yourself “why are there so many changes needed to fix this problem.” Perhaps you misclassified this pull request. Or you ended up refactoring a lot of broken code. Or, maybe you have a system that requires you to commit code to test it, and your iterative testing cycle led to you writing a ton of commits.

46. Average size of a pull request (in lines of code)

Generally I don’t recommend using lines of code as a metric for measuring software teams. However, there are a few exceptions and here’s one of them:

Using lines of code to understand why a pull request has a lot of commits. If you have a lot of commits and few lines of code written, it can be a good indicator that a developer has done a lot of iteration.

47. Percentage of bugs found in QA v. in production

Only applicable if you have a formal QA process or QA team.

Bugs should be discovered prior to being released to production. If bugs are being discovered by end users in more than 10% of cases, then you should rethink your QA process.

48. Percentage of stories that are completed on-time.

If you set deadlines on specific stories (which is often advisable on deliverables promised to specific stakeholders/customers), then it’s useful to understand how many end up being delivered on time versus taking longer than initially promised.

Likewise, developers should be judged on their ability to ship code. Developers that regularly miss deadlines require more scrutiny – is the problem caused by unreasonable expectations, a perfectionist mindest, laziness, or a lack of skill?

49. Percentage of developer time spent on planning

Developers should spend at least 10% of their time planning their changes prior to writing code. It’s much easier to change a solution on paper and it regularly saves developer time having a more explicit plan in place before starting.

50. Percentage of developer time spent in meetings

Developers are paid to build software, not sit in meetings. As a general rule, developers should not spend more than 20% of their week in meetings.

51. Number of outdated third-party dependencies

Outdated third party code is a security and maintainability risk to a project. We recommend carefully watching your projects for out-of-date dependencies and working to keep them up-to-date (this can be as simple as running an update tool, like yarn update or it can take several hours if there’s a breaking change.)

52. Average age of third-party dependencies

Old third party dependencies can indicate abandoned projects. When upstream developers abandon their projects, issues can quickly become difficult to address (especially when using closed source libraries). Be sure to check when the last time each of your third party dependencies were updated.

53. Documentation update frequency

Old documentation rarely is helpful to other developers. If you have written documentation, your team should spend some time each week maintaining it.

54. Number of times main branch build fails

The main branch (often called the “master” branch) should be stable and buildable. If you regularly experience build failures on the main branch, you should re-evaluate your approach to merging in development branches. Perhaps you need more thorough testing or need to automate certain steps (such as making database schema changes).

55. Compile/build time

There’s no hard and fast rule for compile-time, but having a slow compile time (or build time, for projects that don’t get compiled) means your developers are spending more time waiting than they are producing code.

56. Average number of issues in third party libraries

One of the key metrics I look at when selecting a third-party library is the number of outstanding issues on the repository. If a project has a lot of open issues, then it can be a sign that it’s not being maintained sufficiently (and developer beware – there may indeed be dragons).

Avoid measuring these engineering KPIs

There is a difference between what you can measure and what you should measure. When it comes to software engineering teams, here are some KPIs to avoid measuring (and why).

Number of lines of code written

In the distant past, lines of code written was the only metric that was readily available to managers. Unfortunately, using lines of code as a performance metric is problematic for a number of reasons, including:

  • More code does not mean better code. Often, writing less code means overall higher code quality, fewer bugs, and better performance of the code that’s written.
  • Some lines of code can take a while (in some cases, hours) to be written. This is particularly true when a developer is integrating a feature from a library that has a lot of complexity or when they’re developing an algorithm. The amount of effort cannot be measured by the number of lines written.
  • Not all code has the same value. One line of code for one assignment does not equal one line of code in another assignment, in terms of business value created.
  • Perhaps worst of all, it’s easy to game the task of “writing more code.” Developers who are measured on how many lines of code they write can easily “sandbag” the metric with more roundabout ways of accomplishing the same outcome – often with disastrous impacts in terms of code maintainability.

Fortunately, lines of code is not the only option to measure individual developer performance. There are at least 53 alternative metrics that can be used to measure performance and velocity.

Number of hours worked

While the exact number of hours a developer can actually be productive during a day is a contentious issue, there is clearly an upper limit to the number of hours a developer can produce in a day.

A developer who is expected to be “butt-in-seat” for 8 hours per day will certainly deliver on the sitting in their chair part. But, instead of being incentivized to spend their time more efficiently, they’ll look to fill this time with less efficient work. Alas, the curse of Parkinson’s Law rears its ugly head.

What this looks like in practice is quite interesting: a time-constrained developer (that has enough autonomy to decide how to work) will step back, re-evaluate their tools and approach, and look for ways to eliminate redundancy or repetitive tasks.

For example, a developer who is building a web application using a framework like React might opt to spend a few minutes up front configuring their code editor to use preconfigured templates for the components that they’re creating, instead of spending time banging on their keyboard to produce the same template from scratch.

In fact, rewriting the same code over and over again is not only bad from an efficiency standpoint, it often produces lower quality code.

It’s much easier to build something correctly once, then reuse it, rather than having to rewrite the same thing numerous times. Instead of finding a shortcut that increases efficiency, a developer’s natural laziness and simultaneous waste of time create a need to cut corners to deliver the work on-time, rather than looking for smart ways to save time.

Time estimates

Writing code is often a chaotic process without a lot of upfront certainty. While estimation is a good skill to have, time-based estimates are problematic because there are so many variables at play deciding the time it takes for a project to be completed.

As a developer, I’ve encountered many times when I’ve gone to make a quick change only to discover that I really should refactor a poorly written component. Sure, it takes more time – and I could have accomplished the same task without rewriting the bad code – but it perpetuates existing technical debt in my project.

Any KPI that focuses on measuring outputs, rather than proven processes, code, or outcomes

It can be tempting to measure developers at a myopic level – focusing on what they produce day-by-day – especially when you’re non-technical. It can feel comforting to ascribe a number to the developer’s outputs, especially when they’re working on long-tail assignments that take weeks and months to deliver.

Unfortunately, this temptation is counterproductive. Measuring output is akin to micromanagement – it is frustrating, time-consuming, and oftentimes creates exactly the outcome it intends to avoid. Given how expensive and difficult to hire developers are, it’s critical that the metrics you use focus on what they produce rather than how much effort it takes to produce it.

After all, one of the main reasons “software is eating the world” is that businesses in every industry can leverage software to create economies of scale.

Looking for a tool to manage your software development KPIs?

Minsilo is designed to help software managers set goals and manage their team’s KPIs. It integrates with many common development tools, allowing you to gain visibility into the work your engineering team is doing (without having to nag your developers for a status report). You can learn more on our website.