What is Velocity Debt?

All Posts
Share this post
Share this post

A team’s velocity is their ability to deliver value over time. Managers often use velocity as a key performance indicator (KPI) to assess team performance.

Velocity measurements show whether a team is consistent and if they are improving over time.

The problem with using it as a KPI, however, is that velocity doesn’t tell you what is holding your team back or why.

Your team could be burdened with significant internal overhead, yet still showing a stable velocity. To truly tell how a team is doing, we need a better metric.

Velocity Debt Defined

Velocity debt is anything that prevents teams from spending their time creating value for customers.

Velocity = Capacity - Velocity Debt Cost

Velocity debt It is a silent killer, sucking up time and energy on activities that may not show up on sprint reports.

Teams accumulate velocity debt as they grow, sometimes starving value-adding work entirely. It is not uncommon for teams to waste over 50% of their time on velocity debt.

The Human Cost of Velocity Debt

As its name indicates, velocity debt slows down your velocity, but it also impacts team morale.

Engineers want to spend their time building things, not wading through bureaucratic stumbling-blocks. Teams laden with velocity debt have lower happiness, higher attrition, and drive away talent.

On the other hand, nothing makes people more productive than job satisfaction. If you remove the impediments and roadblocks created by velocity debt, your team will take care of the rest.

Velocity Debt vs. Technical Debt

Anyone who works with software has heard the term technical debt, which is a deficiency that makes software more difficult to modify and maintain.

While technical debt is one component of velocity debt that gets a lot of attention, there are others that can have a big impact and are important to consider. Velocity debt also includes things like inefficient meetings, interruptions from external requests, merge conflicts, and more.

People sometimes refer to other persistent impediments as “process debt”, “managerial debt”, etc. Velocity debt encompasses all of these concepts together.

Types of Velocity Debt

There are a lot of things that can interfere with software development, but they tend to fall in the following high-level categories based on where people spend time:

  1. Non-Coding Time - Time spent on non-value-adding activities entirely outside of writing code. It includes all manner of “corporate” overhead like filling out expense reports, as well as unnecessary meetings and other interruptions like answering questions from outside the team.
  2. Unticketed Time - Time spent writing code, but the code is untraceable to any tracked task. This often represents urgent hot-fixes, merge conflicts, inefficient deployment processes, or simply a lack of ticket tracking.
  3. Off-Sprint Time - Time going toward coding for a tracked ticket that wasn’t planned as part of a sprint. The type of velocity debt depends on the nature of the ticket, but this may represent urgent bugs, incident response, or other unplanned maintenance, which could be caused by lack of test automation or other technical debt.
  4. Incomplete Task Time - Time spent on tasks that do not complete within the boundaries of a single sprint may not entirely go to waste, but it is less efficient because it delays time to value and has greater risk of merge conflicts or abandonment. This may be caused by issues with the tasks themselves, or by problems with earlier tasks or unexpected general overhead that prevented them from wrapping up by the end of the sprint.
  5. Underestimated Tasks - Tasks that took more time than expected may have had an incorrect estimate or encountered some unforeseeable hurdle. Even if a task couldn’t have directly gone faster by eliminating velocity debt, the fact that it was underestimated can detract from velocity by interfering with plans for later tasks.
  6. Planned Bug Fix and Maintenance Tasks - These are tasks required to keep the software functioning in its existing state that detract from new feature development.

Strategies for Measuring Velocity Debt

There are a few different approaches for getting a handle on how much your team suffers from velocity debt.

Surveying

One method is just to ask each team member to approximate the percentage of time they spent on value-adding development vs. other activities each sprint. The nice thing about this approach is that it is easy to get started.

A downside of surveying is that it requires manual effort. The more serious problem, however, is that people have a strong availability bias, which causes them to remember the things that felt frustrating, while not considering velocity debt that has become a normal part of how things are done (e.g., we always have to spend a day fixing merge conflicts at the end of each sprint).

