This is part of a series called Eight Questions to Ask About Your Tech Debt
- Introduction
- #1: Visibility
- #2: Misalignment
- #3: Size
- #4: Difficulty
- #5: Volatility
- #6: Resistance
- #7: Regressions
The main thing to keep in mind is this diagram (described in the introduction):
The next question we’ll cover is on Uncertainty: How sure are we that our tech debt fix will deliver the developer productivity benefits we expect?
My definition of tech debt emphasizes its internal effects. The main one being developer productivity, which is captured in the Resistance and Volatility scores. To the extent that a tech debt project delivers benefits for customers and other stakeholders, that will be represented in its Visibility. If a project has no internal effects and is driven by its tangible benefits to customers (e.g. security and performance), then I would generally consider that project to be a normal enhancement that should managed by the Product Manager, Product Owner, customer, or whoever is responsible for the feature roadmap.
So, given that we’re mostly talking about projects that have benefits to our team, we need to be the judge of how certain the proposed project will deliver those features. That’s what we score with Uncertainty. It contributes to the Stay Force, which, if high, indicates that we should live with this debt.
Use Spikes to Lower Uncertainty
Spikes (or pilot projects / proofs of concept / etc) are a good way to learn if you’ll get the productivity benefit a project promises. I said the same thing about high Difficulty projects (that have high estimate risk) for the same reason. If you have a project with high scores for both, a good pilot project would lower both of those scores and help the Pay Force overcome the Stay Force.