Measuring Development Velocity (While Balanacing Reliability)

Wondering about development velocity? We explain what development velocity is, how to measure it, and how to balance the need for fast development and reliable products.

What is Development Velocity?

Development velocity is a measurement of how much work a software team can complete, based on similar work completed in previous iterations.

‍

Development velocity is a controversial metric and is easy to manipulate. In many scenarios, inaccuracies will happen. Here are a few:

‍

• Inflated velocity: a scenario where the development team gives higher time estimates (four hours instead of one) resulting in their stats looking good. Velocity shouldn’t be used as a performance metric as higher velocity does not indicate better performance. 
• Code quality: velocity does not take code quality or user experience into account. Simply put, it’s about completing tasks even while ignoring coding standards or good design.
• Measure of work done: while it’s often misused as a measure of team performance or efficiency, velocity is the measure of work done. Velocity increases even if you develop a feature that no one uses, add new team members, or work overtime. 

‍

In order for development velocity to be a meaningful metric for understanding your team’s progress and the effectiveness of your processes, you need to avoid these inaccuracies.

‍

The ultimate goal of every organization is to balance the development velocity with service reliability. 

How to Measure/Calculate Development Velocity?

Velocity is the sum of all effort points of the items that are finalized at the end of each sprint. Sprints are a component of Agile development, where points are assigned based on how much effort a task takes. It’s generally measured in units of work completed by a team in a given time. Incomplete or partially complete units of work are not taken into account when measuring velocity. 

‍

In velocity measurements, we consider two metrics, units of work and time frame. There are three ways you can measure units of work:

‍

• Engineer hours 
• User stories
• Story points

‍

Time frame can also be measured in three ways:

‍

• Sprints
• Iterations 
• Weeks 

‍

Important: in velocity measurements, consistency is the key. Whichever way you choose to measure velocity should remain the same moving forward. 

Best Practices to Improve Development Velocity of Your Team 

Empower Your Developers with Tools

Developers love new tools and technologies. They can also significantly increase your team’s productivity and development velocity. According to a report by McKinsey and Company, organizations that have strong tools for planning, development, collaboration, and CI/CD are 65% more innovative than bottom-quartile companies. 

‍

To make the most out of tools, let your developers choose their tools but restrict ad-hoc tools to avoid inefficiencies and redundancies. Leading companies are also investing in low-code and no-code platforms. They allow business users to easily build applications and the developers can focus on more challenging tasks. 

‍

Here are a few tools that can help you improve development velocity:

‍

• Planning tools
• Collaboration tools
• Development tools
• DevOps tools
• Low-code or no-code platforms 
• Test automation
• Infrastructure as a service (IaaS)
• AI assistants
• Public cloud 

Foster a Culture of Experimentation

You can never find what works best for your team if you don’t experiment. Instead of micromanaging your developers, foster a culture of experimentation. Encourage your developers to experiment, fail, learn from their mistakes, and try again. Instead of pointing fingers, take the blameless approach to use failure as an opportunity to improve. 

‍

To avoid any setbacks, try minimizing the impact of failures via controlled releases, automated rollbacks, and feature flags. Conduct blameless retrospectives (also known as postmortems) to reflect on incidents by asking the “what, why, and how” questions. Remember that failure is inevitable, but there’s much you can do about it. 

Build a Diverse and Balanced Team 

Having a diverse and balanced team is key to improving the development velocity of your team. Without balance, your team’s productivity will suffer even if you have amazing developers.

‍

Here’s why you need a balanced team:

‍

• In a strong team with many senior and experienced developers, there will likely be many strong opinions and debates. There are many approaches to doing something, and with too much debate, you often end up implementing complex solutions to simple problems. 
• In a weak team with mostly junior developers, the timeline will suffer because of their lack of experience and skillset. Not only will junior developers take longer to solve certain problems, but they’ll also likely make more errors as they do.
• In an average team with developers that are not very junior or very senior, the velocity will suffer because the developers will get stuck on many problems that require the expertise of a very senior developer.

‍

The best team is one that is composed of all types of developers i.e. senior, junior, and average developers. In a team of six developers, consider hiring two junior, two senior, and two average developers. Regardless of the project, you will be able to assign tasks easily depending on the developer’s experience.

Manage Technical Debt

