Productivity in Software Development: How to Measure It in 2026

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Productivity in software development is one of the most argued-about topics in engineering management, and in 2026 it has become harder, not easier, to get right. AI coding assistants now write a large share of new code, yet the 2025 DORA State of AI-assisted Software Development report found that AI adoption is still associated with higher delivery instability. More code is being produced; that does not automatically mean more value is being delivered.

For anyone buying or running engineering capacity, this matters in money. If you pay for an in-house team, a vendor or outcome-focused product engineering services, you need a defensible way to tell whether the team is getting faster, whether quality is holding and where time is being lost. Counting commits or story points will not tell you that, and using those numbers to rank people usually makes things worse.

This guide explains how to measure software development productivity in a way that engineers respect and executives can act on. It covers definitions, the three main frameworks (DORA, SPACE and DevEx), a practical metric set with benchmarks, the metrics to avoid, how to measure the impact of AI tools, and a six-step plan to roll out measurement. It is based on what we see running delivery teams for US and EU clients and on published research from DORA, Atlassian, Stack Overflow and METR.

What is productivity in software development?

Productivity in software development is the ability of a team to deliver working, valuable software to users quickly and sustainably, relative to the effort and cost it consumes. It combines three things: how fast changes flow to production, how reliable those changes are, and whether the work actually moves a business outcome.

Classic productivity is output divided by input. In a factory that works because every unit of output is identical. In software it breaks down, because no two features are equal: a ten-line fix to a pricing rule can be worth more than a ten-thousand-line module nobody uses. That is why mature organizations stopped treating code volume as output and started looking at delivery flow, quality and outcomes instead.

Output, outcome and impact

Output is what a team produces, outcome is the change it causes, and impact is the business result of that change. Keeping these three levels separate is the single most useful habit when you discuss productivity.

• Output: pull requests merged, features shipped, deployments made. Easy to count, easy to game.
• Outcome: users adopting a feature, support tickets falling, checkout conversion rising. Harder to attribute, much more meaningful.
• Impact: revenue, retention, cost savings, risk reduced. This is what leadership ultimately cares about.

A healthy measurement program uses output and flow metrics as leading indicators, but always connects them back to outcomes. A team that deploys ten times a day and never moves a product metric is busy, not productive.

Team productivity vs individual productivity

Software is a team sport, so productivity should be measured at the team or system level, not per developer. A senior engineer who spends a day unblocking three colleagues may merge nothing and still be the most productive person on the team that week.

Individual metrics also invite gaming: people split pull requests, avoid hard tasks and skip code reviews to protect their numbers. Use individual data only in private, supportive one-to-one conversations about growth and blockers, never in rankings or performance scorecards.

Why should you measure software development productivity?

You should measure software development productivity to find bottlenecks, check whether process and tooling changes actually help, forecast delivery more reliably and have fact-based conversations about investment. Done well, measurement is a diagnostic tool for the system, not a judgment of people.

The practical benefits we see when teams start measuring properly are consistent:

• Visible bottlenecks: breaking lead time into stages shows whether work waits in review, testing, approvals or deployment.
• Evidence for change: you can tell whether a new CI pipeline, a team reorganization or an AI tool rollout improved delivery, instead of relying on impressions.
• Better forecasts: historical cycle time and throughput produce more honest delivery dates than gut-feel estimates.
• Early warning on quality and burnout: rising rework, incidents or falling satisfaction scores signal trouble months before attrition or a major outage.
• Shared language with leadership: engineering investment decisions, such as paying down technical debt, become easier to justify with trend data.

Why is software development productivity so hard to measure?

Software development productivity is hard to measure because the work is creative, collaborative and uneven in value, and because most easily available numbers measure activity rather than results. Any single metric can be optimized at the expense of what you actually want.

The main reasons, in our experience, are these:

• Work items are not comparable: a story point in one team means something different in another, and estimates drift over time.
• Value appears later: the payoff of refactoring, test coverage or architecture work shows up months after the effort.
• Much of the work is invisible: design discussions, code review, mentoring, incident response and requirement clarification rarely show up in tooling.
• Goodhart's law: when a measure becomes a target, people optimize the measure, and it stops reflecting reality.
• Bottlenecks sit outside engineering: unclear requirements, slow approvals and dependencies on other teams cap delivery speed regardless of developer effort.
• AI inflates volume: assistants generate code quickly, so activity counts rise even when review load, rework and defects rise with them.

The last point is now significant. Atlassian's State of Developer Experience 2025 report found that 50% of developers lose more than 10 hours a week to organizational inefficiencies, even as 68% say AI tools save them more than 10 hours a week. Time saved at the keyboard can easily be lost in meetings, waiting and searching for information, and only a balanced set of metrics will show where.

Which frameworks are used to measure developer productivity?

