Technical debt, more commonly known as tech debt, is a general term given to tasks or stories in a product backlog to address several common categories of issues.
The shared theme among these issues is that resolving them typically doesn’t directly change or improve a product so they are generally assigned low priority and teams usually have to negotiate with a product manager or leadership to get them into a sprint.
The general categories of these issues are:
- Rushing to build a feature to meet a date, resulting in subpar code or architecture that will need to be revisited later.
- Architectural changes that don’t affect the general function of a product but may be needed for other reasons (e.g. team skill set alignment, code efficiency, development speed, etc.).
- Platform changes where code needs to be reworked to support a target platform (e.g. major browser updates, iOS/Android updates, etc.)
Teams should take an intentional approach to dealing with tech debt. When tech debt becomes unmanageable, the ripples are felt throughout the organization in the form of burnout from trying to level the mountain.
Before this happens, the product team (engineering and product) needs to deliberately assess, prioritize, and assign tech debt tasks into sprints. Tech debt should be reviewed on a regular basis during Backlog Refinement. Many teams will dedicate five to ten percent of their sprint velocity to tackling tech debt each sprint.