## 6 Conclusions and Future Work  
COVID-19 pandemic outbreak triggered a search for a solution to address inter-team dynamics of communication caused by forced working-from-home mode, especially that this team took at this very moment the responsibility for product development and its maintenance strategy. Therefore, in order to ensure a highly participative approach focused on technical debt management, the Wisdom of Crowds technique was used for technical debt identification and its alignment with business roadmap. It helped to mitigate communication challenges the team faced during the COVID-19 pandemic time, and keep all team members engaged in improvement efforts. An extensive discussion on technical debt prioritisation techniques was covered by the initial paper introducing the CoDVA approach. We perceive the originality of the CoDVA approach in continuous prioritisation of TD Items relying on the business perspective. This enables relative comparison between TD Items, which in turn drives prioritisation [4]. The techniques of prioritising technical debt as well as understanding the dynamics of its reduction process allow for rational spending of limited funds and reasonable balancing of efforts between the software product development and optimization of the current codebase. Adopting the CoDVA approach for technical debt prioritisation resulted in tangible benefits. Particularly, one year after technical debt reduction effort was incorporated into the process,releasing a new product version required 6 times less stabilisation cycles (removal of key issues discovered at the final stages of testing) than initially. The engineering team improved the product in a way that adding new functionality was easier and less error-prone, hence achieving faster time-to-market. Technical debt refactoring was following the plan in general (top-most improvements were applied); however, a few lower priority TDIs were refactored as well. Considering the overall cost of investments this is a desired situation, as the engineering team used the opportunity of ongoing development not only to add new functionality but also to improve the exact part of the code they were currently working on. The cost of adding a refactoring change in the same context as a new development is usually significantly lower than opening a new context and introducing the change there, which makes the continuous refactoring approach useful and desired. Another factor which should be considered is sizing of technical debt items. They cannot be significantly bigger than the effort required to develop a new feature, as they will be constantly postponed. The biggest size of a single TD Item implemented in this case study was not surpassing the cost of a middle-size feature. Moreover, refactoring of these bigger TD Items should be explicitly planned and agreed upon with the Product Manager. Finally yet importantly, we also observed some minor dynamics of TDI priorities presented in Table 1 caused by the changing feature roadmap priorities. However, as the fluctuation was negligible, we refrained from explicitly showing this dynamics. In order to achieve better predictability of the execution of technical debt roadmap we claim that the following rules should be applied:  
* Proper sizing of TD Items small enough to be considered for implementation,
* Shifting focus towards more costly TD Items,
* Limiting the number of explicitly allocated TD Items for refactoring (limiting work-in-progress),
* Embracing continuous refactoring approach for smaller TD Items,
* Broader, service-like, product context: CI/CD related refactorings should be treated with the same focus as the sheer product codebase (they should be considered a part of a product by definition), and prioritised accordingly. As this is the second application of the CoDVA technique, we assume that the proposed approach can be replicated, and the results may be generalised for telecommunication software.