Developer Velocity: What It Is, How to Measure & Improve It

Your developers ship faster than they ever have. AI writes the first draft of most of their code, features land in days instead of weeks, and the review queue never empties. Then someone needs a database, and everything stops for three days while a ticket works its way through your platform team.

That gap is what developer velocity measures. Not how fast your developers type, but how long an idea takes to become something a customer can use, and whether it holds up once it gets there.

In this post, we’ll cover what developer velocity is, which metrics actually track it, where the measurement goes wrong, and what to change first.

Developer velocity measures the speed and efficiency with which software development teams can deliver can deliver working software. It includes the speed of shipping new features and bug fixes, the quality of the output, team efficiency and collaboration, the ability to respond to changes, and much more.

Consider developer velocity as the rate at which a development team can turn ideas into working applications that provide real value to the end users. It is about optimizing the entire software development lifecycle (SDLC), not about making developers work more.

Developer velocity gets attention outside engineering because it predicts things leaders care about. DORA treats its five delivery metrics as leading indicators for organizational performance and team well-being, and as lagging indicators for your delivery practices. How quickly and safely you ship now tells you where the business and the team are heading.

The more useful finding is that speed and stability are not opposites. DORA has shown repeatedly that its metrics correlate for most teams: top performers do well across all five, and low performers do poorly across all five. The teams deploying most often tend to be the teams breaking production least often. If you are currently trading quality for speed, that is a fact about your pipeline, not a law of software delivery.

What higher velocity actually buys you:

• Shorter feedback loops – You learn what customers want by shipping to them, not by planning for them.
• Cheaper mistakes – High-velocity teams ship smaller changes, and smaller changes are easier to diagnose, revert, and reason about. DORA points to reducing batch size as the most common way to improve all five metrics at once.
• Capacity without headcount – When deploying is routine, teams absorb more work without adding people.
• Less firefighting – Fewer failed deployments and less unplanned rework mean your engineers spend their weeks on the roadmap instead of in incident channels.
• Retention – Engineers leave organizations where shipping anything takes three weeks and a ticket. That one you can verify against your own exit interviews.

Developer velocity vs productivity

Developer velocity can be an indicator of productivity, but if developers focus too much on improving this metric, this can harm productivity in the long run because of burnout or technical debt.

Developer velocity focuses more on delivering new features fast and without issues, whereas developer productivity is broader. It includes velocity, but also the impact of what you shipped against the business goals, system reliability, and how maintainable the result is over time.

It is important to increase developer velocity, but not at all costs, as this can affect your overall productivity.

Read more: What is Developer Experience (DevEx)?

Here are some of the many metrics you can use to measure developer velocity:

• Deployment frequency – How often your code gets deployed into the production environment; a higher deployment frequency with a small failure rate translates to faster time to market
• Change implementation time – How long it takes for an open pull request to be merged and ultimately deployed (DORA calls this change lead time)
• Failed deployment recovery time (formerly MTTR) – Average time to recover from a production failure
• Change fail rate – the percentage of changes causing a failure in production.
• Percentage of deployments without vulnerabilities – Vulnerabilities are not bugs, but they can be easily transformed into exploits, so they have to be solved as soon as possible.
• Code review time – How long it takes to review, address feedback, and merge code changes
• Code testing time – How long it takes to test your code and address bugs
• Sprint velocity – Number of story points completed in a sprint
• Sprint completion rate – The percentage of planned work completed in a sprint

These metrics can help you understand which areas your organization needs to improve. If you deploy changes weekly to production but more than half lead to failures, even if you have a great MTTR, you should focus more on testing your changes in a development environment and implement code change freezes at least one day prior to the production release to increase your velocity.

On the other hand, if you deploy to production bi-weekly and there are few failures, you should focus on improving your deployment frequency while maintaining the same quality.

The challenges of measuring developer velocity

It is important to understand that these metrics should be used for guidance rather than as strict performance metrics. Your goal should be improvement, and you shouldn’t sacrifice code quality for speed or ignore technical debt just to “improve” developer velocity.

The metrics we have identified for measuring developer velocity also come with several challenges:

1. Inconsistency across teams and organizations

Prior experience may count for little when measuring developer velocity inside a new organization. Every team is different, and what was considered a good velocity in a prior job may be deemed poor in another one. 

A larger codebase may have a longer code review time than a smaller one, so this should not be taken as a template from a previous experience. If the team is bigger, the sprint velocity will be higher than in a small team, but that doesn’t mean that the development velocity is also higher.

2. Quality vs quantity

Raw metrics can be misleading because they can prompt a trade-off between speed and quality. If you think that increasing developer velocity means increasing your deployment frequency as much as possible, you will sacrifice quality, and this will result in technical debt and, in some cases, failures that lead to poor customer retention. 

Having a great change implementation time but a bad change failure rate means you still have work to do to increase developer velocity.

3. Not focusing on the outcome

If you focus more on increasing the metrics rather than on their outcome, you will have a great developer velocity, but your business will suffer because you will miss important information about your project’s success.

4. Inflating metrics

Focusing solely on looking good in reports will have a negative impact on your business, even though developer velocity may have skyrocketed. 

5. External dependencies

Dependencies on third-party actors are a feature of all software development practices. These may be different teams, regulatory requirements, or changes in the project scope. All of these factors make detecting developer velocity harder because they introduce variability.

6. Hidden factors

Code review time, test cycle time, sprint velocity, and sprint completion rate all resist clean quantification. Other factors, like learning new technologies and technical debt payoff, can go unnoticed and are not taken into consideration when it comes to understanding developer velocity.

