Are Defects Technical Debt?

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.

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.

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 

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. 

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.

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.

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".

@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. 

Defects can't be technical debts because technical debts doesn't mean not meeting requirement either functional or technical. Technical debts are related to poor design, poor coding or not having applied appropriate design patterns etc. Hope this blog will help you to get a better insight on technical debts.

I generally find with terms like technical debt (MVP is another example), it is best to ensure all interested parties agree on the same definition.

So it's almost certainly important that all development teams agree on what technical debt is in their shared context, and probably useful if Scrum Masters and Product Owner also agree. Depending on the types of discussions that take place, it might even be important for stakeholders to understand and agree on the definition.



It's probably unhelpful to seek a definition that contradicts what is commonly understood in the industry, but beyond that, it doesn't matter if their shared understanding differs from the outside world, because blog writers and forum participants have no impact on the development of their product.

Another important aspect to consider here is choice! We choose design and architecture for our project. Technical debt is something that can be avoided by having a better workflow or better coding practices. Fundamentally bugs cannot be technical debts because that is not something we choose to have in our code. There may exist a relation between bugs and technical debt such that some bugs may belong to bad design choices.

I have a view that may be controversial. Technical Debt as commonly used does not exist. Here is a link to a recent article I had published on this very subject https://lnkd.in/d6YzdEE

If we take the original Question: Are defects Tech Debt. The answer is definitely No.

You only have a defect when the issue is released into live. So once known it is a decision for the PO on whether it gets fixed immediately or not.

If it needs to be fixed immediately then in addition to the remedial work, there is another important step. A defect is at its heart proof that the process you are following has gaps. These need to be fixed. Find why the defect got through and fix it now, do not wait for the end of sprint retro.

If the PO decides that the issue can be lived with then the work goes on the backlog as a possible future enhancement.

Technical debt makes delivering new features hard.

it is a constraint on how you solve the problem in the PBI's you want to bring from the product backlog to the sprint backlog.

A defect is function not meeting specification - test case failure, poor test case, but the behaviour doesn't reflect the need.

The value of the bug/defect is measured by its impact on real users, now.

the (negative) value is measured by the impact on the "expensive practices" you must follow to implement new fatures while it is inplace, or the additional maintenance burden while it is in place.

- you want your users to be ingested from a directory, but to go live early you manage your users internally

- it isn't a defect, it's tech debt which gives an admin burden

- middle names are captured during user creation, but displayed incorrectly. that's a defect. If you leave it to fix beyond the sprint where it's first implemented, it's also tech debt.

A defect is at its heart proof that the process you are following has gaps. These need to be fixed. Find why the defect got through and fix it now, do not wait for the end of sprint retro.

maybe new features are more important than quality.

if you're releasing 3 means to achieve the same outcome and you want to see which is used heavily (and deprecate 2) you may be happy to release all 3 with less than ideal quality. "Move fast and break things" may be a strategy. It might be one you don't like, and that's ok.

Firstly, to clarify the statement in my earlier post.

"A defect is at its heart proof that the process you are following has gaps. These need to be fixed. Find why the defect got through and fix it now, do not wait for the end of sprint retro."

By 'fix it now' I was referring to addressing the issues with the process, not fixing the deflect itself.

In the full article I explore the common misuses of Technical Deb and how it is normally used as convenient mechanism to bypass backlog prioritisation. If you are consciously making a decision to release something into live that may not be a good as it can be as mentioned below;

"- you want your users to be ingested from a directory, but to go live early you manage your users internally"

This is fine and a great way to prove the viability of your product and recommend as a strategy to be used.

But the missing automation process should not be thought of as Tech Debt, but an enhancement to the product, and hence a standard PBI. If you cannot use your product with the manual admin process then it should never have been released into live in the first place. So your early release is completed and can deliver value i.e. Done.

If your product does not prove viable, then you would never need to implement the automated process. If you can manage with the manual process and deliver something of greater value with the effort you would expend to add it then you would not implement the automated process at this point. Its only when the lack of an automated process consumes more value than can be generated by delivering other PBI’s does it need to be worked on.

Just because you have not completed something does not make it Tech Debt. These are just items that were not completed in the sprint so they should go on the backlog with everything else. If you really need it then it should have been there in the first place.

The debt metaphor has been expanded by numerous people since first coined by Ward Cunningham. This to the point that it is now mostly synonymous with "crappy code" which is, in my opinion, an incorrect interpretation.

As I understand his metaphor, it is an informed and deliberate decision to go into debt as this will give you some advantage, just as you intentionally take a mortgage to buy a house. Yes, you will pay interest on the loan for a long time, but you will gain the advantage of living in that house. You always go into debt with the intention of paying it back, and the sooner the better. For the same reasons, you take on technical debt deliberately because you will gain some advantage (like going to market faster) and you are aware that until that debt is payed back your progress will be slower. This is not the same thing as shipping junk and your code should be clean to allow for later refactoring to pay off that debt, and the work needed to pay it back should be put on the backlog.

So for the question if bugs are considered tech. debt, I would say that they are clearly not. Whether that matters or not is another question :-)

See the video where Ward explains the metaphor himself

https://www.youtube.com/watch?v=Jp5japiHAs4

If we look at the definition of a Defect and Technical Debt, you'll see that they really do not overlap.

Defects that are found in the same Sprint as the User Story will be considered as Work in Progress.

Defects that are found in production, but are considered cosmetic, minor or have a workaround can be considered as Technical Debt.

Defects that are found in production and are high, critical or blocker and do not have a workaround will trigger an emergency bug fix and release will be considered a Pain in the B*tt (<-- very professional technical term ;-)  ).

ISTQB

Defect Version:

A flaw in a component or system that can cause the component or system to fail to perform its required function, e.g., an incorrect statement or data definition. 

A defect, if encountered during execution, may cause a failure of the component or system.

ITIL

Workaround

Workarounds are temporary solutions aimed at reducing or eliminating the impact of Known Errors (and thus Problems) for which a full resolution is not yet available.

As such, Workarounds are often applied to reduce the impact of Incidents or Problems if their underlying causes cannot be readily identified or removed

Scrum

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 simple words I can explain technical debt as a system  disability and bug as illness, that can be handled more quickly, then disability.  Also disability is not always seen for users, but affects system quality and it's becomes hard to upgrade and maintain it.  Regarding to Value both affect system quality and product value.