What is Software Development Velocity and How to Improve it?

Are you too feeling the heat of the economic downturn, and the heightened pressure to innovate more with less, and amp your development velocity? Yes? 

Well, you’re not alone. 83% of your peer CIOs, CTOs, and engineering managers confess to feeling the burn.

Engineering top brass often make the case for higher IT budgets, and in return, they are being asked for quick & consistent value delivery to the end customers.  But if only these barter trades were that simple. There are challenges.

Gartner reported-

• 59% of digital initiatives take longer time to complete than what CIOs expect.

• 52% take way too long to deliver the expected value. 

You may wonder, “What’s slowing down innovation?”

• 72% of engineering heads admit technical debt as one of the biggest barriers slowing down their digital transformation initiatives.

• 51% also quoted legacy infrastructure as another big challenge to agility & innovation.

With economic pendulum shifting sides; rising inflation and cloud costs, talent churn, and technological disruptions thumping the IT doors, if you have to outperform the market, improve the customer experience, accelerate innovation-led value delivery, and maximize the positive impact you create— you need to measure, analyze, and optimize development velocity.

Why?

Well, read this insight as we discuss development velocity in detail. For brevity, we have linked to a lot of useful related insights in between. Here, we discuss the following-

• What’s development velocity? 

• How to measure development velocity?

• Why is it important for engineering teams?

• What slows down software development velocity?

• How to improve development velocity?

What is Development Velocity?

Software development velocity is an estimate of the amount of work done over a period of time. 

In simpler words, it is a measure of how fast backlog items, aka new features, are released. For agile practitioners, particularly Scrum teams, development velocity is the average number of story points delivered per sprint. It’s a metric that quantifies the rate of work completion. 

Teams track development velocity because it helps them to come up with a predictable timeline for delivering the project. 

But there is a catch. 

People mistake development velocity as a measure of a team’s performance. It’s not. The confusion is inevitable thanks to the words like ‘velocity’, ‘speed’, and ‘fast’, which we use to define Development Velocity.

To avoid confusion it is important to understand how development velocity gets calculated.

How to Measure Development Velocity?

In our Hatica Insight on velocity metrics for engineering efficiency, we have explained the Planning Poker story point estimation method for measuring development velocity. If you read that blog, you’ll understand-

• Teams divide backlog features into unit-sized deliverables.

• Members individually and secretly assign a number (story point) to each of these deliverables. The story points are in the range 1-13, and reflect an individual’s judgement on how complex it would be to develop it. Of course, these predictions are based on their past experiences of developing similar application modules.

• Next, team members reveal the numbers they have assigned to the deliverables, and discuss the reasons. Then they agree on common criteria (either mean, median, or mode of the story points) to assign a specific story point to each of the deliverable units, and subsequently to the backlog features.

• Lastly, based on how long it took to deliver a feature with a similar net story point, a timeline is predicted for delivering each of the backlog items.

If you observed, the story point-based approach is subjective in nature. Thus, you shouldn’t use it as a performance metric.

Note: Development velocity is not a performance metric

Let’s say a team of 2 senior developers and 5 junior developers estimates backlog items to a median score of 12 and a total sprint story points of 30 for 4 backlog items. 

Now, take a team of 4 senior developers and 2 junior developers. They may estimate a relatively lower median score for the same backlog items. Maybe 7 for the first backlog item. And net 21 story points for the same 4 backlog items. This is a possibility because the experienced developers would find it comparatively easier to accomplish the same task. And thus, they will assign lower story points.

If you analyze, the work remains the same but the story points you deliver per sprint are higher for a relatively inexperienced team. Of course, this doesn’t mean, they are doing more work. Therefore, Development Velocity shouldn’t ever be used to benchmark team performance or compare teams.

Curious about the right way to use development velocity? Well, here’s a Hatica Insight on effectively using Velocity Metrics.

Why is Development Velocity Important for Engineering Teams?

Software release predictability matters as much as software stability. Developer Velocity is your metric to rely on for

• Predicting a feasible software delivery timeline

• Set realistic expectations for the stakeholders, and

• Expose inefficiencies and bottlenecks in software development lifecycle processes.

There is a popular saying, “If you can’t measure it, you can’t improve it”. 

Analyzing what the team committed to, their actual development velocity, and the velocity in earlier sprints, you can get reassurance if the teams are performing at par with the expected performance levels. 

