Return to site

SCRUM: Using a "Technical Debt Register" in Scrum by Ian Mitchell

· scrum

🗣️ "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