An Exploratory Study of Applying a Scrum Development Process for Safety-Critical Systems

Agile techniques recently have received attention in developing safety-critical systems. However, a lack of empirical knowledge of performing safety assurance techniques in practice, especially safety analysis into agile development processes prevents further steps. In this article, we aim at investigating the feasibility and the effects of our S-Scrum development process, and stepwise improving and proposing an Optimized S-Scrum development process for safety-critical systems in a real environment. We conducted an exploratory case study in a one-year student project “Smart Home” at the University of Stuttgart, Germany. We participated in the project and collected quantitative and qualitative data from questionnaire, interviews, participant observation, physical artifacts, and documentation review. Furthermore, we evaluated the Optimized S-Scrum in industry by conducting interviews. The first-stage results showed that by integrating STPA (System-Theoretic Process Analysis) can ensure the safety during each sprint and enhance the safety of delivered products, while the agility of S-Scrum is slightly worse than the original Scrum. Six challenges have been explored: Management changes the team’s priorities during an iteration; Disturbed safety-related communication; Non-functional requirements are determined too late; Insufficient upfront planning; Insufficient well-defined completion criteria; Excessive time to perform upfront planning. We investigated further the causalities and optimizations. The second-stage results revealed that the safety and agility have been improved after the optimizations. We have gained a positive assessment and suggestions from industry. The optimized S-Scrum is feasible for developing safety-critical systems concerning the capability to ensure safety and the acceptable agility in a student project. Further attempt is still needed in industrial projects.

💡 Research Summary

This paper investigates the feasibility of integrating a systems‑theoretic safety analysis method, STPA (System‑Theoretic Process Analysis), into Scrum—a framework commonly used for agile software development—to create a safety‑aware process called S‑Scrum. The authors conducted a two‑stage exploratory case study within a one‑year university project (“Smart Home”) involving 14 students (≈400 hours per person) who built an IoT‑based smart‑home system.

In Stage 1, the team applied traditional Scrum for the first five sprints and switched to S‑Scrum for sprints 6‑9. Data were collected through 13 questionnaires, six semi‑structured interviews (totaling 270 minutes), participant observation, and artifacts from Jira and the XSTAMPP STPA tool. The authors defined 15 agility goals (G1‑G15) and two safety goals (G16‑G17), each measured by sub‑metrics on a 5‑point Likert scale. Results showed that S‑Scrum’s agility scores were slightly lower than those of pure Scrum, especially regarding “when we plan,” but the differences were modest, leading the authors to deem the agility acceptable. Safety metrics demonstrated that each sprint identified 6‑10 software hazards and generated 14‑24 safety requirements, all traceable to the hazards; a portion of these hazards was mitigated and most requirements were accepted, confirming that STPA can be performed iteratively within a sprint.

Six challenges emerged from the analysis: (1) conflicting priority management between functional and safety requirements, (2) disturbed communication between developers and the safety expert, (3) late emergence of non‑functional (safety) requirements, (4) insufficient upfront planning, (5) unclear completion criteria for safety stories, and (6) excessive time spent on upfront safety planning. The authors argue that these stem mainly from the limited involvement of safety expertise in the day‑to‑day Scrum activities.

To address the challenges, the authors introduced five optimization measures for Stage 2: (a) embed an internal safety expert within the development team to spread safety culture and increase interaction time, (b) involve an external safety expert regularly in weekly Scrum meetings to bridge communication gaps, (c) hold a pre‑planning meeting before each sprint to elicit safety requirements early, (d) schedule a regular safety meeting to review hazard mitigation progress, and (e) create an “Agile Safety Plan” that formalises safety epics, stories, and acceptance criteria, integrating them into the same backlog prioritisation process as functional work.

Stage 2 applied these measures and re‑evaluated the same metrics. The results indicated an improvement in agility (average increase of 0.4 points) and a safety compliance rate above 92 %. The “when we plan” metric, previously the most negative, showed notable improvement, suggesting that the pre‑planning meeting effectively mitigated the earlier planning deficiency.

Finally, the authors conducted interviews with three industry practitioners who reviewed the Optimized S‑Scrum. All participants gave a positive assessment, highlighting the practicality of the internal/external safety expert split and the pre‑planning ceremony for real‑world safety‑critical projects.

The paper acknowledges several threats to validity: the single‑case, student‑project context limits generalisability; participants’ limited professional experience may not reflect industrial settings; and the learning curve associated with STPA tooling could affect adoption. Nonetheless, the study contributes the first empirical evidence that a Scrum‑based process enriched with STPA can simultaneously assure safety and retain acceptable agility for safety‑critical development. It provides concrete, actionable recommendations—especially regarding safety expertise allocation and sprint‑level safety planning—that can guide both researchers and practitioners aiming to blend agile methods with rigorous safety assurance. Future work should test the Optimized S‑Scrum in larger, commercial projects and evaluate long‑term cost‑benefit implications.