Any significant variance from development velocity highlights engineering inefficiencies. It would mean that either the development velocity estimation methodology was flawed, or there exists some sort of development bottleneck(s).

Is Slow Development Velocity a Problem?

For instance, let’s say the development velocity is 30% slower than what was estimated. Now chances are–

• The project modules turned out to be more complex than what the team expected.

• The project is plagued with scope creep, aka frequent change requests.

• Development team has toolchain, infrastructure, resources, or process barriers.

This could be a starting point for engineering managers to diagnose what’s crippling the project and the team.

What Slows Down Software Development Velocity?

There could be a lot of reasons contributing to an agonizingly slow development velocity-

• Developer turnover, aka attrition, or churn 

• Standups, unproductive meetings, and low maker time

• Inefficient workflows— Inadequate code reviews, insufficient testing automation

• Scope creep— change requests, fudgy requirements, undefined edge cases

• Infrastructure bottlenecks— Not using CI/CD pipeline tools, not embracing DevOps, GitOps & IaC

• Technical debt

• Dependencies on external teams, third-party services & systems

• Regulatory & compliance requirements

In short, anything that hinders developer productivity would slow down development velocity.

How to Improve Development Velocity?

First, in order to improve development velocity, you need an engineering analytics tool (say Hi to Hatica) that gels with your project management, communication, and engineering tools stack.

In general, either one or more of the tools, culture, project management, or talent management problems are the precursors of high deviations in development velocity. Whatever it may be, Hatica is your hammer to smash away all the blockers curtailing the development velocity of your engineering team(s). 

Using Hatica, you can track 130+ engineering metrics that help expose any culture, management, or workflow-related loopholes. For instance, here’s how to use Cycle Time metric to improve dev velocity. 

On a high level,

• Hatica helps you aggregate data from all your work tools — Github, Jira, Jenkins, Pagerduty, Slack, Gmail, etcetera.

• It facilitates you to quantify engineering activities and gain deeper & complete visibility (understanding) into your engineering processes. The real-time reports, and dashboards contextually analyze the data mulled from your development tools.

• Cherry on the cake, using Hatica Goals, you can easily identify any deviations from the plan, and meddle the data to find the bottlenecks for your software development team.

• Subsequently, you can take measures to diagnose the identified development velocity barriers. 

1. Build A Positive Developer Experience

We shared in our blog on the DevEx framework-

“Consequences of unhappy developers include lower productivity, decreased process alignment, deviation from the best coding practices, low code quality, broken flow state, and decreased communication and collaboration.” 

All of this could badly impact the development velocity. What can you do to mitigate this?

• Empathize with the struggles of a software developer. Provide them with a conducive development environment-

• Help developers establish streamlined development workflows by equipping them with the right tools & processes for all the stages of SDLC. Especially, development, debugging, and deployment tools.

• Invest in good developer communication & collaboration tools.

• Define consistent coding standards across the organization.

You can optimize every single touchpoint to keep your developers happy— from developer interviews & onboarding to developer relieving, you can ensure a delightful experience for your engineers by adhering to the 3D DevEx framework. Read our Hatica blog on 3D DevEx Framework, and understand which engineering metrics to track & how to optimize them for enhancing developer experience  (DevEx).

2. Gift a Potent AI-powered Toolstack to Your Engineering Team

• 60% of developers voted salary makes them happy

• 58% chose work-life balance, and

• 52% said being productive is a key driver of developer happiness. 

The same report also revealed that being unproductive is the #1 reason that makes most developers unhappy. A staggering 45% of developers dislike it.

Also, according to a research paper, GitHub CoPilot users complete a task 55.8% faster than their counterparts with no access to AI code generators. That’s 55% better productivity!

In fact, McKinsey found in its research “...best-in-class tools are the primary driver of Developer Velocity”. They also found out that organizations that invest in top-notch tools also have 47% higher employee retention rates compared to the rest.

They continued, “Organizations with strong tools—for planning, development (for example, integrated development environments), collaboration, and continuous integration and delivery—are 65% more innovative…”. 

Well, isn’t that enough data to make our case for investing in awesome AI-powered tools to boost developer productivity, and subsequently keep development velocity aligned to the calculated release trajectory?
However, gifting AI tools isn’t enough. You also need to measure engineering KPIs. Next, analyze the signals, and accordingly take measures to optimize the metrics for maximizing developer productivity & business outcomes.

