Are Defects Technical Debt?

Last post 03:16 pm July 2, 2019
by Daniel Wilhite
8 replies
08:30 pm June 25, 2019

According to my understanding, technical debt arises when shortcuts like bad design or code are introduced to gain a quick advantage for the short term.

Per the Scrum Glossary,

Technical Debt: the typically unpredictable overhead of maintaining the product, often caused by less than ideal design decisions, contributing to the total cost of ownership. May exist unintentionally in the Increment or introduced purposefully to realize value earlier.

In this regard, is any Defect (intentional, unintentional, escaped etc) considered Technical Debt? 

Lastly, should we be story pointing Defects? What are you thoughts and opinions?

09:45 pm June 25, 2019

Should defects be considered technical debt? I'd say no - they are related, but different and should be denoted differently when tracking. Technical debt is about, in the definition that you provided, "less than idea design decisions". Defects are problems - perhaps a problem in understanding the user needs and requirements, perhaps a problem in the design, perhaps missing or wrong testing. They are visible to users of the system, or at least can be visible to users. Technical debt doesn't affect features or functionality, except to the extent that it can slow the delivery of new or modified features or functionalities. I would argue, however, that the number of known defects can play a role in assessing the quantity of technical debt in that defects can also slow down the ability of people to understand the product and service and continue to develop it.

Should defects be pointed (or, more generally estimated)? It depends. If it's found in-cycle, I'd say no. If you're estimating work and, before it is considered "done", you find a problem, you should not estimate fixing that defect. You've already estimated the work, and the work was incomplete. However, if someone "escaped" and was considered done, I would estimate the work to fix. This can be useful in determining the priority to fix - it may be more beneficial to add a new feature than fix an edge case bug, especially one that is hard to fix.

01:57 am June 26, 2019

Defects and technical debt both represent work that remains to be Done. If the repair of a defect is postponed to some future point then debt will be incurred. Technical debt should always be accounted for when estimating the size of the Product Backlog.

04:04 pm June 26, 2019

Defects and technical debt both represent work that remains to be Done. If the repair of a defect is postponed to some future point then debt will be incurred. Technical debt should always be accounted for when estimating the size of the Product Backlog.

@Ian Mitchell, Agreed with all that you have mentioned above. In fact this is exactly what I teach too, however, the argument that was presented was, while a defect is a requirement not met and can affect functionality, technical debt on the other hand is not really a missed requirement and neither does it impact functionality (atleast not immediately) and perhaps this stems from the fact that Technical Debt is worded as a decision to cut corners in the short-run to achieve value faster. My reasoning however is that, when you cut corners you may introduce Defects unintentionally or intentionally and therefore Defects are Technical Debt.

I guess the answer I am looking for is whether a Defect is Technical Debt or Defect is not Technical Debt 

06:03 pm June 26, 2019

This is my opinion and it differs from others because we have had this debate before.

Technical debt has value.  Negative value as long as it exists, positive value when it is eliminated.  Same can apply to a story for a new feature.  Negative value because the feature isn't available, positive value when it is. Based on that I see no difference between the two.  How do bugs fall into that.  Well as long as bug exists, especially those from users, there is negative value. It lowers the users believe in the quality of the product and tarnishes the companies reputation as an example.  Fixing that bug increases value to all. So I coach to treat everything equally. 

To me a defect, a shortcut taken in order to deliver something to validate value, upgrading a third party component to the current versions are all technical debt. Treat them all the same because there is value in them. 

06:10 pm June 26, 2019

If a defect is being addressed within the current Sprint, then it may be considered work in progress. If however resolution is deferred to some future Sprint then it will constitute technical debt.

I would suggest that if a defect is undetected then, until such time as it is recognized and owned, it cannot be accounted for as debt but will instead amount to pure loss.

07:56 pm June 26, 2019

Technical debt has value.

@Daniel Wilhite, In my opinion, Technical Debt has value only if it has some impact either on the end user or the organization. What if a team that is extremely proficient in coding, design, testing etc, realized that there was an even better way of doing the same thing towards the end of the project? That would constitute technical debt, right? I am not saying that their first approach was bad or they took shortcuts, but in such a scenario even though there is a realized technical debt, is there value in spending to refactor? Sometimes, products have technical debt but doesn't really impact value.

On the other hand, a defect is a piece of functionality or requirement that affects a desired outcome. If detected once the product/code is live/in production it would impact the value.

I am of the opinion that whilst Defects that are detected/realized after being released to Production constitute Technical Debt, Technical Debt isn't necessarily a Defect.

02:57 pm July 2, 2019

I will just say this topic (what is technical debt? does a defect constitute technical debt? and derived questions) has been confusing me for a good number of years. 

Recently though I finally gave up trying to make sense of it all because there are so many different interpretations and arguments in favor of one or another that it's just a waste of time to try and solve the "puzzle". So I simply decided to accept there is no universally-acceptable view, and rather than trying to narrow it down, perhaps it's best to focus on the results rather than names, views and "definitions".

03:16 pm July 2, 2019

@Steve  I agree with most of what you say and that is part of why I suggest putting Technical Debt into the Product Backlog to be assessed as everything else.  

...but in such a scenario even though there is a realized technical debt, is there value in spending to refactor?

Not always but that is the beauty of having it in the product backlog.  The debt is captured and there may not be immediate value to addressing it but at some point it could become more important. For example, 6 months after the Technical Debt is realized it becomes more important to fix it because the current implementation will not support the changes needed for the next new feature.  At that point there may be a decision made to order the Technical Debt higher in order to facilitate the next value providing feature. The flip-side is also true.  After 6 months it may be decided that the feature will live as it is for many years and there is no value at all in refactoring, at which point the backlog item can be handled appropriately. 

As @Eugene said this is an age old debate and I am not sure anyone will ever come up the all encompassing answer.  I have tried multiple options and none of them have been better than the other because every team is unique.  My proposal above is the one that I have found to be most useful but, just like Scrum, I use it as a framework for coming up with the solution that works for the team in need.