What is Developer Velocity & How To Improve It (The Friendly Way)

Ah, developer velocity… such a misunderstood term yet widely used by team leads, project managers, CIOs, CTOs, and anyone in between.

If you ask a software developer to define it, they’ll probably say something like “software development velocity is a mystical art of packing enough code into a day to call it productive”.

If you ask a project manager the same thing, they'll probably answer with “a dance of juggling deadlines and never-ending feature requests”.

If you ask a CTO to define it, they’ll probably suggest “it feels like trying to reach warp speed with a rocket made of duct tape and cotton candy”.

Everyone has their own definition of developer velocity but it’s usually tied to productivity, the desperate need to meet deadlines, and the never-ending list of feature requests.

But in all seriousness, developer velocity is a measurement that shows a development team can keep up with the market’s demands; that it’s customer-centric and focused on delivering innovative solutions.

And now more than ever, with all the disruptions in the IT sector, such as high employee turnover rate and rising inflation, developers are encouraged to amp up this measurement.

But why is developer velocity so critical? And what makes it so intriguing?

In this article, we’ll define the term, how it’s measured, why it should be measured and一most importantly一 how to improve it without micromanaging or being a nag.

Let’s get to it.

What is software development velocity?

Well, here are a few definitions of this term:

• Development velocity measures how much work developers can complete in a particular time frame.
• It’s an estimate of the amount of work done in a timeframe.
• It’s a measure of the efficiency with which software developers create and deploy high-quality code.

And these definitions have three things in common:

1. They suggest developer velocity is a measurement.
2. They take into account the amount of work done by software developers.
3. They indicate a timeframe, as the work needs to be completed within a particular period.

So, in simpler words, developer velocity measures the speed of project releases.

Why do teams track development velocity?

A short answer is that it helps them define a predictable timeline for delivering a project. The higher the measurement, the better.

Development velocity is a tool that helps development teams achieve efficiency. The higher the developer velocity, the quicker the products and features will be delivered. And if a company thrives on increased software development velocity it probably has a competitive edge in the market.

High development velocity also leads to greater adaptability. Whenever customer requirements change, high velocity teams are ready to make pivotal decisions and iterate on a product.

High velocity and reduced development time lead to cost savings for organizations, allowing companies to allocate their resources to other parts of the business, ultimately driving more revenue.

Another benefit of high development velocity is that it improves a team’s experience (which also creates a competitive edge). It supports honest communication and collaboration within teams, leading to a more innovative approach to problem-solving. And if a team is efficient, it has time to experiment. Sometimes, those experiments lead to innovative processes and features, sometimes they lead to learning from mistakes. Either way, it’s a win-win situation.

How to measure development velocity

Measuring developer velocity involves tracking the speed of task completion, stories, or features.

There are a number of metrics that can be used to track development velocity and you should choose the one that aligns with your project’s goals the best.

Here are some common metrics used to measure software development velocity:

• Story points. Story points represent the effort a developer needs to put in to complete a user story, deliverable or task.
• The number of features. It is advisable you track the number of features delivered in each iteration or sprint.
• Cycle time. Cycle time measures how long it takes to move a task or story from the start of the development process, a cycle, to the end, to its completion.
• MTTR (Mean Time To Resolution). MTTR measures the average time it takes for developers to resolve a bug or a problem.
• Code churn. Code churn represents the number of code lines added, deleted or modified during a specific time frame. The lower code churn, the more stable a code is.
• Frequency in release. Frequent releases may indicate a high development velocity.

Is development velocity a measurement of teams’ productivity?

Yes, but it shouldn’t be. And here’s why.

Let’s start by explaining how Scrum teams usually measure development velocity.

They most commonly use story points. Here’s how the process goes:

1. Team members section a backlog of features into smaller tasks一deliverables.
2. Then, team members individually and secretly assign a number, a user story point to each of these deliverables. Team members use their individual judgment to estimate how much time a deliverable would take to complete.
3. Team members base their predictions on past experiences.
4. Team members reveal the numbers of each story point assigned to the deliverables, discussing the reasons.
5. They agree on common criteria to assign a number to each of the deliverables, slowly creating the backlog of features.
6. Team members create a timeline for delivering each of the backlog features.

Here’s what I mean.

Imagine you have two teams.

The first team consists of three junior developers. The second one has two seniors.

