"done", "undone" and Technical Debt.

Technical Debt is undone (or potential) work that is implicit / not transparent.

I don't agree with that definition.

Work can be done, but still have technical debt. Consider one example where a team was introducing new technology to solve a particular problem. At the end of the Sprint, they managed to complete the work from a functional perspective, but learned more about the tools and technology that they used as they went along. Towards the end of the Sprint, they realized that some of their decisions weren't that great and should be revised, but there's no time left in the Sprint. The team makes the decision that it's more important to ship the functionality in order to continue to get feedback on it and they will take on the work in the near future. This is "prudent and inadvertent technical debt".

Since the team is aware that they have learned lessons, they may record the need to go back and do further work as a Product Backlog Item. They may quantify the need to do this in terms of the impact of not doing the work - perhaps they learned their approach isn't scalable and need to approach it before scaling or that it will increase the burden on operations and maintenance. This will allow it to be prioritized with the other work.

In this case, the work may meet the team's Definition of Done for both the work as well as the Increment, meaning that the initial scope of work was indeed Done (and new work was identified). It's also transparent since it's visible to the appropriate stakeholders.

I believe that you can say that Technical Debt is potential work, but it doesn't necessarily have to be undone work or not transparent.

This is one attempt to bring the terms "done", "undone" and "Technical Debt" together visually. Technical Debt is undone (or potential) work that is implicit / not transparent. What do you think?

I think the Definition of Done should make technical debt transparent. Technical debt may be understood to be the long term consequences of work which fails to meet the Definition.

Thanks for you feedback! I was actually trying to share this graphic i made to visualize but can't seem to upload my image. Without the image to elaborate my "definition" from above is indeed flawed.

Hello, 

Where can I actually read about Technical debt? 

I am currently preparing for the PSM 1 exam and my trainers advised me to get familiar with the technical debt. 

Thanks! 

In my opinion your assessment is missing something. 

Consider these things that I interpret to be technical debt:

• Bug found in Production by an end user
• Upgrades to third party components 

Both of those would be transparent to everyone involved in the creation/maintenance of the product.  They should be made transparent to the stakeholders of the product by those involved in the creation/maintenance of the product. @Thomas Owens gives a perfect example and @Ian Mitchell provides a great way of recognizing technical debt.

I actually make an effort to avoid the term technical debt.  In my view, everything in the Product Backlog is an opportunity to provide value. So anything that impacts value should be visible in the Product Backlog.  Everything in the Product Backlog has 2 types of value.  Negative value as long as it exists in the Product Backlog and positive when it is delivered to the stakeholders. Yes, even an enhancement or new feature has negative value if it hasn't been delivered. And yes, fixing a bug or upgrading third party components provide positive value to the stakeholders. The Development Team are the ones best suited to provide the information for a technical debt type item to include it in the Product  Backlog. I know my view is different but by avoiding the term technical debt I have found that it has been easier for people to see everything on the same level.  A few of my Product Owners have even said that it makes ordering technical debt type items higher in the Product Backlog as the value is easier to determine and align with other work.

@velislava, there are many resources on technical debt here.

Thank you, Eric, I will take a look today! 

Have a lovely Sunday all :)

Technical debt describes deferred, necessary work also it includes those internal things that you choose not to do now, but which will impede future development if left undone. This includes deferred refactoring. Technical debt decisions are made based on real project constraints. For more in-depth understanding visit this blog. https://bit.ly/3jghOnb