Software development KPIs and metrics that actually matter

DORA metrics and the SPACE framework, paired with code quality indicators like technical debt ratio, give a fuller picture of delivery speed, stability, and team health. This guide breaks down which KPIs to adopt, which to retire, and how to roll them out without triggering Goodhart's Law.

The short answer: Which software development KPIs to track

DORA metrics and the SPACE framework, used together, give the clearest read on software delivery health. Track deployment frequency, lead time for changes, change failure rate, and mean time to recovery as your core four, then layer in developer experience signals from SPACE to catch what DORA alone misses.

If your teams also maintain a component library, tracking metrics for design systems can reveal similar gaps between perceived and actual delivery health.

In our work auditing codebases and delivery pipelines, we've watched teams drop story points in favor of cycle time and mean time to recovery, and seen sprint conversations shift from estimation debates to actual bottleneck fixes. According to Google Cloud's DORA State of DevOps Report, elite performers deploy on demand, multiple times a day, and restore service in less than one hour.

Most mid-market teams haven't closed that gap. The rest of this guide covers each metric's formula, where code coverage fits, and how to avoid Goodhart's Law once a metric turns into a target. Some of these same teams are restructuring further, shifting from large scrum teams to smaller AI-driven delivery pods to close that gap faster.

KPIs vs. Metrics: Why the distinction matters for engineering teams

A metric is any number pulled off a dashboard: commits per day, story points closed, lines of code shipped. A KPI is a metric tied to a target that changes a decision. That distinction decides whether an engineering team's time tracking KPIs is worth the effort or just theater.

DORA metrics earn KPI status because Google Cloud maps each one to a performance tier, so a number like cycle time becomes a decision trigger, not trivia. Elite performers: multiple deployments daily; High: daily to weekly; Medium: weekly to monthly; Low: monthly or less (DORA State of DevOps Report 2024)

Leading and lagging matters more than the label. Cycle time is a leading indicator: it moves before a release ships and predicts whether lead time and deployment frequency will slip. Change failure rate and mean time to recovery are lagging, they tell you what already went wrong.

Goodhart's Law is the real reason this distinction matters for engineering. Once a metric becomes a target, a team optimizes for the metric, not the outcome it was meant to represent. We've watched story points do exactly this: once tied to a sprint commitment, estimates inflate and velocity stops measuring anything real about software delivery.

Engineering analytics platforms like Cortex or LinearB automate DORA and SPACE collection, but the platform doesn't fix a badly chosen KPI. Netguru's engagements typically start by auditing which numbers a team already tracks and killing the ones nobody acts on before adding new dashboards.

The DORA metrics framework explained

The DORA metrics framework, published annually in the State of DevOps Report by Google Cloud, measures software delivery performance with four numbers: deployment frequency, lead time for changes, change failure rate, and mean time to recovery. Each maps to a performance tier so a team benchmarks itself against thousands of others, not just its own history.

For large-scale software delivery efforts, these benchmarks matter even more, since coordinating deployment cadence and recovery times across many teams and systems is central to enterprise software development.

According to DORA's research, elite performers deploy code multiple times per day and restore service in under an hour, a threshold most mid-market software engineering teams miss by a wide margin. That gap often reflects broader software development industry challenges that make elite-level performance difficult to sustain, even for well-resourced teams.

Deployment frequency counts how often a team ships to production. Lead time for changes measures time from commit to production, exposing code review and release-approval bottlenecks that story points never surface. Change failure rate is the percentage of deployments causing an incident, rollback, or hotfix.

Mean time to recovery follows a simple formula: MTTR = total recovery time / number of incidents. A team that spends 40 minutes restoring service across five incidents in a quarter runs an MTTR of 8 min, a number that tells a CTO more about incident response maturity than any single metric drawn from sprint velocity (Atlassian incident management metrics + TaskCall).

