## 2 Related Work  
The technical debt term is broadly used; however, due to its metaphorical origin it gradually became ambiguous [7]. Therefore, the operational definition used in our work was quoted earlier in Section 1, accompanied by additional explanations. Moreover, the technical debt term also indicates the set of all technical debt items associated with the system [2]. An atomic technical debt item (TDI) points to an immature software development artefact indicating the difference between its current and desired state [4]. The act of reducing technical debt is called _refactoring_[8] or _remediation_[2]. The evolution of software development and delivery techniques, namely the adoption of the DevOps paradigm [9] and its Continuous Integration and Continuous Delivery practices (CI/CD) requires the technical debt perspective to follow. Hence, a broader pool of software development artefacts will be considered a part of telecommunication system or service [3], as more software artefacts undergo the technical debt dynamics. Actually, by monitoring the trends of maintainability metrics, we may determine in advance which parts of the codebase may likely be abandoned by developers and rewritten deemed non-maintainable [10]. Developers themselves may indicate explicitly introduction of technical debt (i.e., Self-Admitted Technical Debt), and its removal in many cases takes the form of rewriting the impacted code, rather than its correction [11]. However, we should avoid a trap of understanding technical debt only according to the scope presented by the tools, e.g., SonarQube [12]. Our understanding should revolve around the difference between the current and the desired state of the artefacts constituting a system or a service. Therefore, even an evolution of the system architecture model might be constantly monitored to preserve the desired quality level [13]. Moreover, technical debt can be introduced by a shift in the context the product exists in, when the system is used in other circumstances than originally envisaged. Also, new technologies might have emerged, invalidating what was originally deemed a good design decision. Therefore, the context evolution may be perceived as an act of incurring technical debt against the product, as it results in an evolution of its desired optimal state. As technical debt management should be the goal, not the relentless refactoring, many approaches to technical debt prioritisation emerged. The extensive secondary studies on technical debt prioritisation were presented in the work of [PERSON] et al. [14], and [PERSON] et al. [15]. Some papers are mostly conceptual; others discuss frameworks standardising the process of prioritisation of technical debt [15]. In our previous work, we introduced the CoDVA technique for prioritising technical debt [16]. This approach enables valuation of technical debt to prioritise its reduction according to the business perspective, i.e., indicating changes with the potentially highest positive impact on the future evolution of the product. The evolution of the product itself should be not only driven by adjusting the codebase to enable future changes (which is a risk in agile development approach), but should ensure an explicit allocation of effort to introduce bigger (e.g., architectural) changes [16; 17]. Hence continuous refactoring approach [18] driven within the context of ongoing development, may only be a partial solution. Moreover, the perception of the desired future state of the product is provided by the business representatives in the form of a product roadmap (a pipeline of future functionalities expected to be added to the system). An additional challenge for the case study design was the outbreak of COVID-19 disease and forced working-from-home policy adopted by the organisation. If the COVID-19 related health fears did not exist, the vast majority of companies would not even consider teleworking practices adoption in a massive way [19].