Developer velocity: what is it and how to increase it?

Software development companies are increasingly focused on finding ways to improve the performance of their developers.

That isn’t surprising, given the state of the industry today. 

Start-ups, small companies, big companies, and huge enterprises compete for a limited pool of users, and all of them are convinced that they have the best products.

So, what can you do to stand out from the rest? Improving developer velocity can be a game-changer.

In this article, we’ll go deep into developer velocity, dissect it and offer tips on improving it.

Today’s software development culture demands speed and quality, so it’s not surprising that something called developer velocity is important to define, track and improve. 

But what is it exactly? The answer isn’t as simple as you might think.

First of all, there are many definitions of developer velocity. For example, here’s one from the previously-cited work by McKinsey & Company:

As you can see, it’s focused on creating a good developer environment, which can lead to better business results.

However, the definition is entirely different if we view developer velocity in the context of an agile environment:

Let’s unpack the definition above.

As you probably know, a sprint is a short period during which a team needs to complete a specific task.

Furthermore, user stories are simple explanations of end goals you want to achieve by completing a small unit of work.

They’re expressed straightforwardly, like this:

For instance, below, you can see what they look like in software like Jira.

Notice that the user in that example doesn’t necessarily mean the user in the traditional sense of consumer. 

Instead, the user can be another team member who wants to achieve something by completing a user story.

When we put all that together, we have developer velocity, which is a measure of how many small tasks can be completed during a set time period.

Below, you can see what that looks like when it’s tracked on the Sprint Burndown Chart.

As you can see, as the time passes, there are fewer and fewer stories to complete, so it’s easy to see if the developer team’s velocity is on point.

For instance, the more stories completed per sprint, the higher the developer velocity is, which means more value is delivered to the customers.

There’s one more point about developer velocity that some experts like Martin Fowler point out—it’s a tool best used for estimating how much time a team needs for a task, and estimations are based on previous similar tasks.

In other words, when you measure developer velocity, you get the data that can help you plan for future team projects—it isn’t a metric for ranking the teams among themselves.

Should we even bother with developer velocity, and is it actually important for software development? Let’s try to answer that question in the next section.

Developer velocity is more than just a measure of how fast your developers can burn through tasks. It can be a strong indicator of whether a business is headed in the right direction.

We can get the answer to the question from the title of this section by looking at some data.

In 2020, McKinsey & Company surveyed senior executives at 440 large enterprises, conducted over 100 interviews, and completed extensive research to determine what factors allow organizations to achieve developer velocity.

As a result, they came up with the Developer Velocity Index (DVI), which we’ll touch on in one of the later sections.

Later, Microsoft did its own research and found a strong correlation between a high DVI and a company’s success.

As you can see from their data, companies with a high developer velocity have four to five times faster revenue growth, 60% higher shareholder returns, 20% higher operating margins, and a 55% higher score on innovation scales.

Overall, the conclusion is that investing in developer velocity matters and makes a noticeable difference in achieved results.

Furthermore, developer velocity matters even when it’s not that stellar. 

Why? Because after you analyze the reasons why it’s not high, you can implement changes to improve your software development process.

According to Tyler Hakes, director at Juice, Top of the Funnel, and Optimist, developer velocity highlights how you can apply innovation, improve customer experience, and, therefore, get more revenue.

Improving it is also great for the software development team:

If you need more convincing, here’s what Ian McAllister, a former director at Amazon and Airbnb, says about it:

In short, developer velocity is a great estimation tool that can help you set realistic expectations, empower your team to meet them, and increase overall satisfaction across the organization.

If you add to those business improvements we mentioned earlier, it’s very well worth tracking and improving.

Many factors contribute to how fast the development team produces quality software—and that also means that many factors can negatively impact that speed.

What are those factors? Let’s start with a more technical aspect.

A codebase lacking continuous integration and continuous delivery (CI/CD) can be detrimental to developer velocity.

In simple terms, CI means that developers’ contributions are frequently merged, even multiple times a day. 

Similarly, CD ensures that software is released frequently and in smaller increments like updates.

You can see how that process works in the visual above—it’s a continuous loop of coding, building, testing, releasing, deploying, monitoring, and then planning what to code again.

Having a streamlined process like that is efficient—it usually involves the automation of repetitive tasks and allows developers to code, merge and release quickly.

On the other hand, a process that is missing all of that results in slower progress. 

Often it proves more frustrating to developers, who have to deal with inefficiencies and the waste of time and resources.

Software tools like Bamboo, with its automation and integrations with Jira, Bitbucket, AWS CodeDeploy, and other Atlassian tools, can make building and maintaining a continuous pipeline more manageable.

However, even if your team has the smoothest CI/CD process, their velocity could still be low if they don’t have suitable working conditions.

That means they should have an environment where they can work without distractions and interruptions, achieving their flow state.

Getting to that sweet spot where the work is challenging enough not to be boring and not so difficult as to be frustrating is hard for developers if they’re constantly interrupted with meetings, messages, or other tasks.

According to GitHub’s survey, that can have a big impact. The chance of having a good day while interrupted at work plummets by 75%.

And you can’t expect great developer velocity if they have to switch tasks and stop their work every so often. That’s inefficient and can slow down even the best developers.

Also, you can’t expect developers to reach peak velocity if they lack diverse training.

Investing in their skills can pay off in the long run—the more rounded a developer is, the more problems they can solve, the faster they are at doing it, and the team can achieve better results.

A T-shaped developer, someone with broad and deep knowledge, is a great asset, but one you can’t have without proper training and education.

However, to even know where you stand with developer velocity in your team, you should be able to measure it.