3. Engineer a Development Culture that Prioritizes Psychological Safety

Scope creep, inadequate documentation, broken communication channels, inefficient collaborations, inferior code quality, accumulating technical debt, delayed projects, shoddy reward & appraisal processes, disengaged & detached developers, and high talent churn are all symptoms of a flawed culture. They are negative catalysts to psychological safety.

You may get a better hang of your engineering culture by asking the right questions-

• Do your teams adhere to agile best practices?

• Do you follow SDLC best practices?

• Do you use DevOps & GitOps-powered SDLC workflows?

• How interoperable is your extended tech & infrastructure stack?

• Have you automated the aspects of SDLC that could be automated?

Though culture might feel like an intangible aspect of workplace dynamics, there are indicators and metrics that you can rely on to improve cultural aspects that may help improve developer velocity:

4. Use a Metric-Driven Approach to Improve Developer Velocity

Engineering metrics when measured qualitatively with context of continuous improvement can help engineering teams realize their developmental bottlenecks. Here are some productive, and non-vanity metrics that can help your team achieve soaring developer velocity:

• Developer Engagement Score (DES): DES is calculated using qualitative assessments (for example, surveys), and is a good way to measure how connected & driven your engineering team is. Happy developers innovate better & faster. So, look out for opportunities to maximize developer happiness.

• Maker Time Metrics: As per MongoDB’s report, developers are spending only 28% time on developing new features. How do you find out “how much time your developers are spending on building new features”? Simple, measure maker time metrics. In fact, the hallmark of high-performing engineering teams is their ability to maximize maker time for their developers. Optimizing maker time unlocks the full potential of software developers. It helps improve development velocity by allowing developers more time to work on developing backlog items rather than getting hobbled by meetings and other productivity killers.

• Developer Retention & Churn: High retention and low churn are ideal. With 12.9% attrition, the tech industry has one of the highest churn rates. Minimize churn by investing in developer experience, well-being, and growth.

• Technical Debt: 73% of the 2000+ respondents to the MongoDB survey marked technical debt as one of the top barriers to innovation.
  Normally, inefficient workflows with no strict code review, insufficient code coverage, and inadequate testing among other reasons end up accumulating huge tech debt. This forces developers to spend most of their time firefighting & repaying the crushing tech debt. Of course, it negatively influences the development velocity.

5. Fix Your Project Management Lifecycle Stages

Improving development velocity is as much about effective project management as it is about engineering tools, practices, and culture. Hatica integrates with your entire workflow toolchain and caters to all the stages involved in a project— Planning, Execution, and Review & Retrospectives. It helps you with-

• Data-driven sprint planning: You can exploit the analytical & quantitative insights (e.g., development velocity, developer workload & burnout, average maker time, ongoing projects, upcoming deadlines, etc.) from similar projects to plan sprints with precise release timelines.

• Resource-optimized project execution: Make use of engineering metrics in tandem with frameworks like DORA or SPACE to help developers unlock their best productivity levels. We’ve covered in detail about Cycle Time, Maker Time, MTTR, Deployment Frequency, Code churn, PR metrics (PR Size, PR throughput), and Code review (code readability, comments per PR, anti-patterns, code churn, bug rate) related engineering metrics. Squeeze the best out of your resources. Execute projects clinically, and accelerate value delivery.

• Doing retrospectives the right way: Retrospectives are key in agile organizations, esp to improve development velocity. It’s when you look back at what worked in favor, what went against, and what can be improved for better project execution. Retrospectives also help ensure that the project was a win-win for all stakeholders. Obviously, such exercises are fruitful when the discussions are more data-driven and evidence-based than assumptions (as bias may creep in). Here’s our take on how to organize killer sprint retrospectives.

Drive Predictability and Value with Software Development Velocity

It’s evident that development velocity is a good indicator of the health of your software projects. It helps make product release timelines more predictable. In pursuit of hitting the sweet spot of the perfect development velocity, you can uncover & fix a lot of loopholes in your SDLC workflows, including cultural aspects. Also, in this quest, Hatica could be your trustworthy ally— a linchpin. Book a free demo to see for yourself how it can help you track all the important engineering metrics, keep noise away, and provide you with actionable insights to harness the full potential of your teams & tools.

Keep accelerating value delivery!