The three most widely used frameworks for measuring developer productivity are DORA for software delivery performance, SPACE for a multi-dimensional view of productivity, and DevEx for the developer experience. Most mature teams combine them rather than pick one.

DORA metrics: delivery speed and stability

DORA metrics measure how quickly and safely a team delivers changes to production, and they remain the most research-backed starting point in 2026. They come from the DevOps Research and Assessment program, which has surveyed tens of thousands of professionals since 2014 and is now part of Google Cloud.

• Deployment frequency: how often the team successfully releases to production.
• Change lead time: the time from a code commit to that code running in production.
• Change failure rate: the share of deployments that cause a failure needing remediation, such as a rollback or hotfix.
• Failed deployment recovery time: how long it takes to restore service after a failed deployment (formerly mean time to restore, MTTR).
• Deployment rework rate: the share of deployments that are unplanned fixes for incidents, added by DORA to capture instability more precisely.

DORA's strength is that speed and stability are measured together, so you cannot look good by shipping recklessly. Its limitation is that it says nothing about developer well-being, collaboration or whether the right things are being built.

The SPACE framework: five dimensions of productivity

The SPACE framework, published by Nicole Forsgren, Margaret-Anne Storey and colleagues from GitHub, Microsoft and the University of Victoria in 2021, says productivity cannot be captured by one number and should be measured across five dimensions.

• S, Satisfaction and well-being: how fulfilled, healthy and happy developers are with their work, tools and team.
• P, Performance: the outcome of the work, such as quality, reliability and customer impact.
• A, Activity: counts of actions such as commits, reviews and deployments, useful only in context.
• C, Communication and collaboration: how well people and teams share knowledge, review work and coordinate.
• E, Efficiency and flow: the ability to make progress with minimal interruptions, waiting and handoffs.

The practical rule from SPACE is to pick metrics from at least three dimensions and to mix system data with survey data. Activity on its own is explicitly not a productivity measure.

DevEx and DX Core 4: the developer experience

The DevEx framework focuses on the lived experience of developers through three dimensions: feedback loops, cognitive load and flow state. It was published in 2023 by Abi Noda, Margaret-Anne Storey, Nicole Forsgren and Michaela Greiler, and it relies heavily on well-designed developer surveys.

DX Core 4, introduced in 2024 by the company DX, consolidates DORA, SPACE and DevEx into four dimensions: speed, effectiveness, quality and business impact. It is popular with leadership teams that want one compact scorecard spanning delivery data and developer sentiment.

DORA vs SPACE vs DevEx: which one to choose?

Choose DORA first if you have no baseline, add SPACE or DevEx once delivery data is flowing, and use flow metrics to find where work gets stuck. The table summarizes how they differ.

Which software development productivity metrics matter most?

The software development productivity metrics that matter most in 2026 fall into four groups: delivery, flow, quality and developer experience. Pick two or three from each group, measure them at team level and watch trends rather than single values. For a full catalog of definitions and a KPI dashboard layout, see our guide to software development KPIs.

Delivery metrics

Delivery metrics show how quickly and reliably value reaches users. They are the DORA four plus throughput.

• Deployment frequency and change lead time for speed.
• Change failure rate and failed deployment recovery time for stability.
• Throughput: the number of completed work items per week, tracked as a trend for the same team, never compared across teams.

Flow metrics

Flow metrics show where work waits, which is usually where most of the lead time goes. In many teams, active work accounts for a small fraction of total cycle time; the rest is queues.

• Cycle time: time from starting work on an item to delivering it, broken into coding, waiting for review, review and deployment.
• Pull request review time: how long a pull request waits for its first review and until merge. Our explainer on what a pull request is in software development covers why this stage is so often the bottleneck.
• Work in progress (WIP): how many items are open at once. High WIP means context switching and long queues.
• Work item age: how long open items have been in progress, an early warning for stuck work.
• Flow efficiency: active time divided by total cycle time.

Quality metrics

Quality metrics stop a team from buying speed with future problems. They should always sit next to speed metrics on the same dashboard.

• Escaped defects: bugs found in production per release or per month.
• Rework rate: the share of recent code changed again within a few weeks, a signal of unclear requirements or rushed work.
• Incident count and severity linked to recent changes.
• Technical debt indicators: share of time spent on maintenance, flaky tests, build duration.

Developer experience metrics

Developer experience metrics capture the friction that system data cannot see. They come from short, regular surveys and are leading indicators of attrition and slowdowns.

• Developer satisfaction with tools, processes and team, on a simple scale.
• Perceived productivity: how productive people feel and what blocks them most.
• Time lost to friction: self-reported hours lost per week to waiting, unclear requirements, flaky builds or searching for information.
• Onboarding time: how long a new engineer needs to ship a first meaningful change.
• Focus time: uninterrupted blocks of two hours or more per week.

Business outcome metrics