In a team of not-so-experienced developers, story points will be higher. And vice versa, senior developers will give tasks low points because they find them easier to achieve. But the amount of work remains the same, it’s not changing. That’s why you shouldn’t use developer velocity as a productivity measure, nor should you use it to compare developers individually.

What can slow down software development velocity?

There are many reasons why a team has a low development velocity. Some of them are:

• High developer turnover
• Challenges with team coordination
• Complex organizational structure
• Meeting creep
• Scope creep
• Inadequate code reviews and testing
• Technical debt
• Relying on external teams or third-party services & systems
• Regulatory & compliance requirements
• Lack of training to support innovation

How to improve development velocity in three quick ways

There are a few ways to boost development velocity immediately. Here they are.

#1 Foster innovation culture

Software development isn’t about sitting 8+ hours behind a desk and writing flawless code or fixing spaghetti code; it’s about problem-solving, experimentation, failing, and learning from mistakes.

And if you take a step back to look at the bigger picture, you’ll see that I’m right: the best way to create a solution is to experiment and take risks. And sure一with taking a risk comes failure but that’s how the best, most innovative ideas are born. They rise like the Phoenix from the ashes.

So, to avoid low developer velocity, invest in systems and tools that minimize the cost of failures. Here’s how you can do so:

#2 Remove technical debt

Technical debt or code debt suggests prioritizing prompt delivery of a solution over perfect code. Team leads usually compromise on the quality features and functionality to speed up the delivery, ending up with a solution with suboptimal performance.

Although it might seem like a good idea to prioritize speed over sublimity, this “let’s build now and fix later” mentality doesn’t do any good. To anyone.

In terms of developer velocity, it hinders it. Because not only are developers asked to work on a poor solution, they often have to work on it without proper planning and documentation. Which requires even more time for fixing all the bugs.

The result of technical debt? A frustrated team of developers with zero motivation.

So, instead of shipping a not-quite-right code and calling it a day, try to reduce the possibility of having a faulty solution by investing in new tools and automation software.

#3 Allow developers to use tools they like

Tools to developers are like spices to a chef; without the right spices, everything tastes bland, but with too much, you end up just being confused and spitting out food.

Consequently, one can say that tools are the foundation of developers’ productivity and velocity.

And the stats show that developers use all kinds of tools for source code collaboration, issue tracking, code review, etc. All these tools are essential for planning, development and collaboration but if there are too many of them or if some of them don’t quite do the job, you can’t expect developer velocity to rise over time.

So, when it comes to choosing the right tools, please allow your (senior) developers to make a choice for themselves. Discuss which tools they would recommend and introduce them across your teams. Doing this step will show them you value developers’ knowledge and input, leaving them feeling valued and appreciated.

#4 Introduce efficient time tracking

From all the previously mentioned, we can agree that the basis of development velocity lies in accurate estimation which requires sufficient experience with estimation.

When we talk about estimation, we think of the time in which a feature will be completed, or how long it will take to fix bugs, etc.

When we discuss experience, it’s important to note that even the more seasoned developers can’t make an estimation with 100% accuracy. They usually guesstimate and are good at it, thanks to years of experience in software development.

But what if there was a way to transform all those guesstimes into estimates based on real time tracking data?

With Memtime, it’s possible, as it makes developer time tracking safe and automated.

Memtime runs in the background 24/7, capturing all activities within programs down to the second. It shows your time in programs visualized in 1-60 minute intervals.

Once you see what you’ve worked on, you can turn captured activities into time entries, and by integrating Memtime with your project management software, you can assign those time entries to tasks. That way, you’ll know EXACTLY how much time it takes to complete each task. It’s that quick’n’easy.

Note: Memtime is NOT an employee monitoring tool. We don't support employee monitoring. Our app is highly rated & used by multiple IT teams across the globe.

Befriend software development velocity

… and it will return you more than you expect. Literally, high development velocity will increase your company’s ROI. 🙂

But more importantly, high development velocity is an indicator of the health of your team and software projects.

It predicts product releases, keeping your software development team feeling accomplished, satisfied, and eager to take on new projects.

And in the quest to skyrocket developer velocity, give Memtime a go.

If you run a team of software developers, opt for our team trial by booking a call with us. It’ll get you:

And to wrap it up:

May your code compile as promptly as Usain Bolt sprints.

May your debugging sessions be shorter than an average human blink (0.4 seconds).

And may your deployments glide through production like ice cream down the throat.

Wishing you all the success in your developer velocity journey!