## 1 Introduction  
The evolution of telecommunication software in use, in an ever-changing landscape of technologies, tools, and business models causes massive creation of technical debt [1]. However, its understanding evolves in time, and a widely used definition is as follows: _\"In software-intensive systems, technical debt consists of design or implementation constructs that are expedient in the short term, but set up a technical context that can make a future change more costly or impossible. Technical debt is a contingent liability whose impact is limited to internal system qualities--primarily, but not only, maintainability and evolvability\"_[2]. Additionally, technical debt embraces a set of actionable product technical debt items (TD Items, TDIs) indicating these immature artefacts and their deviation from the desired optimal state. In our previous paper, we claim that the technical debt definition should be expanded to embrace all software artefacts responsible for delivering a product to a customer [3], as the business perspective shifts towards a service model, rather than a one-time sale. Moreover, even with a one-time sale, the seller is responsible for providing agreed-upon service (bound by Service Level Agreement) for a predefined period of time. Hence, all software artefacts constituting a stable development environment, ensuring testability (automation), code analysis tools, continuous integration and delivery, etc., may be subject to technical debt dynamics. For this reason, they should be considered a part of the telecommunication software solution, which becomes actually a service offered to the customers. Moreover,properly targeted improvements in such a broader context may improve an overall solution: its stability, testability, ability to deliver updates fast; additionally improving predictability of the development team [3]. The outbreak of the coronavirus pandemic (COVID-19) has caused an unprecedented worldwide disruption to personal lives, global economy, and operating procedures of organisations. The field of software engineering was not immune to it, and particularly the initial plan for the industrial case study discussed in this article had to be modified, taking into account forced working-from-home policy. This paper presents the initial results from an over one-year-long case study, and describes the application of the technical debt prioritisation technique to a product managing a fleet of connected devices for a video surveillance system. We decided to use the modified Continuous Debt Valuation Approach (CoDVA) technique for technical debt valuation and prioritisation, which we developed earlier [4]. Additionally, a prerequisite to successful application of CoDVA method was a robust technical debt identification step; in our case, it was executed according to the Wisdom of Crowds approach [5], which proved to be effective in other experiments [6]. Ultimately, we posed a research question: Is prioritising technical debt reduction based on CoDVA effective (i.e., executed as per plan, bringing tangible benefits)? In our case study, a few interesting observations were made. Namely, the implementation of technical debt reduction did not follow exactly the expected guidelines. We have discovered three major reasons for that: implementation of continuous refactoring approach, the size of desired technical debt reduction effort (planned refactorings), and additional required activities which were not originally considered a part of technical debt reduction. Now, after considering the results, we propose to adopt a specific definition of technical debt and follow a few rules for defining the scope of technical debt reduction, prioritising it, and executing refactoring efforts to improve overall software quality and maintainability. The initial results of this industrial case study proved that the quality of the product improved over time, as a downward trend of stabilisation issues was observed.