If you search on the Internet you’ll see plenty written about Technical Debt. It’s something that all software development teams have to come to terms with. Technical Debt is metaphor coined by Ward Cunningham that attempts to describe the effects of delaying software rework/updates in a similar way to accumulating financial debt. The debt needs to be paid back or it will accumulate.
A key aspect to managing Technical Debt is to make it visible, don’t hide it away. It is something that can affect the efficiency of the team and simply ignoring it will have the compound interest effect that will take greater effort to resolve. Some Technical Debt is manageable within a sprint but larger Technical Debt needs to be communicated and planned for in a future sprint or release. To make Technical Debt visible the team should adopt the habit of raising awareness of even small Technical Debt during stand-up and larger items should be regularly discussed during Sprint Reviews. From a Project Management point of view consider Technical Debt similar to Risk – we can have an action plan to mitigate but the proximity and impact needs to be clearly understood.
Dave Browett-Agile Proj Mgt 
[…] us slower that we call “Technical Debt” that I’ve written about last year (see https://davebrowettagile.wordpress.com/2021/10/20/managing-technical-debt-1/) and having these as a flow item type should make them more visible. There are security and […]
[…] posted about Technical Debt on numerous occasions (see my last post here https://davebrowettagile.wordpress.com/2021/10/20/managing-technical-debt-1/). The term was first coined by Ward Cunningham that attempts to describe […]