Software Development KPIs: 20 Metrics for Speed, Quality and Outsourced Teams
28/07/2023
2.58k
Software development KPIs are the small set of numbers a team uses to see whether it ships useful software quickly, safely and at a sustainable cost. The most reliable starting point is the five DORA delivery metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. Add a few quality and flow measures (escaped defects, cycle time, work in progress), one or two outcome measures (adoption, app rating, support tickets) and, if you work with an outsourced team, contract health measures such as SLA compliance and predictability. Track trends per product, never rank individual developers, and keep the list short enough to discuss in one meeting.
What are software development KPIs?
A key performance indicator (KPI) is a metric that a team has agreed to manage against because it reflects a goal the business cares about. Every KPI is a metric, but most metrics should not be KPIs.
In software development, good KPIs answer four questions:
- Are we fast? How long does it take a change to reach users, and how often do we release?
- Are we stable? How often do releases break things, and how quickly do we recover?
- Is the work good? How many defects escape to production, and is the codebase getting easier or harder to change?
- Does it matter? Are users adopting what we ship, and is the product moving business results?
The cost of not answering these questions is large. The Consortium for Information and Software Quality estimated that the cost of poor software quality in the United States had grown to at least $2.41 trillion in 2022, with accumulated technical debt of about $1.52 trillion. Most of that cost is invisible until something fails. KPIs make it visible early, while it is still cheap to fix.
KPIs versus metrics versus OKRs
| Term | What it is | Example | Who uses it |
|---|---|---|---|
| Metric | Any measurable value | Number of pull requests merged this week | Engineers, tooling |
| KPI | A metric the team manages against over time | Change lead time, tracked monthly | Team leads, product owners, clients |
| OKR | A time-bound objective with measurable key results | “Release weekly by Q2” with lead time under 3 days as a key result | Leadership, product teams |
| SLA | A contractual commitment with consequences | Critical bugs acknowledged within 1 hour | Client and vendor |
The distinction matters most in outsourcing. An SLA is something you can enforce; a KPI is something you improve together. If you turn every KPI into an SLA with penalties, the vendor will optimize for the contract rather than for your product.
The frameworks behind the best KPIs: DORA, SPACE and flow
You do not need to invent a measurement system. Three frameworks cover most of what a software organization needs, and they work best together.
DORA: the delivery performance core
DORA (DevOps Research and Assessment) has studied software delivery for more than a decade. Its metrics guide now defines five measures in two groups. Throughput covers change lead time (“the amount of time it takes for a change to go from committed to version control to deployed in production”), deployment frequency and failed deployment recovery time. Instability covers change fail rate and deployment rework rate, the ratio of deployments that are unplanned and happen because of an incident in production.
The set has evolved. According to DORA’s history of the metrics, mean time to recover was redefined in 2023 as failed deployment recovery time so that it covers only failures caused by a change, and deployment rework rate was added in 2024 as the fifth metric. If your dashboard still says “MTTR” and “four keys”, it is worth updating the definitions so you can compare your numbers with current research.
SPACE: the human side
The SPACE framework, published by researchers from GitHub, Microsoft and the University of Victoria, argues that productivity cannot be captured by one number. It covers Satisfaction and well-being, Performance, Activity, Communication and collaboration, and Efficiency and flow. Its practical lesson is to combine at least three of those dimensions and to include perception data from surveys, not just system data from tools.
Flow metrics: where work waits
Flow metrics come from Lean and Kanban. They describe the movement of work items (features, bugs, tasks) through your process: cycle time, throughput, work in progress and flow efficiency. They are especially useful before code is written, where DORA’s commit-to-production view does not reach. A feature that waits three weeks for a requirement decision has a perfect change lead time and a terrible customer lead time.
| Framework | Answers | Typical data source | Blind spot |
|---|---|---|---|
| DORA | How fast and safely do changes reach production? | Version control, CI/CD, incident tool | Work before the first commit; business value |
| SPACE | Is the team healthy and effective? | Surveys plus system data | Harder to automate; needs trust |
| Flow | Where does work wait? | Issue tracker (Jira, Backlog, Linear) | Depends on clean ticket hygiene |
| Outcome metrics | Does the software change user or business behavior? | Product analytics, app stores, CRM | Slow feedback; many causes besides engineering |
Software development KPIs for speed and delivery
These KPIs show how quickly value moves from an idea to users. Track them per product or service, as monthly medians, and look at the trend rather than a single month.
1. Change lead time
Definition: Time from a commit to that change running in production.
How to calculate: For each deployment, subtract the earliest commit timestamp from the deploy timestamp; report the median.
Why it matters: Long lead times mean large batches, slow reviews or manual release steps, all of which increase risk.
Watch out for: Teams can shorten lead time by committing later. Pair it with cycle time.
2. Deployment frequency
Definition: How often the team successfully deploys to production.
How to calculate: Count production deployments per week or month; for mobile apps, count store releases and server deployments separately.
Why it matters: Frequent small releases are easier to test and roll back.
Watch out for: Mobile apps face store review and user update cycles, so “on demand” is not a realistic target. A monthly app release with immediate hotfixes can be excellent for a consumer app.
3. Cycle time
Definition: Time from when work on an item starts (status “In progress”) to when it is done (released or accepted).
How to calculate: Done date minus start date, per item type; report the median and the 85th percentile.
Why it matters: It captures the waiting that DORA does not see: requirement questions, design approval, test environment queues.
Watch out for: Splitting tickets artificially. Compare items of similar size or type.
4. Customer lead time (idea to release)
Definition: Time from when a request is accepted into the backlog to when it is in users’ hands.
Why it matters: This is the number your business stakeholders feel. In outsourced projects, it often reveals that the slowest step is on the client side: decisions, content, approvals.
5. Flow efficiency
Definition: Share of cycle time when someone is actively working on an item.
How to calculate: Active time divided by total cycle time, multiplied by 100.
Why it matters: Low flow efficiency means the bottleneck is handoffs and queues, not engineering speed. Hiring more developers will not fix it.
6. Predictability (say/do ratio)
Definition: Share of committed sprint or milestone scope that is delivered as planned.
How to calculate: Delivered committed items divided by committed items at sprint start.
Why it matters: For clients planning marketing campaigns or store launches, predictability can matter more than raw speed.
Watch out for: Teams can hit 100% by committing to very little. Read it together with throughput.
Software development KPIs for quality and stability
Speed without quality is the most common failure pattern in metric programs. Every team that tracks speed should track at least two of the following.
7. Change fail rate
Definition: Share of deployments that require immediate intervention (hotfix, rollback, patch) after release.
How to calculate: Failed deployments divided by total deployments in the period.
Why it matters: It is the counterweight to deployment frequency.
8. Deployment rework rate
Definition: Share of deployments that are unplanned and happen because of an incident in production.
Why it matters: A high rework rate means the team is spending its release capacity on fixing yesterday’s changes instead of shipping new value.
9. Failed deployment recovery time
Definition: Time from a failed deployment being detected to service being restored.
Why it matters: No team avoids every failure. Fast recovery (feature flags, automated rollback, good monitoring) limits the damage.
10. Escaped defects and defect density
Definition: Escaped defects are bugs found in production rather than in testing. Defect density is defects per unit of size (per 1,000 lines of code, per feature or per story point).
How to calculate: Production bugs in the period, grouped by severity; or defects divided by size unit.
Why it matters: Escaped defects are what users experience. Severity weighting matters: one payment failure outweighs twenty typos.
11. Defect removal efficiency
Definition: Share of all defects found before release.
How to calculate: Defects found before release divided by (defects found before release plus defects found in production in the following 30 or 90 days).
Why it matters: It measures how well your testing and review catch problems, independent of how many bugs the code had to begin with.
12. Test coverage of critical paths
Definition: Share of code, or better, of critical user journeys (sign up, checkout, payment), covered by automated tests.
Why it matters: Coverage is a weak target on its own; teams can write tests that execute code without checking anything. Coverage of the journeys that make money is a much better signal.
13. Mean time between failures and availability
Definition: Average time between production incidents, and the share of time the service is available against its service level objective (SLO).
Why it matters: These are the reliability numbers your users and your SLA care about.
14. Technical debt ratio
Definition: Share of engineering capacity spent on maintenance, rework and debt rather than new features, or a static analysis estimate of remediation effort compared with development effort.
Why it matters: When this ratio climbs quarter after quarter, delivery will slow no matter how hard the team works. It is the early warning for the $1.52 trillion problem CISQ describes.
KPIs for product outcomes and developer experience
Delivery and quality metrics tell you whether the machine runs well. Outcome and experience metrics tell you whether it is building the right thing and whether it can keep running.
15. Feature adoption rate
Definition: Share of active users who use a new feature within a set time after release.
Why it matters: It closes the loop between engineering output and user value. A team that ships fast but sees low adoption has a discovery problem, not a delivery problem.
16. Customer satisfaction signals
Definition: App store rating, CSAT or NPS, and the volume of support tickets caused by defects.
Why it matters: For consumer apps, the store rating is a public KPI that affects downloads. It responds to stability and to how quickly reported bugs are fixed.
17. Developer satisfaction and friction
Definition: Survey-based score on tools, process and focus time, plus specific friction questions (“How often do slow builds block you?”).
Why it matters: SPACE research and common sense agree: unhappy, interrupted teams do not sustain good delivery. In outsourced teams, a low score is often the first signal of attrition risk.
Software development KPIs for outsourced and offshore teams
When you work with an external partner, you need everything above plus a third layer: KPIs that describe the health of the engagement itself. This matters more each year. Deloitte’s 2024 Global Outsourcing Survey of more than 500 executives found that 83% are leveraging AI as part of their outsourced services, and that skilled talent and agility now join cost reduction as key drivers for outsourcing. When clients buy talent and agility, they need ways to measure them, not just the invoice.
18. SLA compliance
Definition: Share of tickets handled within the agreed response and resolution times, by severity.
Example targets to agree: Critical issues acknowledged within 1 hour in business hours, high within 4 hours. Set the numbers together; the point is to make them explicit.
Watch out for: Response time without resolution time. A fast “we are looking into it” is not a fix.
19. Defect rejection rate (acceptance rate)
Definition: Share of delivered items that the client rejects in acceptance testing, or the share of bug reports the vendor rejects as “not a bug”.
Why it matters: A high rate in either direction points to unclear acceptance criteria. It is one of the clearest early signals that requirements are being lost between client and team.
20. Knowledge coverage and continuity
Definition: Share of critical modules that at least two team members can work on, plus documentation freshness and team turnover in the period.
Why it matters: The biggest hidden risk in an outsourced team is a single person who understands the payment module. This KPI makes that risk visible before that person goes on leave.
Two more measures are worth adding once the basics are stable: ramp-up time for new team members, and budget variance per milestone. Our guide to software project cost estimation explains how to set a baseline you can measure against.
Measurement is only one part of running an external team well. For the day-to-day practices (rituals, communication, governance), see our guide on how to manage offshore development teams effectively.
KPI reference table: formulas, data sources and review cadence
| KPI | Category | Formula or method | Data source | Review cadence |
|---|---|---|---|---|
| Change lead time | Speed | Median (deploy time minus first commit time) | Git, CI/CD | Monthly |
| Deployment frequency | Speed | Production deployments per week | CI/CD | Monthly |
| Cycle time | Flow | Median (done date minus start date) | Issue tracker | Every sprint |
| Flow efficiency | Flow | Active time / total cycle time x 100 | Issue tracker | Quarterly |
| Predictability | Flow | Delivered committed items / committed items | Issue tracker | Every sprint |
| Change fail rate | Stability | Failed deployments / total deployments | CI/CD, incident tool | Monthly |
| Deployment rework rate | Stability | Unplanned incident-driven deployments / total deployments | CI/CD, incident tool | Monthly |
| Failed deployment recovery time | Stability | Median (restore time minus detection time) | Incident tool, monitoring | Monthly |
| Escaped defects | Quality | Production bugs by severity per month | Bug tracker | Monthly |
| Defect removal efficiency | Quality | Pre-release defects / all defects | Bug tracker | Per release |
| Critical path test coverage | Quality | Critical journeys with automated tests / all critical journeys | Test suite | Quarterly |
| Availability | Reliability | Uptime / total time against SLO | Monitoring | Monthly |
| Technical debt ratio | Sustainability | Maintenance capacity / total capacity | Time allocation, static analysis | Quarterly |
| Feature adoption | Outcome | Users of feature / active users | Product analytics | Per release |
| App rating, CSAT | Outcome | Average rating or score | App stores, surveys | Monthly |
| Developer satisfaction | Experience | Survey score and friction items | Survey | Quarterly |
| SLA compliance | Engagement | Tickets within SLA / all tickets | Service desk | Monthly |
| Defect rejection rate | Engagement | Rejected items / delivered items | Acceptance records | Every sprint |
| Knowledge coverage | Engagement | Critical modules with 2+ capable people / critical modules | Skills matrix | Quarterly |
Metrics to avoid or handle with care
Some of the most popular numbers in software management do more harm than good when they become KPIs. Goodhart’s law applies: when a measure becomes a target, it stops being a good measure. DORA’s own guidance warns that broad mandated targets increase the likelihood that teams will try to game the metrics, and that the goal is to improve your team over time, “not to compete against other teams or organizations.”
| Metric | Why it misleads | Better alternative |
|---|---|---|
| Lines of code per developer | Rewards verbose code; deleting code is often the best work. AI assistants make it meaningless. | Throughput of delivered items; change lead time |
| Story points per person | Points are relative estimates, not output. Comparing people or teams inflates estimates. | Team predictability; cycle time |
| Velocity as a target | Teams raise velocity by re-estimating, not by delivering more. | Use velocity only for the team’s own planning |
| Hours logged | Measures presence, not progress. Encourages long days and burnout. | Flow efficiency; developer friction survey |
| Raw code coverage percentage | Easy to raise with tests that assert nothing. | Coverage of critical journeys; escaped defects |
| Number of bugs fixed | Rewards creating bugs and fixing them; hides prevention. | Escaped defects; defect removal efficiency |
The underlying rule: measure systems, not people. Use individual data only in private coaching conversations, never on a shared dashboard and never in vendor comparisons.
How AI coding tools change your KPIs
AI assistants are now part of normal development work. Google Cloud’s announcement of the 2024 DORA report states that more than 75% of respondents rely on AI for at least one daily professional responsibility. The same research found that a 25% increase in AI adoption was associated with a 7.5% increase in documentation quality, a 3.4% increase in code quality and a 3.1% increase in code review speed. It was also accompanied by an estimated 1.5% decrease in delivery throughput and an estimated 7.2% reduction in delivery stability. And 39% of respondents reported little to no trust in AI-generated code.
These are associations, not proof of cause, but they have clear consequences for your KPI set:
- Activity metrics become noise. Lines of code, commits and pull request counts rise when AI writes more code, without any guarantee of value.
- Batch size needs watching. If AI makes it easy to produce large changes, pull request size and review time can grow, which lengthens lead time and raises change fail rate.
- Stability metrics deserve more weight. Change fail rate, rework rate and escaped defects are where AI side effects show up first.
- Add AI-specific measures carefully. Share of pull requests with AI assistance, review findings on AI-generated code, and developer-reported time saved are useful context. They are not success measures on their own.
If you are planning to bring AI into your delivery process, see how we approach it on our AI-driven development services page, and agree up front which stability KPIs will tell you whether the speed gains are real.
A real example: what improved KPIs look like in an app handover
KPIs are easiest to understand in a real situation. One SupremeTech project, documented in our agile and DevOps app case study (in Japanese), involved a mobile ordering app of roughly 5 million users for a Japanese restaurant group operating more than 3,000 locations. The previous vendor’s maintenance was slow and uneven: minor changes and urgent bug fixes took a long time, accumulated technical debt made root causes hard to find, and the client’s operations staff spent their time on technical problems instead of business work.
The engagement was organized around the kinds of KPIs described above:
- Handover first: a 20-person team spent about two months on intensive handover and assessment before new development started, to establish a baseline and reduce knowledge risk.
- Cadence: strict two-week Scrum sprints with a review at each sprint end, daily meetings for quick clarification, and a path for urgent requests to go from requirement to release mid-sprint.
- Delivery: a CI/CD pipeline with code quality checks, automated tests and deployment automation, plus proactive monitoring and alerting.
- Release frequency: regular releases once a month, with urgent fixes released immediately.
The results the case study reports are outcome and stability measures, not activity counts: the app store rating rose from 3.9 to 4.2, monthly active users grew by 600,000 after the handover, and a security issue in user authentication and token verification was fixed and released within a month of starting. The client’s feedback focused on exactly what the KPIs targeted: previously slow fixes for frequent app bugs became faster, user inquiries settled down, and the team handled sudden requests flexibly.
[SupremeTech detail: which internal KPIs (for example change fail rate or bug response time) the team tracked on this project, and how they were reported to the client]
How to build a KPI scorecard in 7 steps
A scorecard is a short, stable list of KPIs, each with an owner, a baseline, a direction and a review rhythm. Here is a process that works for in-house and outsourced teams alike.
- Start from the business goal. Write one sentence: “This quarter, the product must…” (launch in a new market, cut support costs, double release frequency before a campaign). Every KPI must connect to it.
- Pick a balanced set. Choose one or two KPIs from each of speed, stability, quality, outcome and, for external teams, engagement health. Eight to twelve in total is plenty.
- Define each KPI precisely. Write the formula, the data source, what counts as “done”, “failed” or “critical”, and who owns the number. Vague definitions cause more disputes than bad numbers.
- Measure a baseline before setting targets. Collect four to eight weeks of data first. Targets set without a baseline are guesses.
- Automate collection. Pull data from Git, CI/CD, the issue tracker and monitoring. Manual spreadsheets drift and become a weekly chore.
- Review on a fixed rhythm. Sprint-level flow numbers in the sprint review, delivery and quality monthly, experience and debt quarterly.
- Act on one KPI at a time. Each review should end with one improvement experiment (“limit work in progress to 3 per developer for two sprints”) and a check on whether it moved the number.
Sample one-page scorecard for an outsourced product team
| Area | KPI | Baseline | Direction | Owner |
|---|---|---|---|---|
| Speed | Change lead time (median) | [measure 4 to 8 weeks] | Down | Tech lead |
| Speed | Deployment frequency | [measure] | Up or steady | Tech lead |
| Flow | Predictability | [measure] | Toward 80% to 90% | Project manager |
| Stability | Change fail rate | [measure] | Down | QA lead |
| Stability | Failed deployment recovery time | [measure] | Down | DevOps |
| Quality | Escaped defects (critical and high) | [measure] | Down | QA lead |
| Outcome | App rating or CSAT | [measure] | Up | Product owner (client) |
| Engagement | SLA compliance | [measure] | Up | Project manager |
| Engagement | Defect rejection rate | [measure] | Down | Business analyst |
| Sustainability | Technical debt ratio | [measure] | Stable or down | Tech lead |
The predictability band is a common working range, not a research benchmark: consistently 100% usually means the team commits too little, and below about 70% means plans are not reliable enough for the business to use.
Choosing KPIs by project stage
The right KPIs shift as a product matures.
| Stage | Primary question | Focus KPIs | De-emphasize |
|---|---|---|---|
| Discovery and MVP | Are we learning fast enough? | Customer lead time, feature adoption, cycle time | Availability SLOs, technical debt ratio |
| Growth | Can we scale delivery without breaking things? | DORA five, escaped defects, predictability | Cost per feature |
| Mature product or maintenance | Are we reliable and efficient? | Availability, recovery time, SLA compliance, technical debt ratio, app rating | Deployment frequency as a goal in itself |
| Vendor handover or team change | Is knowledge transferring safely? | Knowledge coverage, ramp-up time, escaped defects, defect rejection rate | Velocity comparisons with the previous team |
| Rebuild or migration | Are we reducing risk while keeping the business running? | Rework rate, recovery time, parity checklist completion | Feature throughput |
For building the plan these KPIs measure against, see our guide on how to plan a software project.
Running KPI reviews with an offshore team
The same numbers can build trust or destroy it, depending on how they are discussed. A few practices make KPI reviews productive across companies and countries.
Share one source of truth
Both client and vendor should see the same dashboard, generated from the same tools. If the vendor sends a monthly report built by hand, ask for access to the underlying tracker and pipeline instead. Disagreements about numbers waste the time that should go into improving them.
Agree on definitions in writing
Write a one-page KPI glossary at the start: what severity levels mean, when a ticket counts as “done”, what counts as a failed deployment. Put it in the project wiki and reference it in the contract appendix if SLAs depend on it. Our article on offshore software development services covers how engagement models and contract terms connect to these measures.
Close the requirement gap
Many KPI problems in outsourced work are really communication problems: high defect rejection, low predictability and long customer lead times often trace back to requirements that lost detail in translation. At SupremeTech, business analysts who speak Japanese join requirement meetings with Japanese clients directly, which shortens the path between what the client means and what the team builds. Da Nang is also only two hours behind Tokyo, so most review meetings and urgent questions fit inside a shared working day.
Review trends, not single points
Show at least three months of history on every chart. A single bad month after a big release is normal; three bad months in a row is a pattern worth a retrospective. End every review with one experiment, one owner and one date to check the result.
Warning signs your KPI program is not working
- Nobody can explain how a number is calculated, or two people explain it differently.
- The dashboard has more than 20 KPIs and none have changed anyone’s decisions this quarter.
- Numbers improve every month while users and stakeholders complain more.
- Developers ask how to “make the metric green” instead of how to improve the product.
- Individual names appear on charts used in management meetings.
- The vendor’s monthly report never contains a bad number.
- Stability metrics are missing entirely, or speed metrics are missing entirely.
- KPIs were set at kickoff and never revisited when the product moved from MVP to growth.
If three or more of these sound familiar, reset: cut the list to the ten KPIs in the sample scorecard, re-agree the definitions and collect a fresh baseline. Our article on common software development mistakes covers the process problems these warning signs usually point to.
Conclusion: measure what you want more of
Good software development KPIs are few, balanced and owned. Start with the DORA delivery metrics, pair speed with stability and quality, connect the set to one business goal and, if you work with an outsourced partner, add engagement health measures that surface requirement and knowledge risks early. Review trends, act on one number at a time and retire any KPI that stops changing decisions.
If you are looking for a development partner that works this way, SupremeTech’s custom software development teams in Da Nang work with Japanese and global clients on products with millions of users, under an ISO/IEC 27001 certified information security management system. Book a free consultation to discuss how we would measure success on your project.
Frequently asked questions about software development KPIs
For most teams: the five DORA metrics (change lead time, deployment frequency, failed deployment recovery time, change fail rate, deployment rework rate), escaped defects, cycle time and one outcome measure such as feature adoption or app rating. Outsourced teams should add SLA compliance and defect rejection rate.
Eight to twelve on the shared scorecard is a practical range. More than that and reviews turn into status readings. You can keep other metrics available for diagnosis without making them KPIs.
Not with shared KPIs. Individual output metrics such as lines of code or story points per person are easy to game and ignore collaboration, review and mentoring work. Measure team and system performance, and handle individual growth in private one-to-one conversations.
In DORA terms, change lead time runs from commit to production. Cycle time usually runs from when work starts on a ticket to when it is done. Customer lead time runs from when a request is accepted to when users have it. Each shows a different bottleneck, so define which one you mean in writing.
Put enforceable service levels in the contract: response and resolution times by severity, availability for systems the vendor operates, and acceptance criteria. Keep improvement KPIs such as lead time and cycle time in a shared scorecard rather than in penalty clauses, so both sides can be honest about problems.
Flow measures every sprint, delivery and quality measures monthly, and developer experience, technical debt and the KPI set itself quarterly. Always look at trends over at least three months before drawing conclusions.
No. They make stability metrics more important. DORA’s 2024 research associated higher AI adoption with small drops in throughput and larger drops in stability, so change fail rate and rework rate are the best early warning that AI-generated code is causing problems.
Pick four: deployment frequency, change lead time, change fail rate and escaped defects. Collect them for six weeks from your existing tools without setting targets, then review the trend with the team and add flow and outcome measures once the first four are trusted.
