Technical Debt, Quality, and Definition of Done

This is a conversation for the whole team.

I think the "by-the-book" answer, based on the Scrum Guide, is that "quality does not decrease". If work doesn't meet the Definition of Done, it "cannot be released or even presented at the Sprint Review". In terms of Martin Fowler's Technical Debt Quadrants, I would express this as a prohibition on all forms of deliberate technical debt - even if it's prudent, you cannot release or demonstrate the work. You cannot necessarily prevent inadvertent technical debt, since you may not know if it exists until later.

However, I'm not sure this is the right choice in all situations. There's a reason why Fowler calls some technical debt deliberate and prudent. Releasing the work or being able to demonstrate it to stakeholders quickly may be more beneficial. If you're going down the wrong path and building the wrong thing, you can stop earlier and change course, perhaps as early as the next Sprint. If you stretch the work out over multiple Sprints because you think it's valuable but doesn't meet the team's Definition of Done and still has known technical debt, you could spend twice as long or longer and even perhaps build upon incorrect work.

I would expect a conversation between the Developers and the Product Owner, perhaps facilitated by the Scrum Master, to come to the right decision to balance quality with fast feedback loops. There's a balance between the fast feedback loop and investing time to quickly pay down technical debt that the team knows exists in the system and bringing quality back to desired levels fast.

Thank you a lot for your insightful feedback, Thomas!

Is this technical debt created from the past, or is this something created in the current Sprint?

If it is from the past and not created in the current Sprint here are the options I've seen teams leverage:

• Make Tech Debt transparent on the Product Backlog;
• Team Working Agreement to clean up x% per Sprint;
• Account for Tech Debt when sizing work and in Sprint Planning;
• Boy Scout rule: leave the codebase better than when you found it;

If it is something created in the current Sprint because the Definition of Done was weak, leverage the Sprint Retrospective to inspect and adapt the Definition of Done to avoid tech debt in the future. 

If the Definition of Done already includes items such as code reviews, refactoring, code coverage, and other items to catch and remove technical debt, yet it was ignored by the Developers, then the PBIs shouldn't have been added to the Increment. Leverage the Sprint Retrospective to discuss topic.

Please in a case where Developers contend with a technical debt due to unforeseen circumstances, what should they do? 

Make sure those circumstances are foreseen and dealt with in the future.

1. Observing a good Definition of Done is the bulwark against technical debt, so firstly the DoD needs improving and honoring. At that point, the Developers will have an Increment they can have confidence in.
2. Secondly, any technical debt which has been incurred needs to be accounted for on the Product Backlog. It must tell the truth at all times about the total amount of work remaining for the Product. 
3. Thirdly, the Developers ought to decide a policy for paying off a certain amount of the technical debt every Sprint, until it is drained.

Thank you a lot for all the awesome responses. They are enlightening!

Navigating technical debt in Scrum requires transparency, prioritization, and unwavering quality. While the original Sprint Goal remains, address debt incrementally. Reflect, adapt, and maintain the Scrum mindset

My understanding of technical debt is that it is from a decision to follow a design or code in a certain way that isn't sustainable in the long run or will give problems later on like performance issues. Technical debt is not a defect or bug.

The answers above were good. Be transparent etc and log an item to the backlog.

But answering the original question directly, I read the team either created technical debt or technical debt was uncovered that was introduced earlier. Also speaking generally on technical debt as the specific nature of this debt is not known.

Focussing only on the question, "can they still deliver the result of the current sprint as an Increment", I would say yes, it is possible.  Technical debt should imply the system is working, but later on issues will come up. Release the working increment and fix the technical debt in a later sprint.