What software development KPIs should you track?

The exact software development KPIs you should track depend on your engineering organization’s current bottlenecks and priorities. Right now, the biggest question on everyone’s mind seems to be what return they’re getting on their AI tools, which you can measure with a combination of KPIs covering delivery speed, quality, and cost.

The combination of KPIs most engineering leaders land on includes metrics that show how quickly work reaches customers, whether it holds up in production, and whether it goes to the right priorities: the five DORA metrics, time to deploy, throughput per FTE, engineering investment balance, AI adoption and cost, and developer experience. A software development KPI (also called an engineering KPI) is a metric with a target, an owner, and a business question attached, and everything else your tools measure is a diagnostic you check when a KPI moves.

The key software development KPIs are:

• Change lead time
• Deployment frequency and time to deploy
• Change failure rate and deployment rework rate
• Failed deployment recovery time
• Throughput per FTE
• Engineering investment balance
• AI adoption and cost
• Developer experience

As Swarmia’s Build framework puts it, individual engineers can see 10x gains from AI while the company around them struggles to reach 10%, so the KPIs that matter now cover the whole system, not just the coding step. Set every one of them at the team level or above, because KPIs aimed at individual engineers get gamed and the biggest levers are at the system and organization levels.

Change lead time

Change lead time is how long a change takes to go from its first commit to running in production, and it’s the best single check on whether AI speed reaches users. Track it per team and across the organization over time.

Swarmia’s benchmarks put great at under 24 hours and good at under five working days, with anything slower needing attention. The VP of Engineering owns the trend across the organization, and each team owns its own number.

When AI tools cut coding time but lead time doesn’t move, the bottleneck has shifted to review, testing, or deployment. That’s where time to first review and batch size are useful: as diagnostics that explain why lead time moved, not as KPIs of their own.

Deployment frequency and time to deploy

Deployment frequency is how often a team releases code to production, and it shows whether delivery keeps pace with the extra code AI produces. If deploys don’t happen more often as output grows, changes pile up into bigger, riskier releases.

Swarmia’s benchmarks count 10 or more deploys a week as great, 5 or more as good, and fewer than 5 as needing attention. Each product team owns its number, with support from the platform team.

Time to deploy is how long a merged change takes to reach production, and it’s the first thing to check when frequency stalls. Great is under 15 minutes and good is under 60. The platform team owns it: a slow pipeline caps how often anyone can ship, and it’s usually the part of delivery they can fix fastest.

Change failure rate and deployment rework rate

Change failure rate is the share of deployments that cause a production failure needing a rollback or hotfix. Deployment rework rate, which DORA added in 2024, is the share of deployments that are unplanned fixes for production incidents. Together they’re where AI-era quality problems show up first.

DORA’s 2024 research linked a 25% rise in AI adoption to an estimated 7.2% drop in delivery stability, and its 2025 report still linked AI adoption to more instability, even as throughput improved. Swarmia’s benchmarks put a great change failure rate under 5% and a good one under 15%. DORA hasn’t published a target for rework rate, so judge it against your own trend.

Each team owns these numbers, with SRE or platform support. If either one climbs after an AI rollout, check batch size and test coverage first, the basics DORA points to when explaining the stability drop.

Failed deployment recovery time

Failed deployment recovery time is how long it takes to restore service after a deployment fails, which is how long users feel a bad release. DORA renamed it from mean time to recovery (MTTR) in 2023, and many tools still use the older name.

Swarmia’s benchmarks put great at under one hour and good at under three hours. The team that owns the service owns this number, with on-call or SRE support.

AI can draft a fix in minutes, but recovery still depends on how fast you notice the failure and how cleanly you can roll back. Small, frequent deploys help here too, since DORA notes that smaller changes are easier to recover from.

Throughput per FTE

Throughput per FTE is the work a team completes in a period, counted as both completed issues and merged pull requests, divided by its average active full-time equivalent (FTE) engineers. It’s the most direct answer to a question leaders ask about AI: is the same team finishing more work?

Read the two counts together. AI makes pull requests cheap to open, so PR throughput can climb while issue throughput stays flat. That’s why Swarmia’s Build framework treats throughput as one combined measure, even though it’s built from two counts.

There’s no published benchmark, because issue sizes vary between teams and there’s no standard size for a pull request. Compare each team with its own baseline. Read it next to change failure rate and investment balance, so more finished work doesn’t hide more bugs or more upkeep. The VP of Engineering owns the trend.

Engineering investment balance

Engineering investment balance is how engineering effort splits across new things, improving things, productivity, and keeping the lights on (KTLO). It’s the KPI that tells the board whether the time AI saves goes into growing the product. Calculate each category as its share of total engineering effort.

In the Balance Framework, great is about 10% KTLO and 15% productivity, with around 60% on new and improving things. Good is about 30% KTLO and 10% productivity, while 50% KTLO or productivity under 10% needs attention. The CTO or VP of Engineering owns it, and tools like Swarmia’s investment balance calculate it from engineering activity instead of timesheets.

Watch KTLO after an AI rollout. More code shipped is more code to maintain, and a rising KTLO share means the speed is turning into upkeep. The share can move the other way too: Learnship spent 25% less time on maintenance work after implementing Swarmia.

AI adoption and cost

AI adoption and cost tracks how deeply teams use AI tools and what that costs, per tool and per team. Adoption is the share of engineers active weekly and daily, plus the share of merged pull requests where AI contributed. Cost is AI spend per FTE per month.

The spread between organizations is wide. Swarmia’s Build framework reports that AI contributed to 82% of merged PRs at the 75th percentile of organizations and 90% at the 90th in Q2 2026, and that the top decile spends five times more per engineer on AI than a typical organization. Neither number proves value, so read both next to change lead time and change failure rate.

The VP of Engineering owns this KPI, usually together with finance. Swarmia’s AI adoption and cost view brings usage and spend from tools like GitHub Copilot, Cursor, and Claude Code into one place. Report it at the team level. Per-person data helps reclaim unused licenses and spot cost outliers, not rank engineers.

Developer experience

Developer experience is how engineers rate the conditions they work in, measured with a regular survey, and it catches what system metrics miss.

Developer experience matters more as AI writes more of the code. System data shows how much code ships, not whether engineers trust it or spend their days cleaning it up. So ask directly whether AI tools make work easier or just move it into review.

There’s no published benchmark, so compare each team with its own previous rounds and start with the lowest-scoring questions. The VP of Engineering owns the program, and engineering managers act on their teams’ results. Swarmia’s developer experience surveys, for example, put survey answers next to system metrics for the same team.

Measure what matters in an agentic organization

Swarmia’s Build framework lays out the metrics, benchmarks, and practices for getting real returns from AI across the whole software organization.

Read the Build framework