# Software Project Risk Identification Based on Scrum Artifacts
## 4 Experimental Evaluation of the Risk Identification Framework
### Detailed Risks Analysis Stage Results for Project 1
Sprints 3, 9, and 11 were particularly notable, with 6, 9, and 7 attribute counts, respectively. These peaks were associated with the deployment of critical functionalities within the project. During these sprints, the team was required to concentrate on finalizing and deploying existing functionalities while simultaneously beginning the analysis of upcoming features. This shift in focus increased the potential for emerging risks due to distractions and competing priorities. The distribution of detected risks by artifact is illustrated in Figure 14. The number of detected risks represents the total unique risks identified per sprint, aggregated across each artifact. Although the number of detected risks is high, the proportion of registered risks compared to detected risks is relatively low, ranging between 10% and 51%. In Project 1, the team initially did not understand the risk management process. When the framework and associated process for risk analysis were introduced, the team initially intended to use it solely to identify risks without formally registering them. They assumed risks were adequately addressed during the sprint cycle and dismissed formal documentation as \"waterfall bureaucracy\". However, after adopting the framework, the team discovered that the registration process required minimal effort and decided to register the most critical risks according to the proposed process. This change allowed the team to log risks and monitor their resolution over time systematically. To demonstrate the distribution of detected risks across various sprints and risk categories, a heatmap is presented in Figure 15, where darker shades indicate a higher number of detected risks. This graphical representation facilitates the identification of sprints and risk categories with increased risk activity (risk categories RC5 and RC8 show no activity because they were excluded from the monitored risks during the adaptation stage). Notable peaks were observed in the risk categories RC3 (Communication) and RC9 (Agile Ceremonies), particularly during Sprints 3, 9, and 11. These peaks can be attributed to challenges in establishing an effective collaboration framework with the client in the project. The client inconsistently articulated their requirements and failed to provide all necessary details, leading to gaps in domain understanding and project execution. Additionally, discrepancies in the competencies of the project team and the clients' Agile practitioners further complicated the adaptation of Scrum practices. As a result, heightened focus was required to mitigate these risks. It is important to note that risks across different categories are interconnected; emerging risks in one category can potentially impact others. This interconnectedness often arises when the team concentrates heavily on one domain, inadvertently neglecting others. Monitoring detected risks over time provides insights into whether these challenges are isolated incidents or indicative of persistent, systemic issues. For example, risks associated with RC9 (Agile Practices) were particularly prevalent from Sprint 8 to Sprint 13 in Project 1, suggesting potential chronic difficulties in this area. In Project 1, the introduced framework facilitated an expanded risk analysis scope, encompassing the level of artifacts and their associated attributes, and the context of identified risks. As this approach was newly adopted, risk analysis was conducted during stand-up meetings, with the technical manager responsible for formally recording identified risks. The team consistently reviewed the status of registered risks and observed a shift in focus across different risk categories at various project stages. For example, risk R001 (Undefined Requirements) of the RC1 category was more frequently registered during the middle phase of the project. However, by the project's conclusion, although R001 continued  
Figure 14: Comparison of detected and registered risks by artifact.