Let’s dive into how to do that and what to pay attention to.

In previous sections, we established what developer velocity is, why it’s important and what can reduce it. Now it’s time to look at the ways to measure it.

Only by measuring it can you know where your team stands and how much work you have to get them to their peak velocity.

Luckily, a good assessment tool can help you with that.

Remember the Developer Velocity Index (DVI) we mentioned in one of the earlier sections? 

Microsoft made a tool called Developer Velocity Assessment which can, as the name suggests, assess the DVI of your organization.

It works like this: you answer questions about the inner workings of your organization and get a report about your calculated DVI.

For example, here’s what it looked like when Jussi Roine took the assessment for his organization.

The DVI score was 3.4. The report indicated that it’s above average, as you can see below.

The assessment also gave a score in three categories that relate to developer velocity—technology, working practices and organizational enablement.

Furthermore, the tool then creates a graph with subcategories and scores in each one of them.

On the far left, you can see what factors this tool included as important in each category.

For example, they featured architecture, infrastructure/platform, testing, security and compliance, as well as tooling in the technology category.

That’s very useful because you can see the score for each factor on the far right and know which areas need improvement.

To make it more straightforward for you, the tool also provides a more detailed explanation of each subcategory, as well as resources for further research.

DVI is one of the ways you can measure developer velocity. Of course, you can do it in a less complex way by using a simple formula.

For instance, as we mentioned, developer velocity is the amount of work a team can handle in a set time period.

Therefore, to measure velocity, you can do it like this:

That way, you get an average number that you can compare to other projects—the higher the number, the higher the velocity.

Keep in mind that consistency is key. For example, if you measure with the above formula, don’t switch from sprints to weeks or some other variable. 

You won’t get the realistic measure you want.

After we established what you need to know about developer velocity, there’s only one question left—how to improve it?

As you’ve probably noticed by now, developer velocity is complex, and many factors influence it.

The following section will focus on four of them that you should work on—tools, culture, product management, and talent management.

Would you expect an architect to design a complex project by drawing it with a stick in the sand? 

Therefore, you shouldn’t expect developers to maintain a streamlined process of producing and delivering top-quality work in little time if they have subpar tools at their disposal.

Top-of-the-line tools provide a foundation for developer velocity. 

According to data from McKinsey & Company, developers who use them are more satisfied, which leads to 47% higher retention rates and 65% more innovation.

And developers who are more satisfied and have a way to be creative in their work are most likely to produce better results in less time than developers stuck with inefficient and outdated tools.

One of the best tools you can provide them is our own automated software solution that helps them with the repetitive and time-consuming task that is fixing bugs—Shake.

With Shake, your developers get a detailed bug report with over 50 pieces of information about the issue so that they can fix it quickly and efficiently.

The users just need to shake their phone when they notice a bug in an app, and Shake automatically creates a report and sends it.

That way, the developers can have more time to do the most challenging and engaging work and increase the team’s velocity.

When developers feel safe and supported without judgment, they’re more likely to share their ideas and take risks.

Creating a culture like that can significantly improve developer velocity—it provides a space that frees developers and allows them to pull all the stops and do their best.

And a safe space is increasingly important in today’s software developer culture. 

According to data from Stack Overflow’s 2021 survey, almost 27% of developers battle anxiety, emotional, or concentration disorders.

Dealing with deadlines, requirements from managers and users, technology issues, distractions, and more are all part of the software developer’s job—which can lead to increased stress.

That’s why a psychologically safe environment is important. 

The term coined by Amy Edmondson describes the kind of environment that can, among other things, improve developer velocity.

Google also identified creating a safe culture as one of the factors that can contribute to productivity.

Their research concluded that the safer the employees feel, the more likely they are to use their teammates’ diverse ideas, which results in bringing in more revenue, and being twice as effective.

In other words, thanks to an environment in which they feel safe, they can deliver great results quickly.

Product managers are responsible for the project’s business side. Although they usually don’t meddle in the technical part, their decisions can impact the performance of software developers.

According to ProductTank’s Martin Ericsson, a product manager is, above all else, a business function. 

However, they should also have enough technical knowledge to know how developers work and what they need to build a product.

In addition, they should have a user experience in mind—in other words, be the user’s voice during development.

As you can see in Ericsson’s diagram above, product managers are at the intersection of those three areas.

As tech influencer Neil Green points out, if a product manager isn’t competent, that can significantly influence the work process.

On the other hand, having a competent product manager can make all the difference.

Someone who has the business, technical, and UX knowledge that allows them to collaborate well with developers can be a big boost to developer velocity.

Your developers can benefit a lot from your decision to invest in talent management.

Talent management encompasses various practices from the recruitment and onboarding phase through learning and development, succession planning, etc. 

However, in the context of improving developer productivity, performance management is an element of talent management that should interest you the most.

As the name suggests, it can be very beneficial in identifying elements for improving overall performance, including developer velocity.

Performance management tools like BambooHR can make that easier.

With the amount of data it collects, it’s simple to oversee the performance of the developers and provide them frequent feedback.

That leads to more developer engagement and a better sense of how they’re performing daily—certainly much better than waiting for the annual performance review.

Investing in talent management tools like that can make improving developer velocity a much less complex task. Don’t miss that opportunity!

We hope this article showed you that developer velocity is worth investing time and effort into.

It’s a great way to measure how efficient your developers are, how much value they’re providing to users, and, last but not least, if there is room for improvement.

When you know what developer velocity is, why it’s essential, how to measure it, what can negatively impact it, and what to do to improve it, you can start building an impressive software development team.

What are you waiting for?