Technical debt management 2017-07-17T11:48:18+00:00

Technical debt management

Interested in implementing a relevant and exploitable technical debt indicator?
How to avoid the trap of too many abstract indicators.

Technical Debt, An indicator with high ROI

By its simplicity, the concept of technical debt quickly became the baseline indicator for quality assurance management of software projects. Initially invented by Ward Cunningham in the 90′s, the Technical Debt consists of those tasks (feature, bug fixing, code refactoring, architecture optimizing, etc.) that a development team would – whether willingly or not – delay to a later sprint or product release.

It immediately provides the team with a breath of fresh air, but as with any other kind of borrowing, the later you reimburse the debt, the higher the interest will be. In other words, if a feature costs 100 to be developed today, it will cost 100 + something tomorrow, 100 + something higher the week after and so on. Thus, the higher the debt, the lower the innovation and competitivity.

Being able to analyze and manage a project’s technical debt is crucial to avoid this loss of productivity and reactivity.


  • Relevant and Useful Indicator: Technical Debt weighs heavily on teams’ agility and their capacity for innovation. A high Technical Debt means significant efforts are allocated to corrective maintenance, to the detriment of new feature deliveries’ added value. A tech debt indicator will highlight the quality gap of software with regard to product quality requirements and the defects found in the project.
  • Easy to understand: Technical Debt speaks for itself when displayed in UOW (time, money, etc.), from the CIO to the developers through DevOps. For example: We need to allocate 30 man-days to make the project comply with reliability requirements, as defined in our quality model.
  • Easy to deploy: at its simplest, Technical Debt is computed by cumulating workloads of non-conformities.
  • Reconciling managerial and technical visions: by providing stakeholders with relevant, understandable and non-ambiguous information, they use a common framework to act on genuine software quality issues, rather than discuss the definition of the indicator itself.
  • Task-oriented and objectified, by nature: Computed from non-conformities found in the project (code, documentation, requirements, etc.), it allows you to list the measures required to reduce your Technical Debt.


  • A turnkey analysis model, with standardized control points to measure and manage the quality of developments.
  • A rating system that is easy to understand (with A, B, C, D, E and F grades) and provides accurate information (Technical Debt estimates in man-days or currency, etc.).

  • A fast highlighting of risks and quality issues in a project portfolio.
  • Indicators taking into account not only code-collected data, but also the project’s functional requirements, documentation quality, etc.
  • Automated Task Plan generation, optimized to reduce your projects’ Technical Debt efficiently.

What you can do