Considerations

Technical Debt is a consequence of our desire to engineer incrementally and because we sometimes decide to convert the work to correct some escaped defects Into Technical Debt. We engineer incrementally to experiment, to ensure early delivery of value and to avoid over-engineering solutions. Feedback is essential in providing the data to understand the value we are creating and when we reach the point of over-engineering.

Technical debt arises because the simple way we engineer an initial version of a feature may lack sufficient robustness or flexibility to be easily extended to form the later versions. We achieve rapid deployment, allowing business value to be obtained quickly, at the cost of the technical debt of having a simple implementation.

Technical debt may include the use of near obsolete systems infrastructure in order to defer the necessity to update it today.

Finally, technical debt may arise because our testing is insufficient to prevent escaped defects and we subsequently choose to convert the corrective work into backlog items.

Plans to resolve Technical Debt arising from incremental engineering will typically involve creating backlog items that partly or in whole will repay elements of the technical debt. These backlog items are prioritised relative to other backlog items so that, by the time the feature is 'complete', enough technical debt has been repaid to meet the customers needs.

Where technical debt is created to correct escaped defects, teams plan how the technical debt will be resolved. The technical debt is defined by items added to the backlog (or sometimes to the Roadmap) to fully resolve the escaped defect in a slightly longer timescale.

Levels

Green

Work Remains Predictable Despite Technical Debt

Product Teams understand the scale and complexity of the Technical Debt they are incurring. They have clear plans to repay technical debt that has been incurred by deliberate choices that support incremental engineering.

Exceptionally, where it is decided to resolve an escaped defect as Technical Debt, plans are formed by adding items to the Backlog, or for longer term plans, to the Roadmap.

The predictability of the work of the team is not impacted by the presence of technical debt.

Amber

Unrecognised Technical Debt Lessens Predictability

Product Teams do not have a comprehensive view of Technical Debt. Without a clear view, it Is impossible to plan how to repay Technical Debt.

When unrecognised Technical Debt is identified (perhaps to resolve escaped defects) teams effectively plan how to resolve it. These plans will sometimes need to be carried out very quickly causing other work to be re-prioritised or deferred.

The predictability of the work of the team is substantially reduced because of Technical Debt.

Red

Reacting To Technical Debt Makes Work Unpredictable

Product Teams do not have a coherent understanding of Technical Debt. Lacking resilience being reactive, Product Teams often choose to correct escaped defects by converting them to technical debt.

The work of teams is frequently and substantially re-prioritised to help it deal with the consequences of Technical Debt.

The work of the team is unpredictable partly as a result of the lack of understanding of technical debt.