Technical Debt is one of my favorite work-related phrases because it succinctly and metaphorically sums up the obligation we incur when we cut corners during software development. The phrase was coined by Ward Cunningham, the developer of the first wiki and, incidentally, a major contributor to Extreme Programming Agile methodology.
The concept of technical debt can be thought of as the accumulation of product risk introduced by any number of poor development practices. Examples include poorly designed code, loose development practices, and, in Scrum terms, the delivery of “undone work”. The payment terms on this debt can be onerous. Usually the cost is time or productivity, sometimes both. Dealing with this debt during the product release can increase the work required before the product can ship, often delaying the release. Or, if you decide to postpone payment until after the release, the cost may be customer-discovered defects which can cause unexpected maintenance escalations and a higher ongoing product maintenance burden, ultimately reducing productivity and velocity for future development.
Regardless, like credit card interest or the National Debt, at some point in the future the bill comes due - someone is going to have to pay off the debt.
The concept of technical debt can be thought of as the accumulation of product risk introduced by any number of poor development practices. Examples include poorly designed code, loose development practices, and, in Scrum terms, the delivery of “undone work”. The payment terms on this debt can be onerous. Usually the cost is time or productivity, sometimes both. Dealing with this debt during the product release can increase the work required before the product can ship, often delaying the release. Or, if you decide to postpone payment until after the release, the cost may be customer-discovered defects which can cause unexpected maintenance escalations and a higher ongoing product maintenance burden, ultimately reducing productivity and velocity for future development.
Regardless, like credit card interest or the National Debt, at some point in the future the bill comes due - someone is going to have to pay off the debt.
For new teams adopting Scrum, Technical Debt can occur without the team being fully aware that it is happening. For example, teams with a loose definition of Done can introduce technical debt. Stories may be accepted by the Product owner without having code reviews, minimal automated testing, or no code coverage or memory leak verification. Any of which could leave unexposed defects in a seemingly “done” feature. Another possible cause of debt can be caused by user stories that not properly decomposed such that Sprint backlogs do not yield a potentially shippable product increment at the end of a Sprint. In this case, more work, either known or unknown, is created for “later” in the release.
As a Product Owner, you should keep track of your accumulating debt. If the debt is significant, I recommend putting it in your Product Backlog, to be prioritized appropriately. One way that I have found to identify and track any technical debt your team is accruing is to plan periodic “releases” to customers. Product early releases, in the form of early access programs or Technical Previews, can not only provide valuable customer input that can feed into your backlog, but it also keep the Scrum team in the practice of delivering potentially shippable code. When engineers realize their code is going to be used by actual customers, often “forgotten” undone work can suddenly appear.
Note that not all debt is “bad” - there are often valid reasons for accumulating technical debt. Perhaps the underlying architecture has some scalability constraints, but getting the product to market, in other words, harvesting “business value” ($, customers), is more important to the business. The key is for the Product Owner and Team to explicitly know that this debt was incurred, and accept that you may have to pay in the future be willing to accept that obligation.
The Product Owner should be aware at all times of work that is needed to release the software, including the technical debt that is accruing. With a complete and publicly visible Product Backlog, there should be no surprises. Keep an eye on your debt - make sure you know how much debt interest is accumulating...
As a Product Owner, you should keep track of your accumulating debt. If the debt is significant, I recommend putting it in your Product Backlog, to be prioritized appropriately. One way that I have found to identify and track any technical debt your team is accruing is to plan periodic “releases” to customers. Product early releases, in the form of early access programs or Technical Previews, can not only provide valuable customer input that can feed into your backlog, but it also keep the Scrum team in the practice of delivering potentially shippable code. When engineers realize their code is going to be used by actual customers, often “forgotten” undone work can suddenly appear.
Note that not all debt is “bad” - there are often valid reasons for accumulating technical debt. Perhaps the underlying architecture has some scalability constraints, but getting the product to market, in other words, harvesting “business value” ($, customers), is more important to the business. The key is for the Product Owner and Team to explicitly know that this debt was incurred, and accept that you may have to pay in the future be willing to accept that obligation.
The Product Owner should be aware at all times of work that is needed to release the software, including the technical debt that is accruing. With a complete and publicly visible Product Backlog, there should be no surprises. Keep an eye on your debt - make sure you know how much debt interest is accumulating...
