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.
I like to think of having three types and three sizes – note that "Planned" and "Unplanned" are our classification, not how the technical debt is managed!
I would hope that any Unplanned/Large technical debt would be spotted as early as possible(!) but hopefully this will give you a framework to discuss technical debt within your teams.