Treat technical debt as a product risk that competes with feature work. Start by (1) quantifying the impact—slow releases, escalated bugs, or developer fatigue—(2) mapping debt items to business outcomes, and (3) slotting them into a weighted scoring model alongside user‑facing initiatives. The usual mistake is to relegate debt to a “later” bucket without justification. Reinforce your answer by showing a clear trade‑off analysis and a cadence for debt repayment (e.g., 20% of each sprint).
Related FAQs
- How to communicate debt to non‑engineers? Translate it into delivery velocity and customer impact.
- What if the roadmap is already full? Propose a small “debt sprint” or integrate fixes into feature stories.
- Is there a metric for debt health? Track mean time to resolve critical bugs or release cycle length.