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:
- 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.
- 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.
- 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:
- A growing inability to accurately forecast capacity.
- An increasing incidence of iterations that fail to meet team or stakeholder goals.
- A loss of stakeholder confidence in the team.
- 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.
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:
- Use velocity to measure effort, not stakeholder value.
- Use velocity to forecast team capacity, not potentially-shippable value.
- Identify technical debt as soon as possible during each iteration, including at Sprint Planning, Backlog Refinement, and the Sprint Review.
- Keep known technical debt visible to the Development Team, the Product Owner, and stakeholders at all times.
- 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!
- Track all known work (including technical debt) as items on the Product Backlog.
- Review your Sprint Backlog at the end of each Sprint to identify new sources of technical debt.
- Don't differentiate between chores, bugs, features, etc. in your raw velocity measurements, as they all require time, effort, and resources from the team.
- Do review unexpected increases in time, effort, and resources as this may be the result of invisible tech debt.
- 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.