Business outcome metrics connect engineering work to the results the company pays for. Without them, a team can improve every delivery number and still build the wrong things.

• Feature adoption: the share of target users who use a new feature within 30 or 90 days of release.
• Time to value: how long it takes from an idea being approved to customers benefiting from it.
• Roadmap predictability: the share of committed initiatives delivered in the planned quarter.
• Cost per delivered change: total engineering cost divided by changes that reach production, tracked as a trend.
• Unplanned work ratio: the share of capacity consumed by incidents, urgent fixes and support escalations.

These numbers are owned jointly by product and engineering. They work best in quarterly reviews, where they show whether faster delivery is actually turning into customer and business value.

What are good benchmarks for DORA metrics?

Good benchmarks depend on the system, but published DORA data gives useful reference points. The figures below come from the 2025 DORA report, which moved from four performance tiers to a distribution of responses.

Compare a team with its own past, not with another team or company. A regulated banking core and a marketing website should not share the same deployment target. For more reference data on enterprise delivery, see our roundup of enterprise software development speed statistics.

What should you not measure?

You should not use lines of code, commit counts, story points completed, hours logged or tickets closed as productivity measures, and you should never use any metric to rank individual developers. These numbers reward activity, are easy to game and push people away from valuable but invisible work.

• Lines of code: better code is often shorter. Deleting a thousand lines of dead code is real progress that this metric punishes. AI assistants make the number even less meaningful.
• Commit or pull request counts: trivially inflated by splitting work, and they say nothing about value or quality.
• Story points as output: points are a planning tool for one team. Using them to compare teams or measure productivity causes point inflation within weeks.
• Hours worked: long hours correlate with burnout and defects, not with outcomes.
• Tickets closed: one ticket may be a typo, another a month of work.
• Individual leaderboards: they destroy collaboration, discourage code review and mentoring, and drive away senior engineers.

How do you measure software development productivity, step by step?

To measure software development productivity, define the question you want to answer, collect a small balanced set of team-level metrics from existing tools, add a short developer survey, establish a baseline, then review trends with the team and act on the biggest bottleneck. The six steps below are the rollout we use with clients.

1. Start with a question, not a dashboard. “Why do releases take three weeks?” or “Did the new CI pipeline help?” leads to useful metrics; “show me productivity” leads to vanity charts.
2. Collect DORA metrics from existing systems. Version control, CI/CD and incident tools already hold the data. Define precisely what counts as a deployment and a failure before you measure.
3. Add flow and quality metrics. Break cycle time into stages, track pull request review time, WIP and escaped defects.
4. Run a short developer survey. Five to ten questions every quarter on satisfaction, friction, focus time and the biggest blockers. Keep it anonymous and share the results.
5. Establish a baseline for four to eight weeks. Do not set targets yet; first learn what normal looks like and how noisy the numbers are.
6. Review trends with the team and fix one bottleneck at a time. Put metrics into retrospectives, agree on one improvement, then check whether the numbers moved.

Transparency is what makes this work. Show the same dashboard to engineers and leadership, explain how each number is calculated and make clear that metrics open conversations rather than close them.

How to measure productivity in agile teams

In agile teams, measure productivity through cycle time, throughput trends, sprint goal completion and escaped defects rather than velocity. Velocity is a capacity-planning tool for one team and loses meaning as soon as it becomes a target.

Useful agile signals include the share of sprint goals met, how often scope changes mid-sprint, carry-over between sprints and how long items spend blocked. Our guide to managing software development teams covers the rituals where these numbers should be discussed.

How to measure the productivity of an outsourced team

Measure an outsourced or vendor team with the same team-level metrics you use internally, written into the contract as reporting obligations rather than as penalties. Hours billed tell you about cost, not about productivity.

• Require access to the repository, CI/CD pipeline and issue tracker from day one.
• Agree on DORA metrics, cycle time and escaped defects as monthly reporting items.
• Hold regular demos of working software, not slide updates.
• Track predictability: the share of committed scope delivered per milestone.
• Review quality signals such as test coverage trend and incident count alongside speed.

This is also how we work with clients on dedicated development teams: the client sees the same delivery dashboard our tech lead uses.

How do AI coding tools affect productivity in software development?

AI coding tools speed up individual tasks such as boilerplate, tests and documentation, but their effect on team productivity depends on review capacity, quality controls and engineering foundations. Measured at the system level, gains are real but smaller and less even than self-reported gains suggest.

The research picture in 2025 and 2026 is mixed:

• Adoption is near-universal: the 2025 DORA report found that about 90% of respondents use AI at work, and the Stack Overflow Developer Survey 2025 found that 84% of developers use or plan to use AI tools.
• Perceived gains are large: Atlassian's 2025 report found that 68% of developers say AI saves them more than 10 hours a week.
• Measured gains can be negative: a randomized controlled trial by METR in 2025 found that experienced open-source developers took 19% longer to complete tasks when allowed to use AI tools, even though they believed they were faster.
• Stability can suffer: DORA reports that AI adoption is still associated with increased delivery instability, and describes AI as an amplifier of existing strengths and weaknesses.

