The metric that you use to measure technical debt is "the time it takes to build new features over time". If that line on your graph is going up, you have a problem.
Never in the history of software has that line done anything but gone up. Software naturally gets more complex as it grows to handle new features, new edge cases, more users, more backwards compatibility, etc.
This line going up is inevitable and natural. The slope needs to be managed obviously. But the only way this line stays flat is if your company is failing.
That would work really well if it were possible & straightforward to consistently estimate complexity story points, independently of time. Even better if you could (ditch Fibonacci, necessarily, and) objectively match each complexity value in linear scale relative to the others.
In order that you could say 'it's now taking us twice as long per complexity point as it was last year', and know that that was meaningful.
Agreed, and I also think measuring "rework" helps. For a car company, rework could be recalls or warranty claims. For a software company it can be outages or incidents, especially those with major customer impact.
I somewhat agree, but every feature is not equal. And you usually start with the easy ones... So, even without any technical debt, it will probably go up, just less fast.
That's true. So I suppose I would amend to say "if the line is exponential". At the company I work for presently we try to adopt "painful now, pleasurable later".
This line going up is inevitable and natural. The slope needs to be managed obviously. But the only way this line stays flat is if your company is failing.