We've seen teams treat these four metrics as a scoreboard instead of a diagnostic. That's where Goodhart's Law bites. Optimize deployment frequency alone and engineers start shipping trivial commits to inflate the count, while change failure rate climbs quietly in the background. The fix is reviewing all four together, on a fixed cadence, against a baseline set before the first sprint rather than after.

DORA metrics work because they measure outcomes, not activity. Code quality and product stability show up in change failure rate and MTTR; throughput shows up in deployment frequency and lead time. Engineering intelligence platforms like Cortex or LinearB now pull these numbers directly from CI/CD pipelines instead of manual entry, which removes most of the reporting overhead teams used to spend a full day on each sprint.

Read together, the four numbers separate teams that ship fast from teams that ship fast and then spend the following week firefighting. That's diagnostic power DORA metrics have and story points never did.

The SPACE framework, covered next, adds the dimension DORA metrics miss: how the work feels to the engineers doing it.

What is a Good deployment frequency benchmark?

Deployment frequency split into four tiers through DORA's 2024 State of DevOps Report, the last year the research used this classification before shifting to a more granular set of team archetypes in 2025:

Most mid-market engineering teams we work with land in the medium tier when they start tracking DORA metrics seriously, then move toward high within two to three quarters once CI/CD pipeline work and trunk-based branching land.

Deployment frequency alone is a trap. Goodhart's Law applies directly here: once a team is rated on deploy count, someone starts splitting a single feature into ten trivial merges to inflate the rate. Read frequency next to change failure rate and lead time for changes, never alone, and the gaming becomes visible fast.

An engineering analytics platform like Cortex or LinearB flags the divergence automatically, which is worth the setup time for any team past 30 engineers.

The SPACE framework: Measuring what DORA misses

The SPACE framework measures what DORA metrics were never built to capture: developer experience, collaboration quality, and flow efficiency inside the work itself. Forsgren et al. introduced it in a 2021 ACM Queue paper precisely because teams that hit elite DORA tiers were still burning out.

SPACE splits into five dimensions: Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, and Efficiency and flow. Flow efficiency asks a different question than cycle time alone: how much of a task's total duration is actual work versus wait time sitting in a queue, a review backlog, or a handoff.

A team can post a strong DORA scorecard while flow efficiency sits below 20%, which usually means the delivery pipeline is fast but the humans running it are exhausted.

This is where Goodhart's Law bites teams that track DORA in isolation. Deployment frequency rewards small, frequent commits, so engineers start splitting trivial changes to inflate the number without shipping more value. Pairing DORA with SPACE's satisfaction and activity dimensions catches that drift, because engagement and self-reported workload move in the opposite direction of a gamed metric.

In practice, we recommend layering one new SPACE-native metric alongside DORA rather than replacing it: AI-assisted PR acceptance rate, the share of AI-generated pull requests merged without major rework. It sits under Activity, and it flags whether AI tooling is genuinely reducing developer effort or just adding review load.

Engineering analytics platforms like Cortex have started surfacing SPACE dimensions alongside DORA metrics on the same dashboard, which is the direction most mature engineering orgs are heading. Read the two frameworks together on a quarterly baseline-and-review cadence, not DORA weekly and SPACE as an afterthought survey.

Cycle time vs. Lead time for changes: What's the difference

Cycle time and lead time for changes measure overlapping but distinct windows, and conflating them is the most common metrics mistake we see in engineering reviews.

Cycle time runs from first commit to production deploy. It is a team-level efficiency measure: how fast can a change move through code review, CI, and release once work has actually started.

Lead time for changes, one of the four DORA metrics, runs from commit to deploy as well, but DORA scopes it specifically as "time from commit to production" measured across the whole delivery pipeline, not just an individual's active work. In practice the numbers converge for teams with tight WIP limits and diverge sharply for teams with heavy code review backlogs or manual QA gates.

Watch for Goodhart's Law here: once a team knows cycle time is scored, commits get smaller and more frequent to game the number, without any real change in delivered value. Case in point: Spacefox delivered an internal project that improved the team's remote work process and deepened expertise in 3D environments, tool integration, and interactions.

