Choosing the appropriate indicators to make technical debt visible and actionable in a dashboard is the first step in taking a consistent approach to tracking and addressing it across teams. The lack of visibility contributes to mounting technical debt that slows down software delivery and negatively impacts quality.
Most efforts to remediate technical debt are often chaotic and reactionary. Consequently, software engineering leaders are unable to measure the risks and impact of technical debt on value delivery. As a result, they are unable to handle technical debt or respond important questions like:
- How much debt do we have in our code?
- Which debt should we fix?
- How much progress teams are making in remediating technical debt?
- How much business risk is buried in our technical debt load?
CODA Overview Dashboard
CODA Overview Dashboard make measurements broadly visible and accessible for software engineering leaders and other stakeholders, which supports following actions:
- Establishing a consistent approach for measuring technical debt across teams by identifying and aggregating the highest-impact risk items.
- Focusing on metrics that, when aggregated, provide insight into the impact of technical debt on value delivery, team behaviors and code quality.
- Communicating progress in managing technical debt to team and business leaders
Debt Risk
Technical debt represents a risk to achieving delivery of high-quality software. This metric goes from low to high and represents an aggregation of the three core measures: priority debt items, prioritized debt cost, and accumulation ratio. The more one of those measures are far from threshold, the more it contributes to a higher risk.
Priority debt items
This is the output of the technical debt prioritization process, or, in other words, the items that should be remediated first. CODA follows the PAID (Plan, Address, Ignore, Delay) methodology to prioritize items. Items that could cause a high impact (high severity) and are the most likely to realize this business impact (high probability) are the ones that should be remediated immediately (address). The table below illustrates the prioritization methodology:
| Name | Severity | Probability |
|---|---|---|
| (P)lan | High | Low |
| (A)ddress | High | High |
| (I)gnore | Low | Low |
| (D)elay | Low | High |
Prioritized debt cost
This represents the total cost of prioritized technical debt items. This is used to normalize the expectations about the overall cost of resolving the most important items, as well as to show how the impact of technical debt backlog affects the product budget.
Accumulation ratio
Presents a ratio of new technical debt identified versus items remediated. A ratio larger than one implies that more debt issues were found than remediated during the reporting period (the two most recent scans). A ratio less than one, on the other hand, shows that more technical debt items have been resolved than were identified in the period. Tracking a declining ratio overtime indicates that overall technical debt management is reducing risk in the instance. To get the most out of this metric, run instance scans on a regular basis (e.g.: every Friday, once a month, etc.), this can be easily accomplished using the scan scheduling feature.
Continuously track and communicate data insights
Software engineering executives must develop a schedule for reviewing the technical debt dashboard During this activity, they should examine progress on current top-risk items as well as changes since the previous report (such as upward and downward trends). On top of that, it is also important to keep business stakeholders informed on the technical debt management progress, so that they can negotiate approval and funding for remediation efforts.