Improving developer velocity is an ongoing process. Here are some key strategies to help you accelerate and optimize your team’s performance:

1. Identify issues with your process

The first and most important strategy is to identify what works and what doesn’t work inside your process. Take the metrics, do an objective evaluation, and understand where you need improvement.

2. Evaluate your developer tools

Once you know where the process breaks, look at the tools sitting at those points. Invest in tooling that automates repetitive work, gives fast feedback, and fits the workflow your team already has. And don’t be precious about replacing something that works but doesn’t fit.

Jenkins is the common example. It handles application CI/CD well, and plenty of teams then bend it into an infrastructure pipeline, where it has no state awareness, no plan review, no drift detection, and no policy layer. It runs your Terraform. It doesn’t understand it. That is the gap purpose-built infrastructure orchestration closes.

3. Address the technical debt

Another important strategy is addressing technical debt. This should be just as high a priority as feature development. Avoiding it will produce more issues and halt the development process for several months.

4. Give developers a governed path of their own

Standups, retrospectives, and knowledge sharing break down silos between teams, and they matter. But the collaboration bottleneck most platform teams actually hit is structural, not cultural: developers cannot get what they need without asking someone.

Platform engineers need to keep control of production and still let developers spin up ephemeral and test environments in minutes. That means self-service infrastructure with the guardrails built into the path, rather than access handed out and audited later.

5. Monitor and measure performance

Pick a small set of metrics, baseline them before you change anything, and review them on a fixed cadence. Don’t weight them by gut feel in the first month. You need a few cycles of data before you know which numbers move together on your team, and which ones are noise.

6. Avoid implementing too many changes at once

If your organization is performing poorly from a developer velocity perspective, don’t implement too many changes simultaneously. This is a long-term effort, so identify the most important thing to change, work on it, and proceed from there. 

Trying to implement too many changes at once will probably frustrate your team, and you may end up reducing developer velocity for a long period before seeing any improvements.

AI moved the bottleneck. When your developers generate most of their first-draft code, writing code stops being the slow part and everything downstream becomes the constraint: review, testing, provisioning, and approval.

DORA’s 2025 research shows both halves of that. AI adoption reached 90% of respondents, and for the first time it correlates positively with software delivery throughput, a reversal from 2024. It still correlates negatively with delivery stability. Teams got faster. Their systems did not get safer. DORA’s own framing is that AI amplifies what a team already has rather than fixing what it lacks.

Infrastructure is where a lot of that instability lands. Our 2026 Infrastructure Automation Report surveyed more than 400 infrastructure decision makers and found that 78% use AI to generate IaC without review, 76% would apply AI-generated Terraform to production with little or no scrutiny, and 93% have already had at least one AI-caused infrastructure incident.

At the same time, 86% of infrastructure leaders say they are confident in their AI governance, and only 30% have a formal policy.

That is the trap. Deployment frequency climbs, the dashboard looks healthy, and change fail rate quietly climbs with it. If you measure only throughput, AI will improve your numbers while your production environment gets less predictable.

Two consequences for how you measure developer velocity in 2026:

• Read throughput and instability together, never separately. A rising deployment frequency next to a rising change fail rate is not improved velocity. It is rework arriving faster.
• Treat provisioning lead time as a first-class metric. If a developer waits three days for a database, it does not matter how quickly the code got written.

Platform teams don’t slow developers down on purpose. They slow them down because every request, from a production database to a two-day test environment, goes through the same review, the same Terraform, and the same person.

Spacelift gives you two paths instead of one. Production infrastructure stays on IaC and GitOps, versioned and reviewed. Everything else, the POCs, demos, and short-lived test environments, goes through Intent, where developers describe what they need through their own LLM using the Spacelift MCP server. Both paths run under the same policies, the same credentials, and the same audit trail, so speed on one side doesn’t cost you control on the other.

Underneath that:

• Policy as code built on Open Policy Agent. Attach a policy by label once and your plan, approval, and push rules apply to every stack carrying that label, not just the ones someone remembers to check. Intent requests get their own Intent policies.
• Self-service through Templates and Blueprints. Blueprints create a stack and step back. Templates stay attached to what they create, pinned to a commit and immutable, which is what you want for infrastructure that has to stay consistent.
• Cloud integrations that generate short-lived credentials for AWS, Azure, and Google Cloud, plus contexts for shared environment variables, mounted files, and hooks, so every run behaves the same way.
• Stack dependencies with shared outputs, so a Terraform or OpenTofu stack feeds its outputs straight into the Ansible and Kubernetes stacks downstream, in whatever order your graph needs.
• Spacelift Intelligence, covering both Intent and the Infra Assistant, for the questions that used to need a war room: what changed, what drifted, who deployed it, and what the risk is.
• A resource view across your whole account showing what has been provisioned and configured, and which run and commit put it there.

If you want to learn more about Spacelift, create a free account today or book a demo with one of our engineers.

Developer velocity measures how quickly a team turns an idea into working software, and how reliably that software holds up once it reaches production. It is not sprint velocity, and it is not lines of code written.

• Developer velocity covers the full path from idea to production, including code review, testing, provisioning, and deployment.
• Developer velocity is not developer productivity. Velocity covers delivery speed and reliability, whereas productivity also accounts for business impact, system reliability, and long-term maintainability.
• Measure developer velocity with DORA’s delivery metrics, and read throughput and instability together. Deployment frequency on its own tells you almost nothing.
• AI raises throughput and lowers stability.
• Improve developer velocity by fixing one constraint at a time. For most teams the slowest step is not writing the code, it is waiting for infrastructure.