Is development velocity reliable? How to measure & optimize it 

Table of Contents
Share the article with your friends
One way to measure your developer's performance is through development velocity. How much work can he complete per sprint? Yet, many things can intervene in the process and slow it down. If the velocity isn't reliable, why is it still relevant? What does a slow software development velocity represent & how do you optimize it?   

What is software development velocity & Why you most likely get It wrong

In software development, velocity is a metric to calculate how much work a development team finishes in a given time frame based on prior similar projects. There’s no specific formula for development velocity. It’s primarily based on prediction.  

Each team and project will have a different velocity, as well as ways to measure it (which we will learn about later on).  

Despite being an excellent metric for project planning and estimating a project’s deadline, velocity can be manipulated. For instance, your developer might exaggerate that he needs 5 hours to finish a task when he only needs 3. This can make the stats look better, and the manager will probably think he’s doing great.  

A high development velocity doesn’t mean someone is more productive. Therefore, we don’t recommend using development velocity as a performance metric or comparing between teams, as it puts unnecessary pressure on your team. They might trade some quality work to keep their velocity. 

Why managers should still care about development velocity?

Set aside all the controversy of developer velocity; it’s still a decent sidekick for team leaders or CTOs during project planning and management. It can make delivery dates more predictable, allowing the organization to prioritize tasks and milestones while setting the right expectations.   

Velocity can be defined as a unit of work divided by time. The greater the number, the more milestones you can achieve in a particular period. (But once again, keep in mind that a lot of factors can make your development time longer or shorter; it’s not the only matter of skillset or productivity) 

The impact of High development velocity. Source: McKinsey
The impact of High development velocity. Source: McKinsey

Other than estimating your sprint timelines, you can also use development velocity for: 

  • Flexibly adjust your scope and timelines based on actual team performance: If your velocity is unusually low, maybe your deadline or project scope is too ambitious?  Using velocity metrics to establish realistic expectations, avoiding burnout in your dev team. 
  • Diagnose SDLC Process Inefficiencies: In complex software projects that require cross-platform integration, developers and QA teams may make several mistakes during production. You can use velocity metrics to find these loopholes. 
  • A sign of burnout: Although developer velocity shouldn’t be used for performance review, when the number is too low, it can still be a sign your developer is struggling. 

Other cause that leads to slow developer velocity:  

  • High developer turnover, often known as attrition or churn.  
  • You are having too many unproductive meetings and tasks.  
  • Inefficient workflows, insufficient code reviews, and testing automation  
  • Scope creep  
  • Infrastructure bottlenecks. 

How to measure your development velocity (the right way)

Method 1: Use metrics to identify your velocity

Since there’s no universal formula for development velocity, you can estimate it based on several metrics, such as: 

  • Story points earned every iteration (or sprint): This is the most common method if you adopt agile and scrum methodology. Unlike time-based estimates, story points consider the complexity of a task, the amount of work, and potential risks. But again, there isn’t a standard scale for this metric. Your team will discuss each story and its requirements, then assign a score before starting the project. After summing up all the completed story points, you can divide it by the number of sprints to find the velocity.   
  • Number of features delivered: Instead of using a story point, you can count the number of features or user stories completed in each sprint. However, this method only works in projects with equally balanced complexity between each feature.  
  • Lead time & Cycle time: While lead time measures the total time a task/ feature/ user story moves from ideation to fully deployed; cycle time focuses on the time it takes to do the task (meaning it doesn’t include the time the task waiting to be worked on).  
  • With lead time, you can see how quickly and adaptively your team responds to new tasks. With cycle time, you can identify the development pace and discover bottlenecks.  
  • Code churn: is the number of lines of code added, updated, or deleted at a certain time. High code churn can suggest problems with code quality, whereas low churn indicates consistent and efficient development.  
  • Release frequency: The frequency with which new software releases are deployed. Frequent releases may suggest rapid development, but infrequent releases may indicate bottlenecks or other problems.  
  • Mean time to resolution (MTTR): MTTR calculates the average time to resolve a problem. A low MTTR can imply rapid growth and good capacity to address difficulties. 

Method 2: Use Microsoft developer velocity assessment

The steps are simple: You answer questions about the current state of your project, and the application will estimate the result for you. Here’s what the assessment does for you: 

  • Each aspect has its subcategories, and the program will generate a graph for the respective score, identifying which areas need development.   
Graph
  • The tool also includes a more extensive description of each subcategory and resources for more research. 
tool

Method 3: Few questions to detect your velocity downfall

You don’t need to wait for all the numbers, and calculations to identify a slow development velocity. Sometimes, it’s pretty noticeable. Here are a few simple questions to ask yourself: 

  1. Are you getting a lot of interruptions, such as meetings, aiding engineers, and urgent code reviews?   
  1. Do you frequently revisit requirements for clarification like undefined edge situations, unforeseen design challenges, missing requirements, and scope creep?   
  1. Are you missing any resources that can help you accelerate development, such as documentation, clean code, better architecture, better tools, faster machines, and so on?   
  1. Do you frequently have to delay development because of another team or department?   
  1. Are there any issues that arise from a lack of unanimity among your team?   
  1. Does the organization hinder engineering? (Years-long backlog of technical debt)?  
  1. Do you detect a lack of drive and interest among engineers in your meetings?  
  1. Does the team want to see the results of their efforts? 

