Considerations

Understanding the scale and complexity of Technical Debt is critical to the ability of teams to sustain an acceptable level of Technical Debt. Early in the life of a solution. relatively high levels of technical debt may be acceptable because significant portions of the solution are experimental or are minimally viable versions of features that will be elaborated by incremental engineering.

As solutions mature, the level of Technical Debt must be reduced. This ensures that features are completed and excessive numbers of incidents are avoided at the time when active engineering of new features stops. Planned repayment of Technical Debt allows progress to this point to be predictable.

Levels

Green

Technical Debt Is Consistently Repaid

Product Teams consistently carry out their plans to repay Technical Debt. The volume and complexity of Technical Debt is, on average, reduced over time. There may be spikes in Technical Debt when significant new features are introduced. These are recognised and appropriately resolved.

There is awareness of the ageing of environments, third party components, open-source components and other infrastructure. These are replaced on a planned basis to avoid excessive cost of delay at end of life.

Technical Debt from escaped defects is repaid taking account of the operational impact of the defect.

Amber

Technical Debt Is Inconsistently Repaid

Product Teams do not consistently carry out plans to repay Technical Debt. Volume and complexity of Technical Debt may increase or stay constant for extended periods of time. There may be large changes in the volume of Technical Debt as urgent action is taken to repay undocumented Technical Debt.

Teams may be forced to fund high support costs because of excessive ageing of environments, third party components, open-source components and other infrastructure.

Escaped defects are not well prioritised because of a lack of understanding of the operational impact of different defects.

Red

Technical Debt Is Substantially Unrepaid

Product Teams have little understanding of the size and complexity of the Technical Debt in their solutions. Little or no attention is given to repaying Technical Debt.

Funding for high support costs may continue for a significant time because teams do not manage the ageing of environments, third party components, open-source components and other Infrastructure. These assets age excessively and risk becoming unsustainable.

A lack of understanding of operational impact and the relative Importance of other work means that Technical Debt from escaped defects is prioritised wrongly or left unresolved.