External material for "How Do Practitioners Manage Traceability of Technical Debt in Continuous Software Engineering?"

How Do Practitioners Manage Traceability of Technical Debt in Continuous Software Engineering? - External material 1 This document presents the external material associated with the qualitative study of traceability of technical debt (TD) in continuous software engineering (CSE) submitted for TechDebt 2026. It mainly presents the codes arisen from the open coding phase and quotations from the interviews to support auditability of the results. Code: TD awareness P1: “We implemented something that, at the time, wasn’t the best way to do it, but we had to because of an urgent request or a tight deadline that required us to push it to production quickly. So we deal with technical debt that way: acknowledging that it will have an impact, but mapping that debt so it can be addressed later in the backlog.” P2: “So, in the early stages, when the company was in a growth phase, we wanted to do a lot of things quickly, and sometimes we ended up leaving a lot behind. It could be testing, CI processes that weren’t properly set up, or experiments that weren’t fully carried out. So, when it came time to make changes, it was really difficult, and we ran into a lot of problems.” P3: “It’s something we usually do to meet immediate needs. Sometimes we need to act quickly and end up not doing things in the best possible way. That leaves technical debt that we need to pay attention to later. It’s something that can cause problems down the line and may cost us time on future tasks.” P4: “During the software engineering or development process, we make several decisions along the way, like using library X instead of library Y, or taking one approach over another. These decisions are made to optimize the process. Technical debt refers to decisions that provide short-term benefits but create significant long-term drawbacks. For example, choosing not to write unit tests would be considered technical debt in this sense.” P5: “I see this “technical debt” box as, sometimes, depending on the overall project, a sort of rug where you sweep things under. And sometimes it really has to be done. I understand technical debt as something that wasn’t completed, a missed improvement. What exists now is working well, and we plan to come back to it later because we ran out of time. Technical debt is essentially something we didn’t have time to address.” P6: “Technical debt consists of issues that get overlooked during a delivery and need to be resolved for the product to be complete and free of problems.” P7: “Something we developed a year ago might, when we look at it today, have a better way of being done. Or even at the time, there might have already been a better approach, but the developer simply wasn’t aware of it.” P8: “For me, technical debt is a part of the code, or a solution that was implemented to solve a problem or deliver a feature, but this solution, what we call technical debt, is not easy to maintain. It creates some difficulty both for the team and for the business.” Code: TDM processes P1: “I map it out and add it to the backlog to be implemented later, when there’s time to work on it. So, currently, we create more stories on the board in Jira, a board specifically for technical debts, and we tackle them as time becomes available.” P2: “There is some level of management, at least within the company. Each team has a lead, and there’s usually someone more senior, a staff member, whose role is to keep an eye on these projects. They work somewhat externally, helping people and trying to manage this part a bit. Then engineering might come and say, “Hey, we want to revisit this,” and product gets involved. That’s when this senior person steps in and says, “No, everyone, we need to stop — this was meant for that purpose, and if we don’t, it’s going to become a problem soon.” P3: “It’s not a formal process. Usually, it isn’t, because we need to stay aligned with the business. Our focus is on delivering features, so it doesn’t make sense to work on technical debt unless we’re already developing something. So, between other tasks, if I’m going to work on a class that has technical debt, I’ll fix it while I’m there, so the change goes in together.” P4: “No, there is no formal process, such as mapping technical decisions. There is no form, document, or tool that allows us to track the technical decisions that are made.” P5: “We have started projects by mapping technical debt and adding it to the backlog, leaving 20% of the sprint dedicated to technical debt. It was the first time I saw a formal process that allocated a percentage of the sprint for this purpose. In all the other experiences I can think of, there was usually a section on the Jira board or any other platform where technical debt was listed, but it was mostly forgotten. From time to time, in a retrospective, someone would say that no one was looking at technical debt. It was noted, but in practice, no one went back to it. As developers, we often want to address it, because technical debt can involve refactoring that improves a significant part of a feature.” P6: “Within a finished product, we need to decide what is important and what is not for the end customer. Because of this, at the beginning of the project, when we are building the structure, technical debt is completely informal. If something has a problem or is not working as expected, we leave it noted somewhere, like in Jira or Teams. Once we finish the structure or while building it, we address it. When we already have a more mature structure and a product in the hands of a customer or end user, we implement a more formal process, with someone responsible for testing.” P7: “Is it informal. Until recently, we handled it very little. It is mostly addressed only when there is spare time. There is no defined process for improving or removing technical debt. Some things we improve out of necessity, for example, if something has been deprecated across the project and all products must comply, we are forced to improve it. Even then, it is not always done in the best possible way because of time constraints. In most of the projects I have worked on, such as in previous companies, handling technical debt was almost non-existent. A legacy class or something no longer used would remain indefinitely without being removed. Improvements only happened when a bug occurred or a customer complaint was received. It was mostly handled out of obligation to resolve the issue.” P8: “I think management starts right at the first step, which is identification. Identifying technical debt begins when the team notices a part of the code that is difficult to maintain or often causes problems. That is the first phase: identification. Once it is identified and the team brings it up repeatedly, whether in meetings, post-dailies, or retros, we can see if the problem is growing and becoming a real issue for the developers and the team. This can delay delivery or introduce more bugs into production when we work in that area of the code. By understanding technical debt, we can see how much it is affecting the team. If it is causing frequent problems and everyone is talking about it, we try to find a way to address it based on our priorities [...] Recently, we have been working a lot with Jira. We can create an epic for improvements, such as front-end improvements, back-end improvements, or architectural improvements. Within that epic, we create the tasks.” Code: TD traceability process P1: “When it comes to traceability, we usually create specific spreadsheets for that purpose. For example, if I’m implementing a new feature that involves new technologies, we might have a dedicated squad to work on the improvements related to that implementation..” P1: “As I mentioned, in Scrum, for example, when we’re running projects using Scrum, we usually highlight the technical debts from the sprint during the retrospectives, that’s one of the discussion points.” P1: “So, it’s usually the Tech Lead who handles the prioritization of technical debts, while the Product Owner focuses more on the product side.” P2: “We have a strong habit, especially at a low level, of leaving notes in the code itself about things we’ve left unfinished or implemented in a less-than-ideal way, so they’re traceable and can be addressed later. This habit is always tied to the person who wrote the code. For example, we might leave a small to-do in the code: improve this part, enhance performance, reduce costs, and then come back to it in the future. Specifically, the company has what they call Tech Friday, which is a dedicated day where you don’t work on your regular sprint tasks. Instead, you focus on something like addressing technical debt you’ve identified.” P2: “I’d say it’s informal, because it’s not like anyone asks, “Hey, what do we have to work on?” You’d have to stop and review the code. But as developers, we usually know where to look if we actually take the time to check the code.” P3: “We usually notice technical debt when we encounter difficulty adapting something that should be easy to change. When we identify debt, I generally try to fix it immediately, refactoring some part of the system. If that is not possible, I raise the issue with the team and say, ”This system needs technical debt adjustments that will take a certain amount of time and require alignment with the business.” At that point, we create a card and start refining it so we can address these debts.” P4: “There is no internal process in the companies I work for that formalizes traceability. As I mentioned, we currently do not have a way to document this. Ideally, at least in some projects I have experienced, technical debt was tracked in a document, not with items that would impact the future, but with the decisions made, the reasons why they were made that way, and especially the considerations of what could go wrong in the future. For example, when choosing a technology stack, we had to list the technologies, justify why we were choosing them, and include any observations.” P5: “We try to keep it visible so that it is included in the sprint backlog. Then, during planning, it is added there. Of course, I have already developed technical debt, and how it is handled depends a lot on the team. Sometimes it is a tag in Jira, other times it is another type of task. We then follow the normal delivery flow, including testing to ensure it works. But as I mentioned, to be honest, I have often seen technical debt remain in the backlog while the sprint is filled with new features, leaving the technical debt forgotten.” P6: “The way we operate within my teams has always been to set aside a separate part of the board for technical debt. The usual practice is to open it in the backlog because it will be included in upcoming sprints. So within the backlog, we add this technical debt board, at least for the development part.” P7: “When the technical debts are smaller or more isolated, we usually just create a task in Jira and leave it in the backlog. These are the worst cases, because they are often not addressed or take a very long time to be resolved. For larger debts, which involve refactoring multiple classes of a feature or something similar, we can group them within an epic and assign a priority, whether low or high, placing them on a roadmap that fits with our development cycle [...] Usually, it is limited to just creating the tickets. The refinement process is applied mainly to these larger adjustments. Otherwise, we might create a ticket that gets resolved fairly quickly whenever some free time is available.” P8: “We identify it, see how much impact it has, use that to prioritize it, and then, after prioritization, bring it into development and complete the development cycle.” Code: Strategies and tools for TD traceability P1: “When it comes to technical debt related to infrastructure, I usually rely on the pipeline itself, its reports help us with the mapping. SonarQube is also a good tool. There are also some bug tracking tools we’ve used before, but for documentation, I believe we mainly use Confluence and Jira.” P2: “Besides the code, we use GitHub boards and have the habit of creating issues for the projects we’re working on. The projects are usually well documented, and we create issues as needed. Things that go beyond the code, or more general problems, are added as issues, while very specific code-related tasks stay in the code itself. Additionally, in our CI process, we always leave things like coverage reports and code analysis results available for whenever we want to check them.” P3: “We have some linters to check code readability and consistency. We also use Sonar in our pipeline, so every time a pull request is created, Sonar analyzes whether it meets the company’s defined standards. It is not necessarily the “most correct” way, but it is the company standard. Often, we have to make some adjustments based on that.” P4: “They were usually recorded in tasks, depending on the tool, such as Jira, Trello, or even in a report document. It was literally just a document in a Google Drive, just to have it registered.” P5: “Now that you mention Confluence, I remember that we documented technical debts there, creating pages for them. But thinking about it, basically, I only recall using Jira, Azure, or ClickUp, which I have also used before.” P6: “We do not have anything formal or specialized for technical debt; we use the same board that we use for other activities. In my previous company, that was Jira.” P8: “Jira is used mainly for identification, along with other tools we use in our pipelines, like SonarQube. These are the main ones, although other tools may exist. In some organizations, these could also be considered part of technical debt, depending on their needs.” Code: Challenges associated with TD traceability P1: “Most of the time, we’re focused on implementing new features rather than fixing technical debt, and that ends up being a problem. Having tools that can help during code reviews to quickly identify potential technical debt would really help. I also think having a more formal ceremony or meeting to discuss technical debts could be a good practice to implement.” P2: “We don’t really have a very formal traceability process. As you can see, most of it stays in the code or gets added to an issue, but it never reaches the point of creating a card, a board, or breaking it down into tasks. Whether we like it or not, once I say it, it stays in the code or in an issue.” P3: “To track technical debt, it is generally done by looking at the code that has already been developed. The tools only analyze the new code we are working on, like a new pull request, but they don’t cover the existing code. So it becomes difficult to get a full perception of all the technical debt. Usually, we only look at the parts we are actively modifying, little by little. Since it’s a very informal process, it mostly relies on our own perception. We don’t have a way to measure technical debt precisely. It’s quite subjective, what counts as technical debt for one developer may make sense to another. That’s why having a defined standard for the development team is important.” P4: “I think the biggest challenge I’ve faced is bringing to light the urgency, the impacts, and especially the consequences of these decisions. Many times, it’s not the programmers or developers, but analysts making the decisions, and they influence the entire project’s development.” P5: “I think the biggest challenge is convincing management that technical debt exists, because sometimes they don’t even want to acknowledge it and just want to leave it aside. Meanwhile, we, who care a lot about the quality being delivered, want to convince them that it’s important for this debt to be tracked and monitored. I understand that sometimes, clearly, there isn’t enough time.” P7: “Currently, I feel that mainly the leadership, who are responsible for deciding what needs to be done, don’t pay much attention to this. It’s not really their fault, but there is a lot of pressure from above to deliver what’s required. Addressing technical debt is not a priority for them, because it’s not something visible to anyone outside our team.” P8: “The biggest difficulty, as I see it, is more on the prioritization side. For example, you can create a technical debt item, but it might never be given priority and could even be forgotten. That is the part I think is the hardest because you always have to keep track of it. If you do not, it just gets lost.” Code: Practitioners’ wishes P1: “It could be a ceremony within the methodology being used. For example, in Scrum or another agile framework, that’s specifically focused on addressing technical debt.” P1: “Having a visual impact also helps the client — or at least the project’s engineering team — gain a better understanding, because many times the technical debt is something only the developer is aware of.” P1: “Another option would be a tool to help us track this more systematically. I think that would be really useful. There are some tools available, but they’re mostly focused on bugs or improvements, not on documenting technical debt that can be addressed later.” P2: “I think we could adopt some practices to make technical debt more visible within our agile system. For example, we could add it to the task board, start separating it, and say, “This week we’ll focus on value delivery, and this small portion will be tasks related to technical debt we’ve left behind.” Including it in the process helps a lot, and I think we should use more formal processes when addressing it, moving it out of the code, increasing visibility, and making it clear that we’re actively working on technical debt.” P3: “The traceability of technical debt depends a lot on the team’s knowledge. So, everyone needs to be aligned. In our team, we decided to use Clean Architecture and DDD for development. This way, we standardize everything we do, and the way we create things ends up following our standard, which reduces technical debt. Of course, this requires training. The team needs some time to learn, and I am not sure if companies are willing to provide that time for people to study.” P4: “A document of technical justifications. I think this is very interesting. That is, being able to at least have an initial mapping of why we did something in a certain way. These decisions need to be justified, with risks and consequences identified, basically what could go wrong. Traceability in management tools is very good because technical debt becomes something more tangible, closer to an actual task that can be solved.” P5: “I think I have already participated in projects that had a meeting, I believe it was after planning, which was basically a review of the things that existed. Sometimes planning takes a long time. Of course, adding another meeting can be extra, it needs to be carefully analyzed why it is being added. But I think when we return to the sprint, during planning, and are able to really check what is there, sometimes these ideas about what is missing come up. In the review, sometimes we would go through the screens. I have seen this happen a lot, going through the screens and noticing something was missing. Then this goes into technical debt [...] I do not know, maybe with AI coming along, it could do something to check what has been done versus what was supposed to be done. I believe technical debt could arise from something like that as well.” P7: “One thing I have already suggested in the team was to have, either once a month or once a week, a day or two set aside for this type of correction. We could go through and see what technical debt is registered in the tasks. Most of the time, it is something quick to resolve, and we could really work on it. The problem is that it is not carried forward because of the constant pressure from deliveries and such, which makes it difficult to stop and work on something that is outside our roadmap.” P8: “I think it would be, for example, having a solution that identifies this technical debt and shows it to people higher up, who help with decision-making, in order to advance the development of this technical debt. It would show how much it is impacting software delivery and also how it is affecting the organization.”