Tips to optimize your software development velocity

1. Assemble a balanced team

Having a team full of specialists and senior developers is great until nobody wants to do the easy task, and conflict starts to happen. A project includes various tasks of difficulty levels. When you have both junior and senior developers on board, every member has equal opportunities and tasks.  

Having a large team is also not a good idea. In fact, it’s one of the many reasons slowing down your development process (surprisingly? yes). It’s best to hire an adequate number of developers that you can manage, control, and optimize.  

At Synodus, we once cut down traditional roles such as Project Manager and Quality Control to optimize development resources for a client.  

Combining with agile and value-based delivery model, we successfully adopted a fast development velocity while saving 30% of the initial budget for our client, which is a staggering number for a startup at an early stage. Read the case study

2. Leveraging development & management tool

Tech teams with strong tools will outperform the others. Coding is different from 10 or 20 years ago; hundreds of tools can do tedious tasks for you. If you want to enhance development velocity, why miss out on this opportunity?  

McKinsey reported that companies that work with planning, management, development, and collaboration tools are 65% more innovative and reach 47% higher in developer satisfaction

How modern tools impact development velocity. Source: McKinsey
How modern tools impact development velocity. Source: McKinsey 

What tools or technologies should we use?

Low-code and no-code tools: With pre-built code blocks, you can skip through the tedious part and focus on demanding customization. Gartner and McKinsey are actively pushing this technology, as it proves to be a decent sidekick in enhancing development velocity and saving costs.  

Using low-code, one of our clients has an impressive velocity: finishing a task management system for 2000 users in under 10 weeks with a team of 4

Want to learn more? Discover our Low-code Services

AI: They can suggest the following lines of code, automatically test, identify bugs, deploy, and create documentation. Some notable AI tools for developers are GitHub Copilot, Tabnine, and Polycode. For more details, you can read our review of the top 15 AI tools for developers. And the sweetest part? You can combine both low-code and AI

Automation: Instead of spending hours on repetitive tasks, cut it down by simply letting the bots do it for you. Automation is mainly seen in testing, documentation, and code review, with well-known tools such as Selenium, Postman, or Sphinx.  

Project management and Collaboration tools: What’s a better way to keep track of what your teammate is doing, how the project progresses, and what needs to be done next than a centralized management system? Some of the tools you can use are Jira, Slack, or Microsoft Teams

3. Better product lifecycle management with CI/CD

For big tech teams, integrating DevOps practices such as CI/CD can be the key to fast development velocity. It allows developers to build and deploy new code more frequently and reliably.  

While continuous integration ensures that every new line of code is automatically tested and merged into a shared repository, continuous delivery automates code deployment to production environments. This results in a faster development cycle and quicker feedback loops. 

4. Metric-driven approach to your team’s well-being

Another way to look at velocity is through the lens of your developer’s mental state and well-being. Ultimately, a happy and motivated employee brings better results than an overworked and burned-out one.  

To accelerate the development velocity, you must create a safe and thriving environment to empower your developer. And here’s what to look into:  

  • Developer Engagement Score: DES calculates and uses qualitative assessments such as surveys to estimate how connected and motivated your engineering staff is with the project.  
  • Developer retention and churn: With 12,9%, the tech industry has among the highest churn rates. Low retention means you are losing your people, wasting more resources on hiring and training without certainty that they will stay with you long enough to finally get a positive turnover. High retention and low churn are ideal, and you can easily attain this by investing in workplace experience, employee well-being, and clear career development.  
ow positive workplace impacts development velocity. Source: McKinsey.
How positive workplace impacts development velocity. Source: McKinsey

Improving these metrics also enhances the future project’s outcome and encourages your developer to stay with the business longer. 

5. Offer space for experiment, failure, and learning

Creating a culture of experimentation and continuous learning helps increase developer velocity by encouraging innovation and the adoption of more efficient practices. Here’s how to cultivate such a culture.   

  • Help team members pursue their expertise by attending conferences, taking online courses, or investigating new technology. 
  • Empower developers to take risks and try out new ideas, even if they fail. Make sure you view failure as an opportunity for learning and progress rather than a source of blame or punishment.   
  • Encourage team members to share their learnings and experiences. 

As Mckinsey reported, developer velocity shouldn’t relate to agile and speed only, but also “unleashing the full potential of development talent.” 

Wrapping up

Development velocity shouldn’t be used to compare between teams or individuals, but it excels in project planning and management. With the right approach, high-velocity companies in software development are doing much better than others in innovation, adaptiveness, and business results. 

More related posts from Software Development blog blog you shouldn’t skip:

How useful was this post?

Click on a star to rate it!

Average rating / 5. Vote count:

No votes so far! Be the first to rate this post.

Recent posts
Subscribe to newsletter & Get update and news
We use cookies to bring the best personalized experience for you. By clicking “Accept” below, you agree to our use of cookies as described in the Cookie policy