# Integrating Interactive Detection of Code Smells into Scrum: Feasibility, Benefits, and Challenges
## 4 Approach: Integrating ID Technique into Scrum
### Proposal Definition  
The ID and NID can offer advantages and disadvantages depending on the project's purpose and context. ID enables the identification and resolution of specific problems in local code snippets, improving code quality and reducing fix time. This approach proves faster and more cost-effective than globalized detection as it targets specific code areas requiring attention. On the other hand, the NID approach identifies broader issues throughout the software system. It proves most valuable in larger, complex projects with interdependent code components and widespread problems. However, NID detection requires more detailed code analysis across the entire system, making it more time-consuming and costly. According to a prior study, implementing appropriate processes can prevent the occurrence or persistence of software smells in a system. Conversely, ineffective or absent processes can lead to the emergence of software smells [3]. Despite various detection approaches, understanding \"how\" and \"when\" to apply them in the development process remains crucial. To bridge this gap, Figure 2 illustrates an approach integrating code smell detection techniques into the Scrum framework. Each numbered element in the figure represents a crucial component of the approach, and in the following, we offer a comprehensive description of each component. (1) Besides the Product Backlog, another crucial artifact is dedicated to managing code smell occurrences within the Scrum framework. This shared resource necessitates collective maintenance and engagement from developers [3]. It serves as a repository for documenting instances of code smells detected using the Non-Interactive Detection (NID) technique, providing a comprehensive overview of code smell prevalence throughout the project. Incorporating these instances into the artifact facilitates a holistic understanding  
Figure 2: Overview of the Approach for Integrating ID Technique into Scrum. of code quality, enabling informed decisions regarding code smell refactoring and overall software quality improvement. (2) During sprint planning, the team thoroughly examines and prioritizes code smell instances from the global list, employing predefined criteria and consulting with the product owner. To streamline this process, a combination of ID and NID techniques can be utilized. By leveraging both techniques, the team effectively addresses and validates the planning of code smell refactoring. This step is vital for determining which specific code smell instances will be transformed into actionable tasks for the upcoming sprint. (3) The prioritization and order of items in the global list are based on the severity and criticality of code smells, ensuring that the most significant ones are addressed within the sprint. Each identified code smell occurrence from the prioritized list is converted into specific tasks, considering the team's capacity and available resources. Factors such as granularity, spread level, and impacted code elements play a crucial role in determining the size and duration of these tasks. Subsequently, the tasks are assigned to developers responsible for executing them within the designated sprint timeframe. (4) Developers continuously evaluate the software artifacts generated during the sprint through their programming activities, employing the ID technique. Thus, whenever a new instance of a code smell is detected in the code, the developer conducts an initial assessment based on factors such as the spread level of the smell, the time invested in refactoring, and the effort required. This assessment helps determine whether immediate or delayed removal of the code smell is appropriate. In the latter case, the smell is added to the global list, and its resolution is deliberated in future sprints. (5) During the daily Scrum meetings, developers provide updates on critical code smells they have encountered and explain the rationale behind delaying their removal through refactoring actions.