The choice of development methodology also shapes how easily teams can game or genuinely improve these metrics, since iterative approaches naturally produce smaller, more frequent commits.

Track both alongside deployment frequency, or a fast cycle time on a low-frequency pipeline just means small batches queuing up before an infrequent release.

Incident response metrics: MTTD, MTTA, and MTTR

Mean time to detect (MTTD), mean time to acknowledge (MTTA), and mean time to recovery (MTTR) break incident response into three separate clocks, and treating them as one number hides where the team actually loses time.

MTTD = time incident occurred → time an alert fired or an engineer noticed. MTTA = time detected → time someone started working the incident. MTTR = total recovery time across all incidents ÷ number of incidents.

MTTR is one of the four core DORA metrics, alongside deployment frequency, lead time for changes, and change failure rate. According to Google Cloud's DORA State of DevOps Report, elite performers restore service in under an hour, while low performers can take a week or more, per incident.

The tradeoff CTOs miss: MTTR alone rewards fast rollbacks over root-cause fixes. A team can hit an aggressive MTTR target by reverting every incident to the last known-good build, then never touching the underlying bug. That is Goodhart's Law in practice, once MTTR becomes the target, teams optimize the number instead of the reliability it was meant to represent.

Splitting MTTD and MTTA out fixes the blind spot. A rising MTTA with flat MTTD usually means alert fatigue or unclear on-call ownership, not a code quality problem. A rising MTTD points at monitoring gaps. Engineering analytics platforms like Cortex or PagerDuty surface all three automatically from incident timestamps, which removes the manual reconstruction work most teams still do in a spreadsheet after the fact.

We recommend reviewing MTTD, MTTA, and MTTR as a set, alongside change failure rate, on a monthly cadence rather than per incident.

Code quality metrics: Coverage, defect density, and technical debt ratio

Code coverage, defect density, and technical debt ratio each catch a different failure mode, and none of them tells you whether the product actually works. Coverage tells you what's tested. Defect density tells you what's broken. Technical debt ratio tells you what it costs to keep shipping on the current codebase.

Technical debt ratio is the one most engineering leads skip, because remediation cost has to come from somewhere concrete: a SonarQube-style static analysis estimate, or an internal audit against known workarounds. A ratio climbing past 20-25% is the point where we'd flag a codebase for a dedicated remediation sprint rather than folding cleanup into normal delivery.

Coverage is also the metric most exposed to Goodhart's Law: once a team is told to hit 80%, engineers write tests that execute lines without asserting behavior, and the number goes up while defect density stays flat or worsens. We've seen this exact pattern on client codebases where coverage looked healthy and production incidents didn't move.

Pair coverage with defect density and a trend line, not a single target number, so gaming one doesn't hide regression in the other.

Most engineering analytics platforms, including Cortex and similar internal tooling, surface these three side by side per repository. That view matters more than any individual read: a team with 90% coverage and rising defect density is in worse shape than one at 70% and flat, and only tracking both numbers together in your KPIs review shows you which team that is.

What is the technical debt ratio formula?

Technical debt ratio measures the cost of fixing known code problems against the cost of building the code in the first place: TDR = (Remediation cost / Development cost) × 100 (Alexander Jarvis / SaaS Technical Debt Ratio). Static analysis tools like SonarQube estimate remediation cost in engineering hours, then convert both sides to dollars using a standard hourly rate.

Worked example: a service took 800 developer-hours to build. SonarQube flags 40 hours of remediation work (duplicated logic, missing null checks, cyclomatic complexity over threshold). At a shared hourly rate, TDR = (40/800) × 100 = 5%.