Time Tracking

Another way to measure velocity debt is to ask people to log all of their time with a time tracking system. This eliminates availability bias because you are not asking people to remember anything.

One issue with time tracking is that the manual effort required is more significant than for surveys, which ironically creates more velocity debt.

More importantly though, time tracking is still limited by human judgment and has limitations on its granularity. Are people going to stop the clock on their task and start it on “Slack interruption” to answer a quick question? They probably won’t, which means a lot of velocity debt will continue to fly under the radar.

In-House Data Analysis

The most accurate, granular information about velocity debt comes from the artifacts people leave behind in version control, ticketing, and communication systems as they build software.

For large organizations with vast data engineering and analysis resources, it might make sense to gather all this information into a data warehouse to help identify activity that stifles team velocity.

The obvious downside here is that ingesting and analyzing this data is a complex undertaking, and not many organizations actually have vast data engineering and analysis resources.

Velocity Debt Management System

A velocity debt management system like minware handles all the complexities of pulling data from various APIs, analyzing timing artifacts, and enriching events to provide a comprehensive picture of where people spent their time, along with how much was taken away by non-value-adding activities.

This approach provides the power of in-house data analysis at a fraction of the cost.

Here you can see how minware computes overall time ratios and lets you drill down into individual velocity debt activities. This example shows an 8-person team that spent only 37% of their time on completed tasks in a particular 2-week sprint.

minware Velocity Debt Figure

Velocity Debt Value Calculation

Once you have measured the level of effort that goes toward paying “interest,” you can model the monetary amount of velocity debt – that is, how much you should be willing to pay to eliminate it. The formula is as follows:

Velocity Debt Amount (V) = Annual Team Salary (S) × Opportunity Cost Ratio (O) × % Velocity Debt Overhead (D) / Discount Rate (R)

Here is an explanation of the terms in the formula:

  • Annual Team Salary (S) - Your total out-of-pocket expense for the team including all benefits, office space, etc.
  • Opportunity Cost Ratio (O) - The amount of value you’d expect someone to produce for the organization per dollar of salary, which will be more than their salary to make hiring worthwhile. A typical value is 3, but it may be much higher if a company is growing quickly.
  • Velocity Debt Overhead (D) - The percentage of time spent by the team that could be redirected from velocity debt to developing valuable functionality for customers.
  • Discount Rate (R) - What amount would your organization be expected to return on a capital investment? Typical values here are 15-25%, but can be much higher for risky start-ups (which decreases the value of fixing velocity debt).

To understand how the formula works, imagine that you took out a $1m loan with an interest rate of 15%, which costs $150,000 annually. You then turn around and pay this $1m to consultants who magically fix some velocity debt that is taking up 10% of your team’s time each sprint.

The team is paid $500,000 annually, so you just freed up time that was costing you $50,000. Given your organization’s estimated opportunity cost of 3x for engineers, you expect this to generate $150,000 annually in value for the company, thus breaking even:

$1,000,000 (V) = $500,000 (S) × 3 (O) × 10% (D) / 15% (R)

As you can see, the value and cost you should be willing to pay to fix modest amounts of velocity debt can be immense. This model also doesn’t include the human cost, so if you factor in the risk of losing your highest performers, the value can be even greater.

The Bottom Line

While many teams assess performance by tracking velocity, few are able to say how much velocity they lose to non-value adding activities.

By analyzing the cost of velocity debt, teams can identify and prioritize changes that will improve their speed, predictability, and overall happiness.

Velocity debt tracking is easy to get started with surveys, and teams interested in diving deeper can quickly ramp up to comprehensive velocity debt management with minware.

The cost of not managing velocity debt can be quite high and manifest in unexpected ways like team attrition. Product and engineering leaders can get ahead by forming a velocity debt management strategy to help improve their team’s speed, predictability, and overall happiness.

Engineers First
Measure the business impact of things that slow down engineering