One thing that immensely impacts the development velocity is technical debt. Technical debt is inevitable in any growing system, and grows faster when teams take shortcuts in development. It causes issues for the team later when they have to spend extra time and effort fixing bugs from the past caused due to improper planning and documentation. If the development team prioritizes velocity over quality, then they will attain mounds of technical debt over time. Fixing the same issue multiple times over causes frustration and impacts team morale. 

‍

You can reduce technical debt by:

‍

• Defining and keeping track of it.
• Prioritizing code debt tasks instead of procrastinating. 
• Setting up and following good coding practices and standards.
• Conducting code refactoring – restructuring existing code without changing external behavior. 

Take a CI/CD Approach to Software Development

To deliver the best product faster, you need to devote equal resources to development and deployment. Developing a product faster won’t matter if you take weeks or months to deploy. 

‍

One of the biggest software development challenges is to deliver value to the end-users, and the key to high development velocity is DevOps. DevOps uses the CI/CD (continuous integration and continuous deployment) approach to build, test, and deploy code faster. It makes use of automation to make the development and deployment process seamless. The goal is to deliver a more reliable product faster to the end-users.

‍

Here are a few CI/CD best practices to implement:

‍

• Deploy code more frequently in smaller chunks 
• Automate the unit testing procedure. 
• Use trunk-based development (source-control development model where developers collaborate on a single branch called trunk) to avoid merge hell.
• Rely more on automation. 
• Prioritize fixing bugs and broken builds.

Align Goals with the Other Teams

The software development process works the best when everyone’s goals are aligned. If one team is focused on something different from the other, then the friction between the two teams can fall out of sync and can get stuck in a bottleneck situation.

‍

The best way to align goals is by using error budgets and SLOs (service level objectives). For every business, customer satisfaction is the most important metric, and the SLO, SLI, and error budget keep everyone focused on what really matters – the customer. 

How Does Development Velocity Relate to Reliability?

In today's world, trends are changing every day, and to keep up with the pace, you need to change along with it. The relationship between reliability and velocity is complicated. If you focus on reliability beyond what users will notice, then velocity can be compromised. If you roll out features as fast as possible, then the code will be more prone to having errors. 

‍

That's where SRE (site reliability engineering) comes in. SRE is a set of practices that are employed by organizations from start ups to industry leaders such as Google to improve the reliability of their services. It fills the gaps between the development and operations teams by bringing down organization silos and shared ownership.

‍

The SRE team comprises software engineers whose goal is to improve their service's reliability. They also keep track of the error budget and service level metrics to ensure they aren’t breached, and make strategic decisions on when to accelerate development.

How Does Error Budget Relate to Development Velocity?

An error budget is just like your house budget. It sets the amount of unreliability that a service can afford before making the customers unhappy. Just like your house budget, you can spend the error budget as long as you don't overspend.

‍

The development team is always keen to roll out changes and add new features to the product. However, change always brings some instability, and error budgets work as a control mechanism to divert attention towards reliability as needed. With an error budget, you're less likely to go after velocity at the expense of reliability or vice versa.  

‍

Error budgets can help the development team navigate and eventually increase their development velocity. If they're spending too much of their error budget, then it's an indication that they need to slow down and focus more on reliability. On the other hand, they can take more risks and roll updates more quickly if they're well above the target uptime.

How Does SLA/SLO/SLI Relate to Development Velocity?

In SRE, three primary metrics – SLA, SLI, and SLO are used to measure the reliability and availability of a service. 

‍

SLO (service reliability objective) is a reliability target that represents customer happiness and guides the development velocity.

‍

SLI (service level indicator) is a metric that defines a service's health over time and is often used to determine whether the SLOs are met.

‍

SLA (service level agreement) is a formal agreement between the customer and service provider that outlines the repercussions of failure. 

‍

The three metrics are communicated across every level of the organization from developers to VPs. Defining these metrics and sharing them across various teams can result in everything sharing the same goal. The ability to adjust these thresholds over time is necessary to adapt to changing business goals and needs.

How Can Blameless Help You Balance Reliability and Development Velocity?

For any organization, keeping the balance between reliability and development velocity is a big challenge. Without change, you can't innovate and with change comes instability. Blameless is an SRE platform that helps teams through incidents and retrospectives by capturing data and finding interesting patterns. We offer many tools including incident resolution, reliability insights, SLO manager, incident retrospective, and integrations to help you on your reliability journey. To learn more, request a demo or sign up for the newsletter below.