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

Developer velocity measures the speed and efficiency with which software development teams can deliver high-quality code, products, or solutions. 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 not about making developers work more, but optimizing the entire software development lifecycle (SDLC) and processes.

Developer velocity is important for several reasons:

• Increased business value — A higher developer velocity translates to a faster time to market and customer feedback incorporation, which leads to more customers and improved retention rates.
• Offers greater adaptability — Your engineers will be able to accommodate changes easily and incorporate market feedback faster.
• Reduces overall costs — Higher developer velocity usually means fewer failures in production, which reduces the potential for losing business.
• Increase scaling — Deploying new features fast and incorporating feedback supports business growth and lets you expand your team’s capability of handling larger workloads and adapting to market demands
• Enhance collaboration — There is a strong correlation between developer velocity and collaboration. Greater developer velocity usually means more teamwork, due to knowledge sharing, feedback loops, and a strong review process.

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 much more complex – it incorporates velocity but also factors in the impact of the delivered solution compared to the business goals, overall system reliability, and the long-term maintainability of the solutions.

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

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
• Mean time to recovery (MTTR) – Average time to recover from a production failure
• Change failure rate – the percentage of changes causing a failure in production (Multiple environments reduce the overall failure risk.)
• 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/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

Metrics such as code review time, code testing time, sprint velocity, and even sprint completion rate aren’t easily quantifiable. 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

Now that you have identified the issues with your process, it is time to evaluate the products/tools you are using for bottlenecks. You should invest in tools that help you automate repetitive tasks, provide real-time feedback, and integrate seamlessly into your workflow. Also, you shouldn’t be scared to change your tooling: Understanding that specialized products can be a life-saver improves your overall workflow. 

For example, you may be using Jenkins for CI/CD inside your infrastructure. Jenkins is a powerful tool, but it won’t provide the level of automation you need for all your infrastructure resources. This is where a product such as Spacelift can take your workflow to the next level.

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. Foster collaboration and empower developers

Fostering collaboration and a healthy team culture is another strategy for improving your developer’s velocity. Breaking down silos between teams by encouraging regular standups, retrospectives, and knowledge-sharing sessions is a great way to improve collaboration. 

DevOps engineers need to stay in control while giving developers the capacity to spin up ephemeral/testing environments fast, so having a process for self-service infrastructure can be really helpful.

5. Monitor and measure performance

Monitoring and measuring all the metrics related to developer velocity can be really helpful, but when you are initially assigning importance weights, be wary and use these in your whole developer velocity improvement process.

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.

At Spacelift, we understand that you need a platform that not only helps you with infrastructure provisioning, configuring, and governing but also fosters collaboration and increases developer velocity.

Spacelift eliminates collaboration bottlenecks by allowing you to preview the implications of applying changes to your infrastructure while deciding within your team if those changes make sense. By leveraging our policy as a code engine, you can have automatic checks if your infrastructure resources meet certain criteria, and you can also take advantage of requiring multiple approvals from your users for your deployments.

By leveraging cloud integrations to dynamically generate credentials for your favorite cloud providers and contexts (logical containers for your environment variables, mounted files, and lifecycle hooks), you increase developer velocity by ensuring the same behavior at all runs.

Another important aspect related to developer velocity is the ability to leverage self-service infrastructure. Spacelift gives you two options to achieve this:

• Using Blueprints – YAML templates that configure all aspects related to your stacks: repository, tool, policies, cloud integrations, contexts, schedules, etc
• Using our K8s operator – you can configure Spacelift resources from inside Kubernetes

Spacelift has its own Terraform/OpenTofu provider, so you can easily build everything you would do from the UI programmatically. This ensures that when you have a configuration that you want to replicate, you can easily do it by encapsulating it in a module and reusing it.

With Spacelift, you can easily create dependencies between multiple configurations and even share outputs between them. In this way, you can create multi-tool workflows (e.g., Terraform + Ansible, OpenTofu + K8s, OpenTofu + OpenTofu + K8s), and you can create as many nested levels as you want. This, combined with blueprints and our Terraform, gives unprecedented flexibility and elevates developer productivity to the next level.

To ensure that everything works as planned, Spacelift offers two account-level views — one for IaC and the other for configuration management with Ansible. In both, you can see all the resources that have been provisioned and configured inside your account and whether they drifted or not.

Schedule a call to see how Spacelift can improve your developer velocity, elevate your collaboration, and much more.

Improving developer velocity is a continuous process that requires consistent effort, regular evaluation, and an openness to change. Investing in the right products and focusing on an environment where developers work efficiently will naturally improve developer velocity.

No strategy for improving development velocity is bulletproof – every team is different, and what works for one might now work for the other, so you should experiment with them, measure their impact, and adjust accordingly. One thing is bulletproof, though – collaboration between your development teams will always have a positive impact on developer velocity, so invest accordingly.