Per my understanding, velocity is just a metric used to forecast work for future sprints, therefore it has no significance other than for planning purposes. Even if technical debt exists, my assumption is that it would get factored in when work is estimated.

I'd still like to understand if there is any relationship between technical debt and velocity, perhaps if I have missed thinking of something.


3 Answers 3



Velocity and technical debt aren't directly correlated, and velocity can't measure technical debt directly. However, velocity (when properly implemented) can act as a detective control to uncover hidden debt.

Technical debt isn't necessarily bad. Just like financial leverage, there is good debt and bad debt. Taking on debt the project can afford may be a necessary choice to meet short-term goals. It's just important to only take on debt that the project can afford, and that the team can pay back!

The main problem with technical debt is when it's invisible. CodeGnome's Law of Transparency℠ says, "No invisible work, ever!" Visible debt won't reduce your velocity, but may reduce the speed at which new features can be delivered. Invisible work will act as a drag on velocity, which is an early warning that there may be unknown or unexpected technical debt that should be surfaced and addressed by the entire Scrum Team.

Technical Debt Defined

Wikipedia currently defines technical debt as follows (bold emphasis mine):

Technical debt (also known as design debt1 or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.

Technical debt can be compared to monetary debt. If technical debt is not repaid, it can accumulate 'interest', making it harder to implement changes later on. Unaddressed technical debt increases software entropy. Technical debt is not necessarily a bad thing, and sometimes (e.g., as a proof-of-concept) technical debt is required to move projects forward. On the other hand, some experts claim that the "technical debt" metaphor tends to minimize the impact, which results in insufficient prioritization of the necessary work to correct it.

As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. Required changes that are not completed are considered debt that must be paid at some point in the future. Just like financial debt, these uncompleted changes incur interest on top of interest, making it cumbersome to build a project. Although the term is used in software development primarily, it can also be applied to other professions.

As a practical matter, technical debt can be known or unknown, and may be visible or invisible. Known and visible debt may or may not be tracked explicitly within your project, although it certainly should be.

Technical Debt and Velocity

Velocity is an agile metric that primarily measures the capacity for work that can likely be completed within a single iteration. The central idea is that historical measurements can be smoothed out (often by expressing velocity as a range or moving average) in order to make reasonably accurate (e.g. "good enough") near-term forecasts.

There are generally two classes of technical debt: visible and invisible. The two classes are compared below.

Visible and Known Technical Debt

Velocity doesn't directly measure technical debt. If you're explicitly tracking your technical debt and making it visible as work on the Product Backlog (as you should), then the primary costs of technical debt will often show up as:

  1. Increased allocation of team capacity to "debt payments" in the form of chores and explicit refactoring as debt increases, generally at the expense of new features.
  2. A general increase in the size of team estimates, accounting for implicit refactoring and the additional slack required to manage knock-on effects of the debt.
  3. An apparent (although not necessarily real) reduction in stakeholder value from each following iteration, as more and more team capacity is spent on the "debt payments" required to develop the features or keep the project from collapsing under the weight of its technical debt.

Because the debt is visible and tracked, it will generally not impact the team's actual velocity at all. Instead, it may impact the perceived value of that velocity, because it will slow the pace of new-feature delivery. 20 points of work may no longer deliver 20 points of stakeholder value, but the amount of actual effort the team can expend each iteration won't actually change much.

Invisble or Unknown Technical Debt

The cost of invisible debt—or worse, unknown technical debt—is often paid out in terms of an unexpected drag on productivity. If the drag on productivity grows large enough, and if it remains invisible long enough, this eventually leads to:

  1. A growing inability to accurately forecast capacity.
  2. An increasing incidence of iterations that fail to meet team or stakeholder goals.
  3. A loss of stakeholder confidence in the team.
  4. A general loss of confidence in the project management framework.

In short, rather than blaming the framework implementation, the framework itself (and most likely the team that allows this debt to remain invisible) will be blamed for the lack of progress. This will be magnified tremendously in agile implementations that only track stakeholder value when measuring velocity. As the level of effort for each feature goes up, the apparent velocity will go down, as the team's capacity for user-visible features decreases dramatically as the invisible technical debt is compounded each Sprint.

General Advice

Velocity is just one metric among many. Don't depend solely on velocity to measure your project, but don't discard it as irrelevant either. Here is my top-ten list of suggestions for using velocity and other techniques to measure or discover technical debt:

  1. Use velocity to measure effort, not stakeholder value.
  2. Use velocity to forecast team capacity, not potentially-shippable value.
  3. Identify technical debt as soon as possible during each iteration, including at Sprint Planning, Backlog Refinement, and the Sprint Review.
  4. Keep known technical debt visible to the Development Team, the Product Owner, and stakeholders at all times.
  5. Only take on technical debt deliberately, with the informed consent of the entire Scrum Team (and ideally with the stakeholders, too). You will all have to pay it back together!
  6. Track all known work (including technical debt) as items on the Product Backlog.
  7. Review your Sprint Backlog at the end of each Sprint to identify new sources of technical debt.
  8. Don't differentiate between chores, bugs, features, etc. in your raw velocity measurements, as they all require time, effort, and resources from the team.
  9. Do review unexpected increases in time, effort, and resources as this may be the result of invisible tech debt.
  10. Look for invisible technical debt whenever a Sprint Goal is missed, or when velocity drops unexpectedly.

Velocity by itself may or may not reveal technical debt, but can certainly act as an early detection system for invisible work. As long as you strive to keep all work visible, your process transparent, and leverage all of your framework's inspect-and-adapt cycles effectively, you'll typically avoid being surprised by technical debt. You still may accrue it, and unpaid debt may still sink your project, but at least the team and the stakeholders won't be surprised!

Track all work that consumes team capacity (including whatever you're classifying as technical debt) as a first-class element within your Product Backlog. Just like financial debt, you're much less likely to "go broke" when you keep close track of your spending and avoid burdensome interest payments.


Depending on how you to want to deal with technical debt determines if it affects your velocity. You have a few options as far as I can see:

  1. Do not allocate story points to technical debt in a separate 'issue'

If you take on technical debt without story points, e.g. in a separate task, you will see a drop in the velocity for that sprint. That is expected because the technical debt has no story points associated with it.

  1. Allocate story points to technical debt in a separate 'issue'

By doing this the velocity will be not be impacted because the story points are used in the calculation for the velocity. Doing this consistently will show you a velocity and if the technical debt can be estimated correctly in story points, you should be able to plan the work

  1. Include fixing the technical debt in the story that requires it to be solved If you have a story that can not be delivered until the technical debt is solved, include the work in the estimation of the story. If that means that the story becomes to big to handle in a sprint, create an epic and split the story in smaller parts and connect them to the epic. This has my preference because it shows what needs to be done to implement a feature and you can indicate dependencies in the stories listed under the epic.

There is a strong link between technical debt and velocity, both in the short-term and in the long-term.

A team could potentially raise their short-term velocity by accumulating technical debt. In effect, they are putting things off so that they can give the appearance of faster progress.

In the long-term the accumulation of technical debt can start to drag velocity down as it makes development more difficult.

A key aspect of technical debt is the visibility of the decision making process.

That is, when a team takes on new technical debt or recognises existing technical debt it should make a clear and visible decision about what to do about it.

For example, a team might decide to defer resolving some challenging technical debt because they have a release approaching. They would acknowledge and make visible the impact that this will have on the long-term performance of the team and they may also decide to prioritise resolving the debt after the release.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.