·
🗣️ "Debts and lies are generally mixed together" - Rabelais
Technical debt — what, why, and how
These days, you can talk about “technical debt” without everyone thinking you’re a nut-job 🤪.
What it is
- Technical debt = the longer-term consequences of poor design decisions ⚖️.
What it isn’t
- Not every flaw or defect is technical debt.
- If a decision doesn’t directly compromise product quality 👌, it isn’t technical debt.
Scrum expectations
- Your Definition of Done ✅ should be robust enough that unmanageable levels of genuine debt don’t accrue.
Keeping debt down
- Actively allow time for refactoring 🔄️.
What not to do
- No “special sprints” to clean up technical debt 👎.
- “Hardening sprints” are essentially an anti-pattern.
Tracking the debt
- Maintain a technical debt register as part of a RAID log 📃 (Risks, Assumptions, Issues, Dependencies).
- Assumptions and dependencies can also be captured in this register.
Paying it back
- Sometimes you can pay off debt while delivering related backlog items.
- Other times, it must be addressed separately 🔀.
Visibility & ownership
- Some debt items should be exposed to the Product Owner 👨💼 for consideration; others may not need escalation.
Strategy over time
- When the debt is substantial, whittle it down gradually 📈—Sprint by Sprint.
Visual management
- Use a separate card wall 🧱 labeled “Technical Debt Register”.
- Typical workflow states: To Do → In Progress → Done → 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