ほとんどのアジャイルチームが，技術的負債(Techninal Dept) は悪いものである，という考えを持っている。金銭的な負債と同じように利子負担を伴なうからだ。技術的負債の利子は，構造を損なった，あるいは基盤が不安定になったソフトウェアを維持・拡張するために要する余分な労力，という形で支払うことになる。そのためにアジャイル実践者たちの多くが，技術的負債を可能な限り早く返済するように勧めている。その一方で，技術的負債を定量的に把握するための貨幣化(monetize) については，それによって重要な見識が得られるにも関わらず，ほとんどのアジャイルチームが実現できていない。
技術的負債を貨幣化して定量的に把握できれば，ソフトウェアに関する複雑で難解な質問への回答に役立つはずだ。Isreal Gat 氏は技術的負債について，それを定量化する尺度がなければ，ソフトウェアが修復不可能な レベルに達するまで無視されるだろう，と指摘する。
負債が一定のレベルを越えてしまったら，もはや選択の余地はありません。修正を行うことが危険である – どのような修正でも他の部分を破損する可能性がある – というレベルまで，コードは崩壊してしまっているのですから。
氏は技術的負債の貨幣化の必要性について，それを 貸借対照表上の負債になぞらえて説明している。
氏によれば，技術的負債の貨幣化にはいくつかの利点があるという。
- 開発からリファクタリングへの転換時期 が判断できる – 技術的負債が一定のレベル (例えばコード１行あたり25セント) に達した時点で，新機能開発を保留する。チームはリファクタリングモードに入り，負債を抑制できるまでは機能追加を行わない。
- 顧客が ソフトウェアのリスク性を理解 できる – 氏はこれを，アジャイルマニュフェスト “契約交渉よりも顧客との調和を” の延長線である，としている。
- ベンチャキャピタリスト (Venture Capitalist，VC) の投資判断 を容易にする – VC がソフトウェア製品に対して投資する場合に，論理的根拠の定義が可能になる。
- ソフトウェアの価格感 を決定する – ソフトウェアはライフサイクルを通じて拡張を続けるものである。その開発・維持作業の価格対価値に関する質問への回答となる。
- リファクタとリライト(rewrite，書き直し) の選択 判断に利用できる – 他の重要な要因とも合わせれば，再出発を決断するための判断材料になる。
- 信用限度の定義 に利用する – 融資限度を設定することができれば，CxO(CIO, CTO など)を含めたすべてのステークホルダの意思決定に役立つ。
では，技術的負債を貨幣化するには，どのような方法がよいのだろうか？
そのひとつは Sonar の techninal debt プラグイン を利用することだ。Sonar ライブサイトでは，多数のプロジェクト を元にした技術的負債の解析結果が公開されている。費用の計算は，次の式で 負債を求める ことから始める。
- 負債 (人日) = {cost_to_fix_duplications + cost_to_fix_violations + cost_to_comment_public_API + cost_to_fix_uncovered_complexity + cost_to_bring_complexity_below_threshold + cost_to_cut_cycles_at_package_level}
上の式に現れている違反行為にはそれぞれ，時間コストの既定値がある。例えば，
- cost_to_fix_duplications = {cost_to_fix_one_block * duplicated_block}
既定値では cost_to_fix_one_block = 2(時間) である。平均的開発者のコストを１日８時間で $500 とすれば，このブロック１つを修正する費用が $125 と計算できる。同じ要領でそれぞれの違反行為の費用解析 を行えば，最終的に技術的負債のトータル費用が求められる。
このような技術的負債の費用計算によって，ソフトウェアの隠れた費用に関する理解を深めることができる。技術的負債を監視して限度内に収めていくことは，すべてのアジャイルチームにとって非常に重要である。それが単にソフトウェアの維持拡張を容易にするだけではなく，VC からの投資を受け入れ，顧客が信頼して購入できる製品を作り出すために有効なものだからだ。