SonarQube maintainability ratings: A (0-5% technical debt ratio) is healthy; D (21-50%) and E (>50%) are poor (SonarQube Technical Debt Ratio Explained (with 2026)

Watch for Goodhart's Law here: once technical debt ratio becomes a KPIs target, teams under time pressure pad development-cost estimates or suppress remediation flags rather than fix the code. Pair it with defect density and a manual code review sample, and review the ratio on the same cadence as your other engineering metrics, not in isolation.

Developer experience and eNPS: The human side of Delivery metrics

Developer experience is the leading indicator DORA metrics miss, and employee net promoter score (eNPS) is the cleanest way to track it. Ask one question quarterly, "how likely are you to recommend this team to a peer?" on a 0-10 scale, and calculate eNPS as % promoters minus % detractors.

We've watched eNPS drop two quarters before attrition spiked on client engineering teams, well before exit interviews surfaced the real complaint: broken build pipelines, unclear ownership, or a backlog nobody trusted. Deployment frequency and cycle time stayed flat the whole time. That's the gap the SPACE framework was built to close, it treats satisfaction as a first-class engineering metric, not an HR side note.

Watch for Goodhart's Law here. The moment a team's manager reads eNPS as a rate, developers learn to game the survey rather than report honestly, and the metric stops meaning anything. Pair it with a harder signal: AI-assisted PR acceptance rate, which tells you whether Copilot- or Cursor-generated code is actually landing in production or getting rewritten by hand.

According to Stack Overflow Developer Survey, 75% of developers describe themselves as 'complacent' or 'not happy at work' (Stack Overflow Developer Survey 2025)

Run eNPS alongside your core DORA metrics, deployment frequency, lead time for changes, change failure rate, mean time to recovery, on the same quarterly cadence, with a fixed baseline and review date on the calendar. Platforms like Cortex or LinearB surface both sets on one dashboard, so a dip in developer experience shows up next to the delivery numbers it's about to affect, not three sprints later.

How to measure developer productivity without lines of code

Lines of code measures typing speed, not developer productivity. The SPACE framework from Forsgren et al. replaces that vanity metric with five dimensions: satisfaction, performance, activity, communication, and efficiency, and two of its most actionable proxies are pull request turnaround time and sprint burndown shape.

Pull request turnaround time, measured from open to merge, exposes review bottlenecks that story points hide entirely. A team stuck at 48+ hours median turnaround is usually blocked on reviewer bandwidth, not coding speed.

Sprint burndown tells a different story: a chart that flatlines mid-sprint and cliffs on the last day signals scope creep or last-minute integration risk, regardless of whether the team "delivered" its committed points.

Watch for Goodhart's Law here. The moment PR turnaround becomes a target reviewers game it, rubber-stamping to hit the number, which is worse than the problem it replaced. We treat it as a diagnostic signal reviewed alongside cycle time, not a performance target tied to individual engineers.

One pattern worth tracking as AI coding assistants spread through teams: AI-assisted PR acceptance rate, the share of AI-generated suggestions merged without substantial rework, gives an early read on whether tooling adoption is improving developer experience or just adding review overhead. In a joint study of roughly 450 Accenture developers, GitHub Copilot use correlated with a 15% increase in pull request merge rate and an 84% increase in successful builds, evidence that the extra throughput wasn't just noise clearing review (GitHub and Accenture research).

Software development metrics to avoid (and why they get gamed)

Story points, lines of code, and utilization rate share one flaw: each rewards the appearance of work, not the outcome. Goodhart's Law explains why, once a measure becomes a target, a team optimizes for the number instead of the goal it stood in for.

Story points are the clearest case. We've seen teams inflate estimates once velocity gets tied to a performance review, and the sprint burndown starts looking clean while ticket age quietly creeps upward. A burndown that flatlines early isn't proof of a healthy team, it's often proof the tickets were sized to finish on schedule, not sized to reflect the work.

Lines of code fails the same test in reverse: it rewards verbosity, so engineers who know LOC is being watched write more code, not better code. Utilization rate does the opposite kind of damage. Packing a team's calendar to hit a target utilization number leaves no slack for code review, mentoring, or incident response, the exact gap the SPACE framework's activity and efficiency dimensions were built to expose.

Every metric in the table above shares the same failure mode once it's tied to an individual's performance review rather than a team's delivery health. Read that as a warning: any single metric a team is graded on will eventually get optimized in isolation. Pair story points or utilization with a DORA metric and review the pairing quarterly, not the raw number alone.

How AI coding assistants are changing velocity metrics

AI coding assistants compress cycle time on the coding step, then quietly shift the bottleneck to review. GitHub Copilot and similar tools cut time spent writing boilerplate, but pull requests now arrive faster than reviewers can validate them.

This is still an emerging area. Public research hasn't caught up with adoption, so it's worth treating bold productivity claims, including some of ours, as provisional rather than settled fact.

Most teams we work with are missing a metric here: AI-assisted PR acceptance rate, the share of AI-generated suggestions that survive review unmodified. It's a gap that KPIs software and metrics dashboards rarely track, and it exposes a tradeoff plain cycle time hides.

According to GitHub's 2024 Octoverse report, developers using Copilot merged pull requests at a notably higher rate than non-users. That looks like a velocity win until code coverage is checked against it, and until someone asks whether the business or the customer actually noticed a difference.

We've seen coverage dip on AI-heavy codebases when tests get generated as an afterthought rather than a spec. The fix isn't banning the tools.

It's pairing cycle time with coverage on the same dashboard, so a team can't claim speed without also showing the tests hold. Until more industry data exists, verify any AI velocity gain against your own numbers before you repeat it to leadership. Track both, and the AI productivity story becomes verifiable instead of anecdotal.

Rolling out engineering KPIs step by step

Rolling out engineering KPIs works in four stages: baseline, select, instrument, review. Skip a stage and the numbers turn into ammunition instead of signal.

1. Baseline before you name a target. Pull two to three months of historical data for deployment frequency, lead time for changes, change failure rate, and mean time to recovery before anyone sets a goal. A target with no baseline invites gaming, not improvement.

2. Pick DORA metrics for delivery, SPACE for the rest. DORA metrics give you the four throughput-and-stability numbers above. The SPACE framework (Forsgren et al., Microsoft Research / ACM Queue) adds satisfaction, activity, communication, and efficiency, so a team's developer experience and cycle time show up alongside deployment frequency rather than getting inferred from it.

3. Instrument once, review often. Wire the metrics into one dashboard, Cortex, LinearB, or a similar engineering-intelligence tool, rather than five spreadsheets nobody trusts. Run a weekly team-level check on cycle time and change failure rate, and a monthly leadership review that pairs DORA numbers with SPACE survey results and code coverage trends. Treat this dashboard as one piece of your broader engineering best practices, not a substitute for them.

4. Watch for Goodhart's Law. Any metric a team is evaluated on gets optimized, sometimes at the expense of the thing it was meant to protect. We've seen teams chase deployment frequency by splitting trivial commits, which is why we now track AI-assisted PR acceptance rate alongside lead time once Copilot-style tools enter a workflow, it catches throughput gains that reviewers quietly reject.

According to the State of DevOps Report, elite performers deploy on demand, multiple times a day, and restore service in under an hour after an incident.

FAQ: Software development KPIs and metrics

Get an engineering metrics audit from Netguru

Most engineering teams tracking DORA metrics for the first time find their real baseline is worse than the story leadership was telling itself. That gap between assumed and actual deployment frequency, lead time, and change failure rate is the starting point for any KPI program worth running.

An engineering metrics audit from Netguru maps your current setup against DORA metrics and the SPACE framework, flags vanity metrics that reward the wrong behavior, and sets a baseline your team can actually review on a monthly cadence. We've done this across client codebases spanning web, mobile, and backend teams.

Case in point: Otodom's saved-search subscription rate grew 116% after a similar metrics reset. Once the audit sets a reliable baseline, ongoing software maintenance support helps keep those metrics healthy as your codebase evolves.

If your KPIs and metrics program needs a working set of instruments rather than a slide, get an estimate for your project and we'll scope the audit alongside it. If quality gaps are skewing your change failure rate and recovery times, our team can also strengthen your quality assurance process alongside the metrics rollout.