Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
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.
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.
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.
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.
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:
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.
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:
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:
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:
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.
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
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.
velocity != productivity. Don’t conflate the two metrics!