Most engineering organizations are measuring the wrong things. Lines of code written, number of commits, tickets closed: these numbers are easy to pull from existing tooling, and they will tell you almost nothing useful about whether your engineering team is delivering value. Worse, when developers know they're being measured on these metrics, they start optimizing for the number rather than the outcome.
The result is predictable: developers game metrics, trust erodes, and the work that actually matters slows down. Measuring developer productivity well is one of the most important things an engineering leader can do. Measuring it badly is actively harmful.
This guide covers which metrics the highest-performing engineering teams track, what they ignore, and how to act on the data without turning measurement into surveillance.
What Is Developer Productivity?
Developer productivity is the rate at which an engineering team delivers working, valuable software to the business. It is not the volume of code produced, the number of hours worked, or the number of tickets moved across a board. It is how effectively a team translates engineering effort into outcomes the business actually cares about.
This distinction matters for how you measure it. Individual output metrics (commits per developer, lines of code per sprint) push engineers toward activity that looks productive on paper but isn't. Slowdowns caused by unclear requirements, technical debt, blocked dependencies, or lengthy code review queues never show up in individual output data. But they dominate the actual cost of software delivery.
The right level of measurement is the team and the system, not the individual. Developer productivity reflects how well all the pieces of the delivery system are working together: requirements, development, review, testing, and deployment.
The Metrics Most Teams Get Wrong
Certain metrics are popular because they're easy to extract from existing tooling. They're also nearly useless for understanding whether your team is healthy.
Lines of code measure activity, not value. A 500-line refactor that removes complexity and reduces future maintenance cost is worth more than 5,000 lines of generated boilerplate. Tracking lines of code encourages verbosity, discourages refactoring, and has no relationship to software quality.
Number of commits tells you someone is active. It doesn't tell you whether what they're committing is sound, reviewed, or moving in the right direction. High commit counts from one developer can mask a problem just as easily as they can signal momentum.
Tickets closed is slightly better, but only if tickets are consistently scoped and meaningful. Most are not. Teams that optimize for ticket throughput learn to split large problems into many small tickets, move cards to "done" before work is truly complete, and avoid taking on ambiguous work that's hard to close quickly.
None of these metrics answer the question a business actually cares about: is the team delivering working software, reliably, at an acceptable quality level?
Metrics That Reflect Engineering Team Health
The metrics that work measure outputs of the delivery system, not inputs from individual engineers. Three frameworks give you the clearest picture.
DORA Metrics
The DORA research program has tracked software delivery performance across tens of thousands of teams since 2014. The State of DevOps report consistently finds four metrics that predict high organizational performance:
These four metrics give a reliable picture of delivery performance without requiring surveillance of individual developers. For a full breakdown of each metric and how to set baselines, see the DORA metrics guide.
The SPACE Framework
DORA metrics focus on the delivery pipeline. The SPACE framework, developed by researchers at GitHub and Microsoft, adds a broader lens that includes the developer experience itself. SPACE measures five dimensions:
SPACE is particularly useful for identifying productivity drains that don't appear in delivery metrics: developer burnout, poor tooling, excessive meeting load, or unclear requirements arriving mid-sprint. For guidance on when to use DORA versus SPACE and how the two complement each other, see SPACE vs DORA: choosing the right framework.
Sprint Completion Rate and PR Cycle Time
Two additional metrics round out a practical measurement set for most teams.
Sprint completion rate tracks how reliably a team delivers what it commits to in a sprint. Teams that consistently hit 70-80% of their sprint commitment are building predictability. Teams that regularly hit 40% have either a planning problem (unrealistic estimates), a dependency problem (blocked by external factors), or an unplanned work problem (interruptions overwhelming committed work).
PR cycle time (the time from pull request opened to merged) is a proxy for collaboration health. Long PR cycle times indicate review bottlenecks, unclear code standards, or a culture where review is treated as optional. Teams with PR cycle times under 24 hours ship more code with fewer integration conflicts than teams where reviews average three or more days. For benchmarks and improvement tactics, see engineering velocity measurement.
DORA vs SPACE: Which Framework Fits Your Team?
DimensionDORASPACEPrimary focusDelivery pipeline efficiencyDeveloper experience and productivityMeasurement levelTeam and systemIndividual, team, and organizationData sourcesCI/CD, version control, incident trackingSurveys, automated tools, usage dataBest forIdentifying delivery bottlenecksDiagnosing developer experience issuesLimitationDoesn't capture wellbeing or satisfactionSome dimensions require self-reporting
Most teams benefit from running both. DORA tells you what's happening to your delivery pipeline. SPACE tells you why, and whether the people running that pipeline are in good enough shape to sustain it.
How to Improve Developer Productivity
Measurement identifies problems. These structural changes fix them.
Reduce review bottlenecks. Long PR cycle times are one of the most common and addressable productivity drains. Set a team norm: pull requests reviewed within one business day. If this isn't happening, the queue is too long, reviews are insufficiently prioritized, or code submissions are too large to review efficiently. Smaller, more frequent PRs and a defined review SLA address all three.
Manage technical debt as ongoing work, not deferred work. Teams that never allocate sprint capacity to technical debt accumulate it until it slows delivery to a crawl. Treating debt reduction as a deliverable, and budgeting 15-20% of sprint capacity for it, keeps the codebase moveable and reduces the failure rate on deployments. The technical debt management guide covers a practical framework for prioritization.
Protect developer focus time. Fragmented attention is expensive. Context-switching between deep work and synchronous requests carries a recovery cost of roughly 20-30 minutes per interruption. Teams that protect at least four contiguous hours of focus time daily, through meeting norms, async-first communication, and defined no-meeting blocks, consistently outperform teams that don't.
Close the requirements gap before sprints start. Unplanned rework caused by unclear requirements is one of the largest invisible costs in software delivery. Requiring that tickets meet a definition of ready before they enter a sprint (acceptance criteria written, dependencies identified, design questions resolved) removes the most common source of mid-sprint disruption.
Connect delivery goals to business outcomes. Developers who understand how their sprint work connects to what the business is trying to accomplish make better trade-off decisions. Sharing the reasoning behind priorities, including engineers in planning conversations, and giving teams feedback on how their work performed in production all contribute to faster, more confident delivery.
The Role of Analytics Platforms
Tracking DORA metrics, PR cycle time, sprint completion rate, and code quality manually is time-consuming and inconsistent. The numbers need to come directly from the delivery system, not from status updates or self-reported data, to be reliable.
Scrums.com Analytics connects directly to GitHub, JIRA, and other core engineering tools to automate this tracking. It provides real-time dashboards on sprint health, lead times, code quality, and team velocity, and benchmarks performance across teams so engineering leaders can see where the system is working and where it isn't.
The purpose is not to create a surveillance layer. It's to give engineering leaders the visibility they need to make decisions, have informed conversations with their teams, and catch systemic issues before they compound. The Scrums.com engineering analytics platform is built for team-level improvement, not individual performance monitoring.
Frequently Asked Questions
What is the best way to measure developer productivity?
The most reliable approach combines DORA metrics (deployment frequency, lead time for changes, change failure rate, mean time to recover) with sprint completion rate and PR cycle time. These measure the output of the delivery system rather than individual activity, which makes them both more accurate and less damaging to team culture than individual output metrics like commits or lines of code.
Why shouldn't developer productivity be measured at the individual level?
Software delivery is a team and system problem. A developer's output depends on the quality of requirements they receive, the availability of reviewers, the state of the codebase, and many other factors outside their control. Measuring individuals creates perverse incentives (optimizing for the metric rather than the work) and misidentifies system problems as individual performance issues.
What is the difference between DORA and SPACE metrics?
DORA metrics focus on the delivery pipeline: how fast, how reliably, and how safely code moves from commit to production. SPACE adds a developer experience dimension, covering satisfaction, collaboration, efficiency, and wellbeing alongside performance. Most teams benefit from using both: DORA to track delivery health, SPACE to understand the conditions driving those numbers.
How do you improve developer productivity without micromanaging?
Focus on system-level changes, not individual monitoring. Reducing review bottlenecks, protecting focus time, managing technical debt, and ensuring requirements are clear before sprints start are all structural interventions that improve team output without surveillance. Giving teams context on business outcomes also improves delivery by enabling better decision-making at the team level.
What tools track developer productivity metrics automatically?
Analytics platforms that connect directly to your engineering stack (GitHub, JIRA, CI/CD pipelines) can automate the tracking of DORA metrics, PR cycle time, sprint completion rate, and code quality without manual data collection. Scrums.com Analytics pulls this data in real time and presents it through dashboards designed for engineering leaders and team discussions, not individual surveillance.
