These days a man can talk about "technical debt", and folks don't always assume he's a nut-job 🤪.

Technical debt can be defined as the longer-term consequences of poor design decisions ⚖️.

Not all flaws and defects constitute technical debt.

If a decision doesn't directly compromise product quality 👌, then it isn't technical debt.

In Scrum, the expectation is that a Definition of Done ✅ should be sufficiently robust for unmanageable levels of genuine debt not to accrue.

There are certain other controls which can be used to keep debt down: a team should allow for refactoring 🔄️.

Note however that implementing "special sprints" to clean up technical debt isn't an option 👎.

Hardening sprints are essentially an anti-pattern.

What some teams do is to maintain a technical debt register as a RAID log 📃 (Risks, Assumptions, Issues, and Dependencies).

Assumptions and dependencies may also feature in the register.

Sometimes, for example, technical debt can be paid off when implementing related backlog items.

In other cases that might not be possible and the debt must be addressed separately 🔀.

Certain instances of debt may need to be exposed to the Product Owner 👨‍💼 for consideration, and others may not.

Another option when faced with substantial technical debt is to whittle it down gradually 📈, Sprint by Sprint.

I prefer to coach teams to use a separate card wall 🧱 for the purpose of "Technical Debt Register".

Typical states are To Do, In Progress, Done, and Escalate.

Items are Done when they are either mitigated or accepted.

Full article👉 https://www.scrum.org/resources/blog/using-technical-debt-register-scrum

Udemy👉 https://www.udemy.com/course/professional-scrum-developer-certification-prep-200-question/?referralCode=49CBC321F20A7E381F7C