Tech debt is a killer, if you keep accumulating and don’t have a plan to manage it – you’ll end up having a product refactor few years later.
And this doesn’t happen in few days, it’s usually a culmination of bad practices over a period of time.
First mistake –
The problem starts with incurring tech debt in the first place. Anything that is supposed to be done as part of that story, should be in your Definition of Done (DoD)
If that discipline is not there, teams end up incurring a lot of tech debt without even realizing.
Second mistake –
Let’s assume the DoD is good and something is dropped (e.g. writing automated tests), often it’s just left saying we’ll come back to it when we have time.
Instead, a tech debt story should be created to track this and must be prioritized instead of adding to a long list of tech debt. (I’ve seen 1000+ tech debt stories..)
Have some capacity reserved to take up tech debt every sprint.
Mostly its a struggle to prioritize tech debt. Sometimes it helps to just say 20% capacity (for example) has to be allocated to tech debt every sprint.
What else do you try to mitigate tech debt?
#RedefiningSoftwareQuality ✔ #Prioritization #SprintPlanning #TechDebt #Agile #WaysOfWorking