## 3 Methodology
### Technical Debt Identification and Prioritization  
Firstly, technical debt was collected during brainstorm sessions within the development team. The results of these sessions were discussed with stakeholders responsible for business return of engineering investments (Product Managers). Such refined technical debt was stored as separate records in the development database, one record for each atomic TD Item. A single record, stored in Atlassian Jira tool, described in detail: scope of work, estimated effort, product context pointing to an area requiring update, and potential consequences associated (justification for a change). Secondly, the prioritised business roadmap was discussed with the Product Managers. The differences between the CoDVA approach presented in our previous work [4] and the currently used one were briefly described earlier. The most important one referred to the refined valuation process. Instead of using pure monetary value of benefits (deriving it from expected sales), a broader perspective was adopted, taking into account parameters like investment size, alignment with overall product strategy, time-to-market expectations, and many more. As a result, the business value--called feature score (_f_score_)--was calculated by the Product Manager for each feature. The way how these parameters were combined to constitute feature score was at the discretion of the Product Management organisation, which is responsible for business return on engineering investments. The normalised f_score value (in the range 0-1) was called relative feature priority _f_priority. This formed a basis for prioritisation of the product roadmap. Thirdly, a mapping of TDIs on the feature roadmap was prepared (see a sample excerpt in Table 1 below). Such a matrix helped to understand the _TDI_impact_ of the refactoring effort on the product (provided as a t-shirt size estimation, respectively: S, M, L, XL), explicitly listing anticipated benefits. Next _CoDVA_INDEX_ for each refactoring was calculated, based on: feature priorities, feature sizes (_f_size_), TDI impacts, TDI costs, and a _release_cadence_ factor. The more features were positively impacted by a given TDI refactoring, the higher CoDVA_INDEX was associated with it. Additionally, feature scores were modified based on their assignment to future releases of the product (release_cadence). The later in the release chain the feature was planned, the lesser was its value taken into account for calculating CoDVA_INDEX, as the scope volatility for future product releases had to be taken into account. Expecting no changes in the scope of future releases, we may keep the values intact for the complete roadmap (release_cadence \(\rightarrow\) 1), expecting \(\sim\)100% change every release, there is no point for assessing anything beyond the features planned for the next release (release_cadence \(\rightarrow\) 0). The parameter release_cadence was calculated in retrospective mode, based on the content of the recent product releases. As a result, a prioritised list of TDIs was created, and a refactoring effort was planned accordingly. The following formula was developed to calculate CoDVA_INDEX for each technical debt item:  
CoDVA_INDEXi = \(\frac{\sum_{j=1}^{m}\text{f\_priority}_{j}\text{*release\_cadence}_{j}\text{*f\_ size}\text{*TDI\_impact}_{\text{ij}}}{\text{TDI\_cos t}_{i}}+\sum_{k=0}^{n}\text{CoDVA\_INDEX\_dependent}_{k}\) The following parameters: impact of TDIs on feature roadmap, feature size, TDI size, which were provided as t-shirt size values, were mapped on numerical values (in the range 0-1). Taking into account TDI_impact (evaluated against costs related to implementing a new feature, see assessment presented in Table 1), the potential financial benefits might be derived. However, as in this case study a fixed amount of effort was available for improvements, the more important aspect was the relative prioritisation among technical debt items, which ultimately drove the scope planned for implementation.