Technical Debt is a phase coined by Ward Cunningham to help illustrate the pros / cons of releasing software in a quick & dirty fashion vs a long term, cleaner solution. In a nutshell, technical debt is much like financial debt, as it incurs interest in the way of level of effort over time.

Financial Debt comes with a very negative connotation in these tough economic times, but as Eric Ries stated recently it isn’t inherently a bad thing. Releasing early has it’s own benefits such as receiving much needed customer feedback for your product. These leading indicators may provide the direction you need with future software releases.

How does an agile team decide whether or not the technical debt they incur is acceptable?

I have a couple suggestions below:

Address Technical Debt in Retrospectives – Keep a running tab of your technical debt so that it doesn’t run rampant. Your retrospectives should include items such as Refactoring Debt Incurred and Refactoring Debt Paid. If you trend these data points over time and notice debt incurred going up like a hockey stick, it should be a cause for concern.

Release Early with Customer Feedback Loops – While there are certainly scenarios where a feature needs to be pushed out quickly, the code should include some level of empirical data gathering to measure customer impact. With tools such as Google Analytics and Mixpanel available, take the time to run A/B tests with your code. If your early release results in a 20% boost in conversion, it is much easier to reconcile the technical debt you incurred. Without this data however, you will be missing key elements to your decision process.

In short, be wary of teams that use the phrases “quick & dirty” with “path of least resistance” too frequently without empirical data to back it up. Keep your technical debt manageable by trending it over time, and bake in customer feedback loops to justify your early releases.