"Produktu, który spełnia definicję ukończenia, czyli o długu nie może być mowy" - nie zgodzę się. Można pokusić się o hipotezę, że dług powstaje już z chwilą napisania pierwszej linii kodu: prędzej czy później okaże się, że w kontekście całego produktu coś można było napisać inaczej, że w kontekście nowej (wcześniej nieistniejącej) technologii, standardu, czy "mody" dawny kod jest "jakiś kiepski", że w kontekście nowych pomysłów na rozwój aplikacji, których wcześniej nie brano pod uwagę, obecny kształt kodu nie pozwala na skalowanie produktu i żeby można go było dalej rozwijać, wymagany jest gruby refactoring. A to oznacza, że dług techn(olog)iczny zaciągamy zawsze i nie jest on nigdy w 100% eliminowalny. Dziś możemy uważać, że spełniamy Definition of Done, jutro - w wyniku "inspect and adapt" - okaże się, że zaciągnęliśmy dług. I oczywiście podczas każdej Retrospektywy możemy "się zastanowić co jest nie tak", ale konkluzja będzie często jedna: zmieniają się czasy, potrzeby, możliwości - a jeśli chcemy być zwinni i na te zmiany reagować, musimy uznać, że to, co wczoraj było OK, dziś jest zwyczajnie długiem i wymaga kroku "adapt".
Czy chcemy adresować każdy dostrzeżony dług? Kwestia potrzeb i opłacalności. Podejście zwinne ma umożliwiać osiąganie przewagi rynkowej i jeśli dzięki minimalizacji długu możemy wpłynąć na wzrost konkurencyjności - pewnie warto mieć to na uwadze. Jeśli nie - być może trzeba się zastanowić, czy jest to uzasadniona inwestycja.