To measure AI impact honestly, compare team-level delivery and quality metrics before and after rollout, and watch pull request review time, rework rate and change failure rate closely. If code volume rises while review time and defects rise too, the bottleneck has simply moved. Our overview of AI tools for software development covers which tools help most and where they need guardrails.

How can you improve developer productivity?

The fastest way to improve developer productivity is to remove waiting and interruptions from the system rather than to ask people to work harder. Most gains come from smaller batches, faster feedback loops, clear requirements and protected focus time.

1. Shrink batch size: small pull requests are reviewed faster, fail less often and are easier to roll back.
2. Speed up feedback loops: keep CI builds under ten minutes, run tests in parallel and give developers fast local environments.
3. Set review norms: agree on a target for first review, for example within one business day, and treat review as real work.
4. Limit work in progress: finish before starting; fewer parallel items means less context switching.
5. Protect focus time: research from UC Irvine found that it takes about 23 minutes to get back on task after an interruption. Cluster meetings and keep blocks of uninterrupted time.
6. Clarify requirements early: a short discovery phase and clear acceptance criteria prevent the rework that unclear tickets create.
7. Invest in platform and tooling: self-service environments, templates and automated deployments remove repetitive work across all teams.

Team design matters as much as tooling. Small, cross-functional teams that own a product area end to end have fewer handoffs and dependencies; our article on software development team structure explains the common models. Engineering habits such as code review, testing and continuous integration, covered in our software development best practices guide, compound over time.

Which tools help measure software development productivity?

Most productivity data already lives in the tools a team uses every day, so start with version control, CI/CD and issue trackers before buying a dedicated platform. Engineering intelligence platforms help once you know which questions you want answered.

Whatever the tool, agree on definitions first. Two dashboards that count “deployment” differently will produce two different truths and a lot of wasted meetings.

How do you report developer productivity to executives?

Report developer productivity to executives as a short, trend-based scorecard that links delivery metrics to business outcomes, not as a wall of engineering charts. Leadership needs to know whether delivery is getting faster and safer, what is slowing it down and what investment would help.

A one-page monthly or quarterly report usually works best:

• Speed: change lead time and deployment frequency, with the trend over the last three to six months.
• Stability: change failure rate, recovery time and major incidents.
• Predictability: share of committed roadmap items delivered on time.
• Developer experience: satisfaction score and the top three blockers from the latest survey.
• Investment split: roughly how engineering time divides between new features, maintenance, technical debt and unplanned work.
• One ask: the single change, such as faster CI or another QA engineer, that would most improve the numbers.

Translate metrics into business language. “Lead time fell from 12 days to 5” means customers get fixes and features more than twice as fast; “change failure rate halved” means fewer outages and support escalations.

Common mistakes when measuring productivity

The most common mistakes are measuring individuals instead of teams, tracking activity instead of outcomes, setting targets before a baseline exists and treating measurement as surveillance. Each one turns a useful diagnostic into a source of distrust.

• Turning metrics into targets: the moment a number drives bonuses, it gets gamed.
• Measuring only speed: without quality counter-metrics, teams trade stability for velocity.
• Comparing teams with different contexts: a legacy platform team and a greenfield product team cannot share targets.
• Ignoring the developer voice: system data shows what happens; surveys explain why.
• Collecting data nobody acts on: if metrics never change a decision, stop collecting them.
• Hiding the dashboard from engineers: secret metrics feel like surveillance and erode trust.

Productivity measurement checklist for engineering leaders

Use this checklist to sanity-check a productivity measurement program before you present it to leadership or the team.

• Metrics cover at least three areas: delivery, quality and developer experience.
• Every speed metric has a quality counter-metric next to it.
• All metrics are aggregated at team level; no individual rankings exist.
• Definitions of deployment, failure and cycle time are written down.
• A baseline of at least four weeks exists before any target is set.
• A short developer survey runs at least quarterly and results are shared.
• Metrics are reviewed in retrospectives and lead to one concrete improvement at a time.
• The impact of AI tools is assessed with delivery and quality data, not with usage counts.

If you are estimating how a team’s productivity translates into timelines and budgets, our software project estimation guide shows how to use historical cycle time and throughput for forecasts.

Frequently asked questions

Published 5 November 2026. Sources: DORA, State of AI-assisted Software Development 2025; DORA metrics guide; Forsgren et al., The SPACE of Developer Productivity, ACM Queue (2021); Noda et al., DevEx: What Actually Drives Productivity, ACM Queue (2023); Atlassian, State of Developer Experience 2025; Stack Overflow Developer Survey 2025; METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.