Agile Gamification Risk Management Process: A Comprehensive Process for Identifying and Assessing Gamification Risks

Abstract

Gamification has become a motivational technique for enhancing engagement and productivity, extending into agile software development. However, integrating gamification into agile frameworks such as the Scrum framework has led to the emergence of gamification risks, which may have adverse impacts on agile roles and tasks. These risks include an increase in the number of unassigned tasks affecting sprint velocity, novelty-seeking and quick boredom, clustering group, and intimidation, thus showing the need for a structured approach toward their management, their impacts on team dynamics and project outcomes. This study proposes the Agile Gamification Risk Management (AGRM) process, focused on identifying, assessing, and mitigating gamification risks in agile software enterprises. AGRM introduces artifacts such as the Gamification Risk Reporting Form, Personalized Risk Profiles, Task Impact Matrix, and Gamification Risk Register, enabling real-time proactive risk management. By leveraging a gamification risk taxonomy, AGRM categorizes and prioritizes risks, aligning mitigation efforts effectively. This paper details a two-phased empirical study to evaluate our proposed AGRM process. The proposed process identified 17 and mitigated 9 gamification risks for two agile teams in two software development enterprises. Unlike ad hoc practices, AGRM provides a structured approach, empowering teams to manage risks during sprint events. By incorporating artifacts like the Gamification Risk Register (GRR) and Personalized Risk Profiles (PRPs), teams can assess risks in context, enhancing productivity, collaboration, and project outcomes. The results demonstrate AGRM’s ability to boost team morale and confidence in addressing gamification risks effectively.

1. Introduction

Gamification is the “use of the game element in a non-gaming context”, defined by Deterding et al. [1] to encourage user engagement and improve their motivation towards the intended goals [1,2]. The integration of gamification into Enterprise Systems (ESs) has been the most intriguing phenomenon and has proven successful in different domains, such as banking [3], tourism [4], health [5], education [6], and enterprise resource planning (ERP) [7,8]. The global gamification market was valued at USD 9.9 billion in 2020 and is expected to reach USD 95.5 billion by 2030 [9]. This paper focuses on the gamification of software engineering [10], especially in the agile Scrum framework [11,12,13,14], and shows how the use of gamification has evolved significantly to motivate and engage software engineers in their work and help guide their behavior toward productivity improvements [10,15,16,17]. Software practitioners also acknowledge the benefits of gamification and use support tools, such as JIRA Hero, that implement essential gamification components [18], ScrumKnowsy [19], and Visual Studio Achievement [20].

Agile methodologies, particularly Scrum, have become foundational to software development practices because their iterative and incremental approaches are designed for flexibility, adaptability, and stakeholder engagement [21,22]. This methodology emphasizes empiricism and adaptations, leading to continuous feedback and continued planning [23]. However, while Agile possesses many strengths, it is not free of weaknesses. Scalability remains an issue, with Agile having initially been developed for small teams, and coordination in larger organizations proving difficult. The overreliance on highly skilled and self-organizing teams could cause difficulties in environments with less experienced developers. Meanwhile, Agile’s emphasis on a lack of documentation can act counterproductively towards long-term maintainability and knowledge transfer. Poor planning and changing requirements inevitably lead to scope creep, and it proves difficult to accurately estimate both cost and timelines. In addition, Agile’s high velocity and constant adaptability can burn out development teams. There have recently been studies reporting increased concerns about Agile’s effectiveness in real-life environments, with companies dropping and changing agile frameworks and reducing the use of Scrum Masters and agile roles. All these concerns serve to illustrate a need for formalized approaches to managing risks, particularly with emerging areas such as gamification, to make agile settings in modern software development environments and preserve its effectiveness and viability.

Gamification has been adopted in agile software development to address challenges related to the motivation, performance, and engagement of the agile roles (Scrum Master, Product Owner, Development Team) in their software development tasks and Scrum events. Previous studies have shown that improvements were not only related to the engineers’ motivation, engagement, and productivity in their tedious tasks, such as bug fixing, freeing up backlogs or writing unit testing, creating and prioritizing user stories, documentation, and improving employee performance [24,25,26,27,28,29] but also related to achieving organizational objectives such as developing [27,28,29] higher product quality, project performance, and better-defining goals [17,30,31].

The research in [31] has synthesized gamification in software engineering (SE), shedding light on some of the challenges that arise when gamification is implemented in an enterprise software system. Additionally, Ebert et al. emphasize trust deficiency and the possibility of cheating as notable concerns stemming from applying gamification in software development contexts [32]. The literature shows that gamification has led to the emergence of adverse side effects in enterprise systems [33], especially teamwork enterprises [34], education [35], and software development [36,37]. They refer to these as “gamification risks” that can detract from teamwork, job performance, and project success.

It was mentioned in principle that, due to the risk of gamification and adverse side effects, emergence was the predominant focus on points, badges, and leaderboards as the primary game elements [15,21,23,24,25,26,29], known as “shallow gamification” [38]. Studies related to gamified software engineering, agile software development, and software education tend to overlook various other game elements. Also, the adoption of a “one size fits all” gamification strategy applied to the enterprise system [34] that disregards user preferences and creates a universal design could lead to the emergence of gamification risks [34,39,40].

Meanwhile, the iterative approach of agile methods is beneficial in mitigating certain types of risk, such as product engineering, development engineering, or program constraints-related risks [41]. However, there has been increasing recognition that more explicit risk management (RM) practices must be integrated to address emerging challenges, especially in complex and large projects [41,42,43,44,45]. This gap has encouraged explicit risk management approaches, including risk registers [41,46], risk poker [47], risk checklist, risk assessment forums [48], and risk recommender systems [49] within agile frameworks to ensure positive project outcomes and reduce the chances of project failure. Such methods introduce systematic ways of predicting risks and mitigations while making the project management process resilient. The proposed agile risk management methods do not cater to the specifics of gamification risks within agile settings.

A systematic risk management process will equip teams to identify, evaluate, and mitigate gamification risks to ensure that gamification benefits can be accrued without compromising either team well-being or project outcomes. Although the number of adoptions of gamification in agile methodologies is increasing, comprehensive frameworks for managing those risks still constitute a gap in literature. None of the previously mentioned agile risk management frameworks addressed risks related to incorporating gamification into the agile framework, and neither did they study the nature of gamification risks and risk factors related to the software development domain. Thus, in this study, a new risk identification and assessment and management process is proposed to offer a systematic way to proactively handle and prevent the emergence of gamification-specific risks within agile Scrum by identifying, analyzing, and prioritizing risks.

This paper presents an Agile Gamification Risk Management (AGRM) process, which systematically identifies, assesses, and mitigates gamification risks within agile enterprises adopting the Scrum framework, hence responding to a literature gap concerning the management of such risks in software development. The AGRM process combines procedural steps, artifacts, agile roles, and measures for assessment to proactively handle gamification-specific risks while maintaining employee motivation in gamified environments. An evaluation study was performed in three phases: an expert pilot study, a control group without AGRM, and case studies involving two teams with the AGRM process.

Based on the previous multi-stage study [36,37], this paper involves qualitative research methods, such as semi-structured interviews and focus groups, that are used to (1) conceptualize gamification risks and risk factors in software development enterprises, particularly in agile Scrum; (2) provide a gamification risk taxonomy that would help with the risk assessment and management process; (3) design a software process model resembling the gamified Scrum framework, events, and roles; and (4) design context-inclusive risk profiles that consider beyond personality types as a contextual risk factor that has led to the emergence of risks, which we elaborate on in the Results section of this paper.

This research provides the following contributions:

• It presents the appropriate artifacts, assessment metrics, and deliverables needed to help identify, assess, and prioritize gamification risks within agile Scrum.
• It proposes AGRM processes for risk identification and assessment of gamification risks within the agile Scrum framework.
• It presents an evaluation of the proposed AGRM process.

The rest of the paper is organized as follows: Section 2 reviews existing concepts and literature for agile methodologies, gamification, and risk management, while Section 3 outlines the research methodology. Section 4 presents the previous study results: Section 4.1 presents the conceptualization of gamification risks and factors and Section 4.2 presents the gamification risk taxonomy and personalized risk profiles. Meanwhile, Section 5 presents the proposed risk management process. Section 6 describes the case study for evaluating the method, while Section 7 discusses the effectiveness of the proposed process. Finally, Section 8 summarizes the findings and provides recommendations for further research.

2. Background and Related Work

This section introduces the main concepts related to gamification in software engineering, agile methodologies, particularly Scrum, and risk management.

2.1. Background

2.1.1. Gamification in Software Engineering

Gamification is the application of game design to non-game contexts to influence users’ behaviors and attitudes. In [50], the authors propose that “gamification applies game thinking to non-game problems to drive business outcomes by encouraging people to engage in desired behaviors” by applying game mechanics that make tasks more engaging. Gamification is defined as the utilization of game design elements to induce “gamefulness” in daily activities, underscoring the significance of developing engaging and motivating experiences that can facilitate behavioral change and improve performance in a variety of fields [1]. In recent years, numerous studies have investigated the integration of gamification into various domains. This research focuses on incorporating gamification within software engineering processes and agile methodologies. Gamification boosts software engineers’ engagement and productivity by using gamification strategies to tackle mundane or uninteresting tasks. These studies have synthesized the gamification literature of software engineering by showing the state-of-the-art, the proposed solutions, and the remaining unaddressed challenges [10,16,17,31]. Barreto and Franca [17] concluded that the field tends to have a rigorous understanding of gamification; the effects of gamification in practice are unclear, and there is still considerable room for advancement in this field of study. Pedreira et al. [10], García-Mireles et al. [16], and de Paula Porto et al. [31] state that the most widely used game elements were points, badges, and leaderboards. Additionally, they noted that most software engineering activities supported by gamification were requirement elicitation [46,51,52], requirement prioritization [27,51], requirement management [53], software development [25,54,55], testing [53,56,57], project management [53,58,59], software process improvement [60], and support processes. However, many other software development activities, such as documentation, design activities, modeling, architecture, and reengineering, have been overlooked.

Gamification studies exist in principle to support software development in the agile context [12,13,25]. The authors of these studies mapped game elements into several agile SE activities. They stated that the most gamification-supported tasks for each activity were code review and agile support processes [61,62,63,64], stimulating registration of defects, improving team building, prioritizing user stories [27], prioritization of goals [65], requirements elicitation, and prioritization [66]. It was noticed in the literature that prioritized user stories was the most gamified activity; however, there was no justification for it [28].

A systematic and thorough methodology is still required to integrate gamification into SE. Comprehensive knowledge of how the inclusion of gaming components in SE activities and tasks might impact software developers and the tasks being carried out is lacking, as are details of the challenges that software engineers encounter while doing their work because of gamified systems.

2.1.2. Agile Methodologies and Scrum

Software development enterprises are challenged with the rapid succession of requirements due to the traditional requirements engineering approaches often needing revision, re-evaluation, and innovation. Secondly, they must continuously deal with changing requirements that may become obsolete before the projects are completed. This has undoubtedly contributed to the increasing growth and adoption of agile software development methodologies within software enterprises [67]. Agile development methodologies were introduced to the community with the publishing of the Agile Manifesto in 2000 [68]. These methodologies are at the heart of modern software development. They focus on flexibility, adaptability, and the pursuit of constant improvement. Core to agile is the understanding that iterative development breaks projects into smaller, more manageable segments or iterations that enable frequent reassessment to adapt to feedback and changing requirements. Agile practices like Extreme Programming (XP) [69] and Scrum [23] work on enhancing team agility, which usually affects inefficient processes when traditional plan-driven software development is concerned. A fundamental principle of agile development is effectively sharing high-quality information, knowledge, ideas, suggestions, skills, and expertise across its membership [70].

In this research, the focus is on the Scrum framework, as referred to by Leffingwell [71] as “a lightweight, agile project management method based on small, empowered, self-organizing teams; complete visibility; and rapid adaptation”. It is one of the most used agile frameworks [23,72], encompassing a structured yet flexible approach to managing this iterative process. Scrum has the following roles, as mentioned in the Scrum guide [21,23]:

• Product Owner: The customer representative who extensively knows the business rules behind the development of the product or can clarify it with the stakeholders in case of doubts. Responsible for maintaining the product backlog and prioritizing it based on customer needs.
• Scrum Master: This role ensures that Scrum is carried out according to principles, rules, and best practices by coaching and involving all stakeholders. He facilitates clarity regarding team goals and objectives.
• Development Team: A team of software developers collaborating in product feature development. It should be self-organizing and multidisciplinary, with up to eight people working on one-to-four-week iterations with representatives of developers, testers, and designers.

There are three major stages in the Scrum project life cycle: pre-planning, development, and post-planning [21]. During the pre-planning stage, representatives of customers and users define their needs by creating a prioritized Product Backlog. Development is organized in Sprints (iterations), starting with a planning meeting where the team discusses backlog items to select the sprint goal and delivery features. During the Sprint, progress in turn is monitored in short 15 min Daily Scrum meetings to review what has been accomplished. Post-planning occurs at the end of each Sprint, with a Sprint Review to consider the progress made and show the client the software’s status.

2.1.3. Risk Management

In project management, risk is defined as an uncertain event or set of circumstances that, if they occur, will impact one or more objectives. Effective project risk management shall be proactive and systematic, including the processes for identification, analysis, and response to project risks in either threats or opportunities. This process covers identifying risk factors, evaluating their probability and impact, formulating the proper responses, and monitoring and controlling risks throughout the life cycle. The risk factor involves a component that could affect either the likelihood or impact or both concerning any particular project, and its assessment would be warranted for the overall evaluation of Risk Exposure and the formulation of strategies for mitigation [73].

2.2. Related Work

This section discusses existing studies in the literature concerning gamification in software engineering in general, agile methodologies in particular, gamification risks, and agile risk management.

2.2.1. Gamification of Agile Methodologies: Benefits and Challenges

This section reviews notable studies on the gamification of software engineering, summarizing findings, benefits, and challenges. In the last decade, research has shown that the integration of gamification into agile practices such as Scrum enhances motivation, engagement, and task performance [14,15,16,17,31,74]. However, empirical validation is still scarce, focused on a few practices, and incompletely reported concerning the impacts. Further, broader and more rigorous research is required to fully realize the potential and implications of gamification [14,17]. Challenges such as reduced autonomy, cheating, demotivation, and decreased creativity have been identified, but their causes and solutions are yet to be fully addressed [31]. Moreover, other studies have presented the application of gamification in agile software engineering. For example, the gamification of the Scrum process increases the potential for higher engagement and effectiveness of staff in performing software engineering tasks. Gamification in agile processes, like Lean UX integration within Scrum [12], has improved collaboration and engagement through game elements like points and rewards. However, challenges include scalability, balancing intrinsic and extrinsic motivators, and aligning gamified workflows with agile priorities. Studies also highlight the complexity of designing effective strategies and sustaining long-term engagement, as individual motivations vary significantly [26].

Also, a gamified framework exists to improve specific SE activities [63]. The authors suggested the creation of a framework to reduce the cost of implementing gamification efforts and make this field more accessible to organizations looking to enhance their software process. In [62], Eggert et al. noted a gap in the gamification of software systems targeting software developers was noted. They suggested a set of affordances and design guidelines. However, they neglected to include main contextual factors such as personality types and tasks when proposing their solution. However, endeavors employing points and badges do so most often without a conceptual rationale, and a common approach seems to be pontification considering only one personality factor, conscientiousness, as categorized by the Big Five Factor (BFF) [75], neglecting other motivating game elements for different personality factors.

Moreover, other studies have focused on integrating gamification into software engineering education. Marín et al. [76] underline that gamification in software engineering education enhances the engagement and motivation of students in learning, skills in teamwork, and problem-solving skills. However, there is also a downside concerning designing efficient gamified systems, balancing fun and learning, being inclusive for all learners, and maintaining long-term interest once the novelty factor decreases. These insights underline the need for thoughtful implementation of gamification to maximize its benefits. Adverse outcomes related to education include no effect, deteriorated performance, motivational problems, lack of understanding, and irrelevance. Attempts have been undertaken to relate game design elements with the potential adverse effects they might trigger. This systematic approach allowed the designers to pragmatically evaluate the possible negative consequences of gamification in educational software and make an informed decision, aiming for the best balance between engagement and efficacy in education [27,28,60,76,77,78]. Lencastre et al. [27] state that, among other benefits of gamification, it increases users’ activity, motivation, and collaboration in mundane activities such as prioritization of requirements, making them more interactive and enjoyable. They offered a PRIUS framework that allowed improvements in quality based on well-defined roles and their systematic use. These include discouragement if gamification elements are designed poorly, if there are issues related to scalability, or if the overall engagement remains superficial. A more profound level that requires proper alignment of such design with the concepts of agility assures meaningful benefits.

There are no current principles and guidelines available in the literature on how to effectively use gamification in agile settings, considering the multi-contextual nature of gamification. Further research is needed to identify specifically how the incorporation of game elements in software engineering activities would influence the role and responsibilities of Scrum Team members and how their activities could be effectively gamified in the Scrum process.

2.2.2. Gamification Risks in General and in Agile Methodologies

The literature discusses the adverse side effects and challenges of gamification from a general point of view [34,79,80,81,82], and in software development [31] and software engineering education [60]. Several scholars have identified the deficiencies in using a “One-size fits all” approach in designing gamified enterprise systems and attributed that to the adverse effects of gamification on diverse users across various contexts, such as education and ES [34,83,84,85]. The first strategy for mitigating gamification’s negative effect on users may be explored within the merits of personalized and tailored gamification approaches [85,86,87]. In [88], seven problem domains were identified as problem domains of the gamification risks, including motivation, addiction, communication, manipulation, data integrity, surveillance and privacy, ethics, and exploitation. None of them came from studies within the area of software engineering.

Moreover, Gros and Van De Leemput [79] synthesized 187 studies that identified the limitations, challenges, and risks of gamification. Despite such an in-depth review, adverse effects relating to user behaviors still appear, reflecting a severe deficiency in both the conceptualization and mitigation of gamification risks. By this, we begin to look deeper into conceptualizing the negative impact of gamification in agile software development roles and tasks, identifying which of those roles, and with what associated personality types, could be most prone to experience gamification risks, and developing strategies that could reduce adverse effects. Fulcini et al. [89] pointed out some problems with integrating gamification into software testing. Not every situation can make use of gamified mechanics. It is underlined that such mechanics must be carefully adapted. They need first to be tailored to the testing objectives; secondly, they need to prevent misuse by players, and lastly, they should not have any disturbing effects on the effectiveness or efficiency of a task.

Say et al. [90] explore the effect of leaderboards on developers within gamified software quality contexts. Negative effects were observed on motivation, perceived competence, and fairness concerns. For example, the lower-ranked developers were likely to feel inadequate. The other contextual factors that could also be taken into consideration in studies, according to the results, included team dynamics, individual differences in competitiveness, the complexity of tasks, cultural influences on the perception of performance, and how the leaderboard criteria are transparent. With this in place, there can be more detailed experimentation regarding the effects of leaderboards. In addition, the impact of incorporating time pressure [91] into a requirement, and its elicitation as a gamification element, leads to hindering creativity. This may elevate stress levels among individuals participating in the gamified task, impeding their creative ability. As mentioned by [36,37], incorporating game elements that do not align with the task type would affect the employee’s ability to perform such tasks and negatively impact the task quality.

Algashami et al. [34] identify the term “gamification risks” from the following five risk factors: performance, societal and personal aspects, goals, tasks, and gamification design, presenting 20 risks comprising performance misjudgment, loss of joy, missing cohesion, bias, or disengagement into well-being and ethical and productivity-related risks. However, their domain was teamwork enterprises like call centers, which differ from an agile Scrum environment in tasks that are rewarded individually, separate roles for accountability, and structured Scrum ceremonies. While the two contexts share some overlying risks, our work extends these insights by studying the negative impact of gamification on agile roles and agile activities.

In [36,37], we focused on conceptualizing gamification risks and related factors in software development. Inclusive gamification risk identification and assessment facilitates the design of gamified Scrum processes that would be less prone to the emergence of gamification risks. We aimed to relate different context-related factors with identified gamification risks to help in the development of context-inclusive gamified systems. The study pointed out the importance of classifying gamification risks based on not only personality but also on agile roles. Risks emerge based on how agile roles perceive gamification within their tasks. To create an inclusive risk assessment process for an agile software development context, we investigated the impact of gamification on agile roles and tasks. We identified which roles and personality types, respectively, were most prone to encountering gamification risks. In conclusion, we proposed strategies to mitigate such adverse effects. As a result, a list of 73 risks associated with gamification in agile environments was identified and categorized into six categories. For example, decreased motivation and increased stress and anxiety are categorized as psychosociological risks. Bias and fairness of agile team members and finding ways to cheat the system for rewards are categorized as ethical risks. Understanding the risks and their contextual factors has led to the development of a gamification risk taxonomy and the design of inclusive risk profiles. This has laid the foundation for designing risk assessment and management processes within the Scrum framework. This risk management process will not only identify gamification risks but also provide a way to assess and prioritize the risks, offer preventive actions to prevent these risks from occurring, or reduce the possibility of their occurrence.

2.2.3. Risk Management in Agile Methodologies

Risk management is essential in software engineering for decreasing uncertainties, increasing project predictability, enhancing product quality, and helping with informed decision-making processes [42,92,93,94]. Applying systematic methods to identify, evaluate, and mitigate risks strongly enhances the likelihood of the software development team delivering successful and effective software solutions [73,95,96]. Even though there is considerable literature on the subject of general risk management in software development [42,97,98,99], within agile development particularly [28,49,100,101], integrating risk management as an integral part of project management is still crucial. The main goal of risk management is to detect prospective risks that may happen and minimize their impact on the objectives of the project and its success as a whole [42].

To that end, some recent research has been done on frameworks and tools for assessing the potential risks for gamification within agile settings. For example, Garcia et al. [41] conducted a systemic literature mapping, identifying 23 studies that explicitly integrated risk management into agile methods. They concluded that, although agile philosophies have typically ignored explicit RM practices when included in specific domains such as requirement, scheduling, and communication, they significantly increase project success by reducing the propensity for failure. Fourteen studies integrated RM into Scrum. Only two studies from the 23 had integrated RM into their agile practices, such as brainstorming, pair programming, daily meetings, incremental deliveries, and prototyping. All the others have also implemented new RM practices. Some of these include risk lists, registers, risk assessment forms, risk ranking, risk cards, etc.

In [45], different risk-mitigation techniques within agile development are described. These underline the need for flexibility and continuous feedback in managing risks. The study gives a comprehensive overview of strategies to identify and mitigate risks, especially for large-scale and complex agile projects. They highlighted the need to incorporate RM practices into agile frameworks to identify and reduce risks proactively. According to the authors, sprint planning meetings are vital in identifying possible project risks and designing strategies for mitigating such risks.

Regardless, risk management concerning gamified agile software development has not yet become widely researched; thus, there is a significant gap in knowledge about how to understand and act on risks associated with the gamification of agile software development. In this respect, this research proposes an Agile Gamification Risk Management process that builds on existing risk management practices, addressing the different aspects introduced by gamification. With apparatuses like risk registers and risk assessment forums provided by the AGRM process, teams can systematically assess and prioritize gamification risks. This practice would then be integrated into everyday Scrum activities to ensure that risks are continuously monitored and mitigated throughout a project’s life cycle. Our AGRM process builds on the previous work mentioned in the subsection above [36,37].

3. Research Methodology

This section provides a concise and precise description of the experimental results, their interpretation, and the experimental conclusions that can be drawn. This paper introduces the concept of “Inclusive Gamification”, coined previously in [36], where the authors emphasize considering gamification risks with broader contextual factors rather than personality types only. We call them context-inclusive gamification risks. For the research study, a qualitative research methodology approach [102] is adopted due to the exploratory nature of this research. We needed to gather insights from actual users and different user perspectives about (1) gamification risks and risk factors in gamified agile contexts and (2) risk taxonomy that will inform the risk management process in agile software development.

Table 1. Our study stages.

Study Stage	Data Collection Method	Purpose
Stage 1: Exploration & Investigation [36]	To generate gamified risk scenarios with contextual factors and gamification risk Conducted Semi-Structured Interviews with 15 Participants	To study gamification in a software development context. To study the contextual factors that impact designing tailored gamified systems in software development. To investigate and study the negative impact of gamification in software development. To investigate and study risk management in a gamified software development context. To develop a thematic map for gamification risks and risk factors in gamified software development enterprises (Section 4.1) (Figure A1).
Stage 2: Confirmation & Elaboration [37]	Conducted a virtual focus group with seven experts having 10+ years’ experience in gamified software development enterprises (part one: using scenarios; part 2: using hybrid card sorting)	To confirm and refine the mappings of the gamification risks in software development, particularly agile software development tasks (Section 4.2.1). To provide gamification risk categories using hybrid card sorting (Section 4.2.2) (Table A1). To visualize the impact of gamification risks on agile software development tasks and roles (Section 4.2.3) (Figure A2 and Figure A3).
Stage 3: Evaluation Study	Conducted a two-phase case study with two teams (11 participants) in two software development enterprises	To present the risk reporting form (Figure A4) and the Agile Gamification Risk Management (AGRM) process (Section 5). To evaluate the risk reporting form and the Agile Gamification Risk Management (AGRM) process (Section 6 and Section 7).

summarizes the three-stage study data collection method and purpose.

3.1. Stage 1: Exploration and Investigation

This first stage, Exploration and Investigation, consisted of semi-structured interviews, a commonly used qualitative data collection method [102] in the field of software engineering. This approach facilitates obtaining in-depth insights from participants. Four contextual factors were studied, including game element design, task nature, personality type, and organizational aspects. We strive to address two research questions:

• (RQ1) What are the gamification risk factors that could lead to the emergence of risks in software development organizations?
• (RQ2) What are the associated risks considering various contextual factors, such as tasks, personality type, adopted game element, and organizational cultural aspects?

A total of 15 interviews were conducted, comprising seven males and eight females aged between 25 and 34. With a cumulative duration of 23 h, each session lasted approximately 1.5 h on average. All recordings and transcriptions, with the consent of the participants, are available at https://bit.ly/3BtWiL1 (accessed on 1 February 2025). The recruited participants represent various roles and seniority levels within the software development field, including Product Owner, Scrum Master, and Development Team members (UX/UI Designers, Developers, and Testers). We conducted a thematic analysis of interview transcripts using the six-phase process [103], resulting in the identification of primary and sub-risk factors associated with gamification.

For the self-containment of this paper, in Section 4, we present the thematic map, identifying primary and sub-risk factors associated with gamification risks. The thematic map of the first study and some examples of the gamification risks that emerged are presented. The full details are discussed in [36]

3.2. Stage 2: Confirmation and Elaboration

This stage involved a virtual focus group, a commonly used qualitative data collection method [102]. This study addresses three research questions:

• (RQ1) What is the expert’s prioritization for the contextual factors we considered in our previous study?
• (RQ2) What is the finalized list of risk categories?
• (RQ3) What is the impact of gamification on agile roles and tasks? (Designing of context-inclusive risk profiles)

The focus group was conducted with seven highly experienced software development experts who had successfully gamified Scrum software. These experts, recruited via the researcher’s extensive network connections, brought a wealth of diverse backgrounds and roles, such as Software Engineer Tech Lead, Senior Product Manager, Senior Product Owner, and Senior Data Analyst, with experience ranging from 11 to 16 years. All worked in different companies in Egypt, the USA, and Germany, ensuring a comprehensive and unbiased perspective. The session, lasting 2.5 h, employed scenarios to stimulate group discussion, followed by a hybrid card sorting technique. A Google Drive folder containing a prioritized list of gamification risks and six designed scenarios devised from academic literature [104] as presented to the experts.

The evaluation from multiple scenarios allowed the experts to reveal potential risks in various contextual settings, including game elements, tasks, agile roles, personality kinds, and organizational culture. A list of identified risks was provided to experts in an Excel file. Three risk categories were proposed: well-being, productivity and performance, and ethical risk categories. Other categories were developed based on the contributions of the experts in discussion; this helped to refine and reach a consensus in the classification of gamification risks. Both the session’s recording and transcription via Zoom were saved for future study and reference, available at https://bit.ly/402Mdhg (accessed on 1 February 2025). They have undergone deductive coding so that comprehensive gamification risk profiles may be verified. The thoroughness of the deductive analysis, testing contextual issues like the agile role and personality types of potential players, which the existing literature has already reported as critical factors determining how gamification risk profiles unfold, ensures the rigor of our study [36,37].

3.3. Stage 3: Evaluation Stage

In this stage, an Agile Gamification Risk Management (AGRM) process is presented and evaluated using a case study approach. It is one of the qualitative data collection methods [102]. The study procedure is presented in

Table 2. Evaluation Study Procedure.

Evaluation Study Procedure	Description	Materials Used	Demographics	Duration
Pilot Study	Expert checking for validations and refinement of the process	AGRM proposed process and supporting material	Two experts	1 h 25 min
Induction Session	Familiarizing participants with the topic, introducing the previous results and the study objective	Scenarios, Risk taxonomy, thematic map	11 participants (Two Teams)	40 min
Conduction without our proposed process (Control)	Baseline evaluation without our proposed process	Traditional risk management methods, risk description list	11 participants (Two Teams)	1.5 h
Conduction with our proposed process (AGRM)	Presenting the proposed AGRM in a series of sessions conducted during the sprint events	The AGRM process and its supporting materials	11 participants (Two Teams)	3 h

. Two research questions were addressed:

• (RQ1) How to structure a process to handle gamification risks.
• (RQ2) How to utilize the proposed artifacts in the process.

Based on our research, we selected four essential requirements for the case study to identify the risks of gamification in the agile Scrum: (1) supporting self-reporting techniques [105], as this allowed us to be able to gather subjective insights by individuals into experiences, thoughts, and behavior related to gamification that has been integrated within the Scrum framework; (2) supporting a participatory approach [106] with a focus on empowering, collaborating, and integrating involving Scrum Team members’ identification and assessment of the gamification risks from their perspective to facilitate ownership; (3) supporting a longitudinal approach [107] collecting and identifying gamification risks and regular analysis of gamification risks; repeated analysis process helps with the emerging and iterative nature of both the agile and gamification; (4) supporting detective approaches [108], i.e., risk analysis must be implemented to identify risks and help prevent and avoid the emergence of risks. These imperatives form the basics of the proposed assessment process.

3.3.1. Pilot Study (Expert Checking)

A pilot study was conducted with two experts working in agile software development enterprises, with over 15 years of collective experience at major software organizations in the United States. The female served as Scrum Master and staff engineer, whereas the male became principal software engineering manager. The session lasted 1 h and 24 min and presented the proposed AGRM process, followed by expert revision and discussion around its usability. The experts’ recommendations were to remove the risk validation at sprint retrospection and improve the aspect of risk reporting by giving the information more clearly and pragmatically as a Google Form. This includes risk review and prioritization beforehand by assigning the Scrum Master, which also helps in not overwhelming the development teams during sprint execution.

3.3.2. Recruitment Phase & Organization Information

The recruitment phase was facilitated through the researcher’s network connections with software development companies in Egypt. Two software development teams were selected before the study, and each participant’s personality type was determined through a BFF questionnaire. The selection of these teams and the use of the BFF questionnaire were based on their relevance to the study’s focus on gamification risks in agile software development [75]. Participants were recruited via email; emailed agreement forms were used to collect consent from the participants. The participants as shown in

Table 3. Participant demographics.

Organization	Participant No.	Participant Role	Experience	Gender
Organization 1	Participant 1	Junior Software Developer	2 years	Male
	Participant 2	Junior Software Developer	3 years	Male
	Participant 3	Senior Software Engineer	7 years	Female
	Participant 4	Senior Scrum Owner	16 years	Male
	Participant 5	Junior Software Developer	4.5 years	Female
Organization 2	Participant 6	Senior Product Owner	15 years	Male
	Participant 7	Junior Software Developer	2 years	Male
	Participant 8	Senior QA Engineer/SWE	8 years	Female
	Participant 9	Junior Software Developer	3 years	Male
	Participant 10	Senior Scrum Master	12 years	Female
	Participant 11	Senior Front-End Developer	4 years	Male

were 11 developers (7 males and 4 females aged 21 to 37) whose roles were Product Owner, Scrum Master, and Development Team. Personality types were measured using the 44-item BFF questionnaire. Participants were provided access to a dedicated Google Drive folder containing all the supporting materials and artifacts needed for each phase of the case study, available at https://bit.ly/4iKpnCC (accessed on 1 February 2025).

Organization Information: Both organizations were involved in various engineering, business science, and technology activities, aiming to customize and produce software development products for clients. Employees use their project tracking software, Jira, and Jira gamification plug-ins, Camp Base and Spike. Organization 1 was a service-based organization with 15 years of experience in internet services and cloud computing and had gamified platforms with badges, leaderboards, and rewards within their agile Scrum framework. Organization 2 is 15 years old, specializes in software product customization, and integrates gamification elements such as voting, feedback, and progress bars in their agile Scrum practices.

3.3.3. Induction Session

An induction session was conducted with the two teams; it took about 40 min and was an introduction to gamification risks in agile Scrum. Gamified scenarios were used by participants related to agile roles to get through by gut and experience. The researcher shared a few fundamental concepts, such as possible gamification risk (e.g., technical debt, lack of testing, unethical mindset) and a thematic map, with five main risk factors defined (e.g., organizational, social, task/spirit, performance tracking, game elements, and rewards). The scenario played as immersive material to contextualize how gamification impacted agile events and roles.

3.3.4. Two-Phase Conduction Session

The evaluation consists of a two-phased case study conducted by two teams from different organizations. The assessment method was done through a comparative evaluation (Phase 1 and Phase 2) conducted with two teams from two large software development companies based in Egypt to gather diverse opinions and ensure our proposed risk assessment process is suitable for a real work environment. The two-phased sessions were designed to contrast the efficacy of the (Phase 2) AGRM process in identifying and assessing gamification risks. In the first session, not having AGRM, a baseline was experienced to witness obstacles in identifying risks, and in the second session it showed how AGRM facilitated a systemic approach in evaluating and countering such gamification risks within sprints.

Phase 1: Conduction Session Without AGRM Process: This phase focused on how participants independently identified and managed gamification risks without the proposed model; a baseline (control) assessment without the proposed method. Participants were asked to identify and assess gamification risks using their traditional risk acquisition methods without the aid of our proposed assessment method. This phase lasted about two hours. The objective was to establish a baseline for comparison with the results obtained using the proposed method. This phase lasted 1.5 h. Phase 2: Conduction with AGRM process with two teams: This case study explores how well the proposed AGRM process and artifacts support identifying, assessing, and mitigating the gamification risks in the real agile software development environment. Within this study, the proposed risk management process was tested in practice for its applicability and effectiveness within agile environments. The second phase involved using the proposed risk management method. This phase included four key sessions that lasted for almost 3 h:

Introduction and Training Session: The researcher introduced the agile risk management process, explaining activities and new artifacts such as a risk reporting form, mitigation repository, and personalized risk profiles, fitted to the Scrum roles and personality types. Participants were trained using the process for 35 min; masters needed different kinds of tools, such as gamification risk registers, and the Risk Exposure metric is used to prioritize the items. In the 2-week sprint execution, the participants self-reported the risks of gamification using a Google Form; notifications were sent to the researcher for analysis.

A Session with Scrum Master (prior Sprint Retrospective): We conducted a 40-minute session with the Scrum Master of Teams 1 and 2 after 13 days of their sprints. In this session, the Scrum Master completed the tasks and subtasks related to risk reviewing and prioritization activity. As mentioned above, this study supported the longitudinal approach of repeated risk analysis.

A session with the Scrum Team (simulating the Sprint Retrospective): After 14 days of sprints, we conducted a session with Teams 1 and 2, simulating the sprint retrospective, using a prioritized list of risks based on Risk Exposure and impact on tasks. The team collectively addressed how the identified risks would be mitigated regarding the risk mitigation repository. This session lasted approximately 1.5 h.

A Session with the Scrum Team (simulating Sprint Planning): After 15 days of the Scrum Team’s sprints, a session was held during sprint planning. The Scrum Master used the Personality vs. risk histogram, personalized risk profiles, team members’ information, and sprint backlog to better assign team member tasks concerning the enabled game elements. This session lasted for approximately 35 min. As mentioned above, this study supported the longitudinal approach of data collection, which was done over several intervals of time, for example on day 13 and day 15. Participants were then asked to evaluate the AGRM process and were given these links: https://forms.gle/wJ2pimDrzGKNN81k6 (accessed on 1 February 2025) and https://shorturl.at/8BaS7 (accessed on 1 February 2025). Findings will be discussed in Section 8.

4. Result of the First Stage (Interviews) and the Second Stage (Focus Group)

4.1. Stage One: Exploration and Investigation Results (Interviews): Gamification Risks and Risk Factors

This section aims to conceptualize the gamification risks and risk factors in agile software development [36]. The analysis of contextual elements that influence risk emergence allows us to determine the overall impacts of gamification on software development roles and activities. A list of 73 risks associated with gamification in agile environments was identified [37], such as decreased motivation, increased stress and anxiety, and peer conflict. These risks have emerged as a result of five primary risk factors, which are the rewarding system, monitoring and performance feedback, social aspects, organizational, and task/goal-related risk factors (Figure A1).

Within this section, quotes from the interview study are presented to identify the risks that emerged and their contextual risk factors. Quotes are highlighted with corresponding tags indicating the main risk factors and other contributing sub-contextual risk factors. Additionally, the dominant personality type number and participant number are provided alongside the quotes. Risks are presented in italics and underlined. Some of the identified risks had been previously discussed in the literature, but not within our contextual setting. This underlines the broader relevance of these risks, while at the same time highlighting the need to analyze them within the gamification contextual risk factors. Some examples of the gamification risks are presented in this section as a result of incorporating gamification into agile tasks neglecting task/goal sub-related factors such as task completeness, task complexity, and task type.

• Task Complexity: This reflects the level of difficulty or specialized knowledge required to perform a task. It acknowledges that tasks can vary in complexity, from routine and straightforward tasks to more challenging ones. Instead of solely relying on developers’ commit counts, this approach incorporates the lines of source code, taking into consideration the complexity of the code [11,12,13,14,74]. “I can sometimes do 1000 commits with 1000 points [Game elements: Points] and other times do 500 commits, but the 500 fixed more critical bugs. Fixing a complex task [Task Complexity high] requires other metrics than just counting the number of commits [Metric: accumulation of number of commits only]”. [Personality type: Openness] (Participant 14, Senior Development Team) leading to unappreciation and effort Misinterpretation, previously identified by [34,109].
• Task Type: Tasks are either core or non-core. Core tasks are those high-priority ones that are direct contributors to the key objectives of, among others, the following: Development: Implementing new features, refactoring code, and resolving bugs; Design: data modeling, wireframing; Testing: writing unit and integration tests; Innovation: study and development, improvement regarding software features. Non-core tasks enable the process but do not contribute to core value, such as fixing low-priority bugs or attending optional meetings. “Time Pressure and Competitions [Game element: Time Pressure, Competition] would limit my creative thinking [Task type: qualitative, innovative], I need to produce a good wireframe [Task type: Core] suggestion and not be concerned by the competition itself” [Personality type: Openness] [Participant 11, Junior Development Team]. Leading to limited creativity, previously identified by [91].

4.2. Stage Two: Confirmation and Elaboration (Focus Group with Experts)

This section presents the aim and results of stage two of our study [37]. The focus group study has three aims: (1) refine and confirm the results of the first study from experts using immersion scenarios; (2) provide gamification risk taxonomy with the use of a hybrid card sorting technique; (3) design inclusive risk profiles and present the impact of gamification on agile roles and tasks.

4.2.1. Confirmation and Refinement (Using Scenarios)

The focus group’s first aim was to confirm and refine the first study results. The experts were given gamified agile scenarios, which helped them to refine and prioritize the contextual factors for the emergence of gamification risks. The contextual themes need to be evaluated by the experts, confirmed, and then refined with their mapping into the emerging gamification risks. Scenarios were used for that purpose. The experts received six scenarios, available at https://bit.ly/3BCUj78 (accessed on 1 February 2025). Each scenario showed agile tasks and activities performed by different agile roles within different gamification contextual situations. For example, scenario two described the functions of the development team during sprint execution bug fixing, test case writing, code restructuring, and peer rating. They were then asked a series of questions collectively to attain a consensus concerning any missing contextual factors. They all agreed about the contextual factors mentioned above. However, they pointed out that sprint and task goal achievement are candidate risk factors that may contribute to emerging gamification risks; hence, goal achievement was added to our thematic map.

4.2.2. Gamification Risk Taxonomy

This section presents the second aim of the focus group, which is to provide a gamification risk taxonomy through a hybrid card-sorting technique. Initial broad categories of risks included “Well-being, Productivity and Performance, and Ethical”. In developing this process, however, it became clear that other categories were necessary beyond what this initial set provided. It was pointed out that some emergent risks should be directly classified as affecting software development tasks and activities due to gamification. In contrast, other well-being-related risks need further categorization according to whether they affect the individuals or relationships among the teams. After the discussion, experts reached a consensus on mapping risks into six risk categories, named psychological, operational, ethical, socio-dynamic, task, strategic, and organizational-related risk categories [37] (

Table A1. Table of Gamification Risk Taxonomy.

Risk Category	Risk Category Definition	Risks
Psychological Risks	Refer to negative impacts on individuals’ well being	Fear of Incompetence (Self-Criticism), Fear of prejudgment & triviality, Stalling & disengagement, Anxiety, Unconfident, Increased stress, Effort misinterpretation, Irrelevant reward (mismatched expectations) (confusion feedback), Feeling stagnant, Novelty-seeking & quick boredom, Embarrassment, Left out.
Operational and practical Risks	Refer to the potential negative impact on individuals’ ability to effectively and efficiently perform tasks or achieve goals due to the implementation or design of game elements	Skill and knowledge gap, Lower performance & Productivity, Diminished skills ineffective learning & skill development, Lack of skill alignment, Inequitable workload distribution, Limited experimentation, Distraction shift of focus, Novelty effect, increase in the number of unassigned tasks affecting sprint velocity,
Ethical Risks	In gamification, refer to infringement of employees’ ethical mentality and responsibility towards their workplaces and task achievements.	Infringe ethical mentality and responsibility, being dishonest, Bias and fairness concerns, Exploitation, Persuaded voting, Ego-centric, Implied toxicity, Procrastination, Rabbit hole (Gaming addiction), Meeting minimum requirements.
Socio-dynamics related Risks	Refer to risks influencing team dynamics, relationships, and behaviors.	Social comparison & competitive pressure, Anchoring bias, Unneeded competition, Peer conflict & inaccurate achievement, Lack of peer feedback, Peer pressure & fear of letting down teammates, Unfair comparisons, Clustering group & intimidation, Peer rejection & negative employee morale, Employee inequality, social overload, Increased jealousy & competition
Strategic & Organizational Risks	Refer to risks of the impact of gamification on achieving organizational strategies, business goals, and misalignment of users’ needs.	Misalignment with client needs, Poor user satisfaction, Resistance & lack of senior management participation
Task-related Risks	Refer to the potential risks that can affect the successful completion of specific tasks or activities within a project or workflow. Quality-related risks refer to potential issues that can affect the output or deliverability of a task. These can include inadequate requirements gathering, reoccurrence of issues, inadequate product documentation, and insufficient testing. Schedule-related risks pertain to risks related to task timelines and dependencies. Factors such as time-consuming and high overhead, underestimated task durations, and unexpected schedule delays that cause disruptions in the planned sequence of activities can impact the overall project schedule	Quality risks: Low-quality user stories & impractical user stories, Incomplete backlog prioritization & Refinement, Rushed or superficial requirement scoring, Less robust or inefficient requirement solutions, Technical debt accumulation & reoccurrence of issues, Disruption of workflow and affecting number of completed sprints, Poor quality deliverables & test coverage, Delays of the lead time of log items, Decrease in sprint velocity and affected burn-down charts, Complex functionality & not user-friendly user interface, Missed opportunities & overlooking anomalies, Inadequate testing & quality assurance, Functionality issues & high defect density, Increased number of reopened & persistent bugs, Premature closure of bugs & unsolved and incomplete bugs affecting the software development, Lack of innovation & creativity, Incomplete product documentation, Rushed sprint backlog prioritization & user story selection decisions, Poor user story selection. Schedule risks: Delays and inefficiencies for lead time of log items decrease in sprint velocity and affected burn-down charts

).

4.2.3. Impact of Gamification on Agile Roles and Tasks (Personalized Risk Profiles (PRP) and Gamified Scrum Software Process Model)

This section presents the third aim of the focus group, which is to introduce context-inclusive risk profiles to present the impact of gamification on agile roles and tasks. In this regard, the experts were asked about designing inclusive risk profiles to present personalized risks of gamification. Experts have emphasized how important and helpful it would be for software development companies to develop inclusive risk profiles that introduce gamification risks to integrate a risk management approach into the gamified agile tasks to handle gamification risks. Also, these risk profiles will help project managers perform better employee assignments based on their respective gamified tasks in sprint planning. Expert 1 mentioned that “the risks identified were pertinent to the associated personalities, particularly in the context of well-being risks; however, they can emerge for other personalities as well”. Expert 2 stated that “some risks were identified regarding the impact of gamification on agile tasks, irrespective of individual personalities. Therefore, it’s essential to design inclusive risk profiles considering a broader range of factors beyond personality types”. They also showed that knowing the agile role is essential in using the Scrum methodology. Therefore, they concluded that the inclusive gamification risk profile should be based on agile roles and personality type accompanied by other contextual factors, such as a task being executed and a game element integrated within the functions.

To present the findings from this study, as shown in (Figure A2), Personalized Risk Profiles were used to present context-inclusive risk profiles by showing the gamification risks encountered by different agile roles. Fishbone diagrams [110] are used to show the cause and effect of the potential gamification risks related to each agile role (Product owner, Scrum Master, and development team). The rest of the fishbone diagrams are available at https://shorturl.at/yeooP (accessed on 1 February 2025). Also, a gamified process model for the Scrum framework is presented in (Figure A3). The process model illustrates those personality types that were most susceptible to encountering gamification within gamified Scrum. We have used colors to signify the different personality types presented in this study. Red is for extraversion, green is for conscientiousness, purple signifies openness, yellow for agreeableness, and blue for neuroticism.

5. Agile Gamification Risk Management Process: Our Proposed Process

This section presents the Agile Gamification Risk Management Process (AGRM), a structured approach that manages the emergence of gamification risks within agile Scrum projects. The AGRM is an ongoing process that contributes to improving project effectiveness and well-being for the team to maintain a balance throughout the project’s life cycle between motivation and productivity, on the one hand, and mitigation and avoidance of risk on the other hand. To do this effectively, the AGRM process and its artifacts are presented in this section.

Table 4. AGRM process.

Risk Management Activity	Role	Scrum Event	Activities	Tasks	Artifacts
Risk Identification	Scrum Team Member (Affected team member)	All/Any Scrum events	Risk Identification	Complete Gamification risk reporting form Scrum team members fill out the Gamification Risk Reporting & Assessment form with the risks that emerged and assess the risk likelihood and severity.	Gamification risk reporting & assessment form Sections A–E (Figure A4) Personalized Risk Profile
Risk Assessment	Scrum Team Member (Affected team member)		Risk Assessment	Assess Risk Likelihood and Severity within the risk reporting form “Evaluate the likelihood and severity/impact of each identified gamification risk”. A new risk-identified label will be tagged as “new” until reviewed by the Scrum Master	Gamification risk reporting & assessment form Section G (Figure A4)
Risk Review & Prioritization	Scrum Master	During Scrum execution and before the sprint retrospective meeting Post Sprint	Risk Review & Prioritization	A. Check and refine the gamification risk titles B. Update Personalized risk profiles with new or identified risks and their contextual factors, which will be used later during sprint planning. C. Calculate Risk Exposure depending on risk likelihood and risk severity from a Scrum Team member’s point of view	Gamification Risk Register Risk exposure measure Task impact matrix Prioritized list of risks
				D. Inspect risks with high RE against the Task impact Factor using the Task impact table Check risks with no task or sprint to be labeled with risk status “escalated”. E. Prioritize risks based on two assessment factors (Risk Exposure and Task impact factor) using Personal vs. Task Impact Matrix Highlight the risk with RE = 9 and task impact equals high labeled red. Tag risk status as “reviewed”.
Risk Mitigation	Scrum Master and development team	Sprint Retrospective	Validate & Mitigate Risks	Verify and validate the identified risks Group Discussion for Mitigating Highly Prioritized Ranked Risks Document mitigation and update risk status as “mitigated”	Gamification Risk Register Resolved risks and risk factors table Risk Mitigation Repository
	Project manager and IT Operations manager	Post Sprint
Risk Avoidance	Scrum Master	Scrum Planning	Analyze gamification risks against personality types and avoid high-risk allocations.	Analyze gamification risks against personality types Use the Personality vs. risk histogram to analyze the frequency of risk occurrence of different personality types. Avoid high-risk allocation of tasks Cross-check personality types with the highest frequency of risk occurrence from the previous step. Use personality Risk Profiles to cross-check the risks with their contextual factors and game elements Use a Task allocation matrix to ensure that personality types with higher frequencies of risk emergence are vulnerable to experiencing such risks into specific tasks are avoided.	Personality vs. risk histogram Personalized Risk Profiles
					Task Allocation Matrix Gamification Risk Register Sprint Backlog Sprint Team member

shows the Agile Gamification Risk Management (AGRM) process, which presents the proposed process with its tasks, subtasks, and artifacts needed. The gamification risks that were identified within the sprint and were not mitigated during the sprint are escalated or deferred to the subsequent sprint planning meeting for reassessment and action.

5.1. AGRM: Risk Identification

This AGRM activity, Risk Identification, can be performed by any Scrum Team member who encounters gamification risks at any stage, whether initiation, execution, closing, or even outside of active sprints.

(1)

Gamification Reporting Assessment and Prioritization Form

This form helps team members report observed risks related to gamification during their sprint activities, tasks, events, or even off the sprint. It is an initial step to document specific risks encountered due to gamified elements in their tasks. Scrum Team members would need to fill out the risk reporting and assessment form available at https://forms.gle/wJ2pimDrzGKNN81k6 (accessed on 1 February 2025), which enables the Scrum Master to contact the relevant person for updates.

The risk reporting form is divided into several sections (Figure A4). Sections A–G: Team members fill out one form for each emerging risk and fill in contextual factors such as team member ID (risk owner), role, personality type, seniority, project name, sprint number, agile task, game element, and assignment level and visibility, as depicted in Section E. Team members fill in the risks of the narrowed-down list marked in Section D according to the identified impact category of risk or describe a new risk. The PRP concerns similar situations and contextual factors when setting the reference. Otherwise, Section F describes new gamification risks and the impact category. Section G asks team members to identify the likelihood and severity of each identified risk: low, medium, or high.

This would allow Scrum Team members to report and assess risks in real-time, either during or off-sprint, ensuring risks are captured within their actual context. This is dynamic, iterative, and hence agile, which can allow one to act responsively to risks as they emerge.

(2)

Personalized Risk Profiles (PRP) and Risk Descriptions

Personalized Risk Profiles (PRP): These profiles were developed as a key outcome from the findings presented in Section 4.2 above. The PRPs have been a helpful input to the risk identification activity, helping team members identify the contextual factors giving rise to emerging risks. PRPs summarize the distinctive risk susceptibilities for each personality type, the Scrum roles in which they are most likely to occur, and the contexts in which such risks arise. Available at https://shorturl.at/yeooP (accessed on 1 February 2025) (Figure A2).

Risk Description: This document provides detailed definitions and categorizations of identified risks. Scrum Team members may use this document to further understand and categorize their identified emerging risks. Using structured profiles, team members are empowered to identify and manage risks so that no gamification aspect compromises the integrity or objectives of tasks and sprints.

5.2. AGRM: Risk Assessment

This AGRM activity, Risk Assessment, is performed by the affected Scrum Team members through the risk reporting form (Section G). This would allow the team member to assess the identified risk from their perspective by categorizing it as either low, medium, or high in terms of likelihood and severity. Completing the risk reporting form would allow the affected Scrum Team member to report and assess gamification risks in real-time, either during or off-sprint, ensuring risks are captured within their actual context.

5.3. AGRM: Risk Review and Prioritization

This AGRM activity involves risk review and prioritization. Before the Sprint Retrospective, the Scrum Master reviews and prioritizes the identified risks from the Gamification Risk Register. The aim is to prioritize the risks based on their potential impact and the urgency of addressing them so they can be mitigated within the sprint.

(1)

Gamification Risk Register (GRR)

The identified risks of the affected Scrum Team members’ reports are documented and entered into the Gamification Risk Register. This repository keeps track of all identified risks within the project. This register can be used as a resource for managing and monitoring risks, whereby the Scrum Master can access, evaluate, and prioritize them. This Gamification Risk Register will give the Scrum Master a consolidated view of all the project risks and enable systematic addressing of risks and prioritizing them for mitigation.

(2)

Risk Exposure Measure

The Scrum Master calculates Risk Exposure (RE). The RE is calculated by multiplying the probability of the risk’s occurrence by its potential damage. These measures are to be identified in Section G during risk reporting and assessment.

RE = Risk Likelihood × Risk Impact

This calculation helps to prioritize the risks quantitively, focusing on the ones that could significantly affect the Scrum Team member from their perspective. For instance, risk likelihood/risk impact is high, equal to 3; medium, equal to 2; and low, equal to 1. As a result, risks could be labeled with an RE of 2, 3, 4, 6, or 9.

(3)

Task Impact Matrix

The Scrum Master inspects the highly rated risks in the GRR of an RE score of either 6 or 9 and categorizes them under task impact factors, on the completeness and complexity of tasks, as “high impact” or “no impact”. Having only two choices can help the Scrum Master determine the impact; either a risk has prevented a task from completion or had no or minimal effect. It is evaluated by checking for a task’s completion and comparing values for code complexity at developer edits, both initially and subsequently, to measure productivity impact.

Some risks will be tagged as “escalated risk” for the risks that emerged not in a specific sprint task but in general and have no impact on sprint tasks. These are the ones that cannot be resolved at the current level of the team, or even within an upcoming sprint retrospective, and hence require the intervention of higher management.

(4)

Two Assessment Factors

Use two assessment factors, exposure and task factors, to prioritize risks. Ignore risks with an RE score of less than 6. Label risks with color codes according to the RE and the impact on the task, as described in

Table 5. Assessment factor impact and RE categories.

Risk Impact	Description Level
Low Risk	Green (Medium Risk Exposure = 6, No Impact on Tasks): Accepted risk
Medium Risk	Yellow (High-Risk Exposure = 9, No Impact on Tasks): These risks should be mitigated
High Risk	Orange (Medium Risk Exposure = 6, High Impact on Tasks): These risks should be mitigated soon.
Highest Level Risk	Red (High-Risk Exposure = 9, High Impact on Tasks): These risks need immediate mitigation.

. Indicate risks that should be mitigated urgently. Identify risks to be acted on later. Update Risk Status: update the status of reviewed risks in the GRR to “reviewed”.

Based on this review, the Scrum Master creates a prioritized list of risks that will be utilized as input into the upcoming SGRM activity. The prioritized risks are those with the highest exposure and task impact, ensuring that the most critical issues are addressed promptly.

5.4. AGRM: Risk Mitigation (During Sprint Retrospective)

This AGRM activity, risk mitigation, is a group activity between the Scrum Master and Scrum Team. During this activity, the Scrum Team members who identified risks in the GRR are asked to validate those risks. In this regard, the members had to confirm the context of the risks, the severity, and the possible impacts so that they were correctly captured for further analysis or mitigation. Afterward, the Scrum Master suggests the list of risks to come to a common team agreement on how to mitigate those high-exposure risks, especially those affecting the different personality types in the team.

By encouraging open discussion of those risks, the team will work toward practical and effective strategies agreed upon and supported by all. This reinforces the development of the team’s practices to ensure alignment and shared accountability for addressing potential challenges and strengthens risk management.

(1)

Resolve (Understand) Risks and Risk Factors

This task requires the risks to be mitigated based on their resolved risk factors and risk impact category. Identifying and categorizing risks and their contributing factors had to be explicitly resolved to effectively guide the risk mitigation phase through actionable solutions. This step thus ensured a focused and productive discussion, which ended with creating the Risk Mitigation Repository, listing the mitigation strategies from the existing gamification risk literature [34]. The factors that make these risks likely to occur include task complexity, transparency, seniority, and personality type, which are external elements called risk factors. Such risks are summarized in categories of gamification risks [37], like social and team dynamics, practical, ethical, psychological, strategic, and task-related, which will allow the team to identify which risks to focus on.

(2)

Risk Mitigation Repository

This repository is a documented collection of risk mitigation gathered from the literature, along with the strategies employed to address them. It is a reference for future sprints, helping the team learn from past experiences and continuously improve their risk management practices.

5.5. AGRM Activity: Risk Avoidance (During Sprint Planning)

This AGRM activity includes risk avoidance, which involves the Scrum Master and Product Owner collaborating during Sprint Planning; this activity aims to proactively manage risks so that the sprint execution will be much easier. Gamification risks can be reduced by not assigning tasks with well-known game elements to such personality types that would cause risk emergence.

This approach elicits possible tasks and risk overlaps; in this way, it minimizes conflict by carefully allocating sprint backlog tasks to sprint team members considering the gamification risks and avoiding their occurrence.

(1)

Personality-Risk Matrix and Histogram

This histogram is a diagrammatic representation of the team members’ personalities and their relation to the risks they could face. It maps the relationship between personality types, risks that have occurred, and the overall count of occurrences. A Personality vs. Risk histogram is generated from the personality vs. risk matrix generated from the GRR of the identified risks. This information aids in establishing the pattern of their susceptibility, which would thereby help pinpoint personality types more susceptible to the risks involved in gamification. By doing so, avoidance could be addressed appropriately and efficiently.

After knowing the Scrum Team members involved in the upcoming sprint and which risks they are vulnerable to, the Scrum Master checks the personalized risk profiles to consider the contextual factors in which these risks emerge. If they could assign team members of a specific personality type to other tasks, that would not make them subject to such risk, or if they turn on/off the game elements based on their preferences in order not to experience the emergence of risk. This would allow for better and more specific task assignments that may solve any foreseen problems and improve overall performance.

(2)

Task Allocation Matrix

A task allocation matrix is used to proactively assign the tasks of the sprint backlog with the consideration of the gamification risks. This matrix will take predefined gamification elements and sprint backlog tasks, and personality types within the given team, performing task allocations in an efficient manner that is able to avoid the emergence of the gamification risks to vulnerable personality types. This makes provision to use the Personality vs. Risk Histogram displaying susceptibility patterns; thus, the highest frequencies of susceptible Personality types are prevented from being assigned to these tasks, and they are assigned to other Scrum Team members instead. Personalized Risk Profiles (PRP) map the risks emerging with their contextual factors.

6. Study 3: Results of the Case Studies

This section outlines the control results and the proposed risk management AGRM process, focusing on its application within real-world settings to identify, assess, and mitigate gamification risks in agile Scrum environments.

6.1. Results of Phase 1 Case Study (Without AGRM)

After introducing the concepts, the researcher gave participants scenarios for immersion and questions to guide them in identifying and analyzing the risks and risk factors. The discussion covered how participants would handle the gamification risks. It elaborated on participants’ processes for monitoring and reviewing risks throughout the Scrum framework to ensure an in-depth understanding of risk management practices within a gamified agile context. The identified risks are presented in

Table 6. Risk identification without AGRM using Risk Description List.

Risk Number	Risk Emerged
R1	Effort Misinterpretation (R1)
R2	Fear of Incompetence (R3)
R3	Unwanted Competition (R4)

.

• Activity 1: Identify Risks

This exercise aimed to gather insights on how participants would identify and assess the risks of gamification in an agile environment without any suggestions from the proposed AGRM process. The researcher requested participants’ experiences to identify gamification risks using traditional risk identification methods.

The participants were asked, “How would you identify and assess gamification risks in your agile work environment?” The response should have been highly variable, and the respondents proposed some very traditional ways of identifying risks, like brainstorming, interviewing employees, and drawing on past experiences. For example, E10 mentioned, “We can brainstorm: what are you annoyed by or which game elements annoy you the most?” Another participant, E7, replied, “Why not mention explicitly the game elements we do not like? We need to map risks for each user since someone may dislike a game element that another person likes”.

These discussions demonstrated various methods and some of the challenges experienced by teams in the identification and classification of risks without formal structuring. These include the following: (1) Brainstorming: All participants perceived it necessary to gather the whole team to brainstorm possible risks, which could help outline some identified game elements that highlighted the missed-out problems. (2) Employee Interviews: Some recommended interviewing the team members to gain insight into the possible identified risks, as individual experience and perspectives could make some risks more prominent and not easily findable to the group. The Scrum Team identified some of the risks that affected their well-being. The identified risks were associated with game elements and factors, such as team dynamics, task complexity, and time–pressure factors.

• Activity 2: Analysis and Prioritization of Risks

Participants were to focus on the identified risks and analyze them based on the technique that they are currently practicing. They are provided with the essence of the discussion through the focus question: “How will you assess/evaluate the effect of these risks on the work environment/stakeholders?” It was analyzed how the assessed risks may have the potential to affect their agile processes, goals/project goals, tasks, and relationship with the team. E5: “We can have the usual matrix with likelihood and severity, like a 5 × 5 or 4 × 4 grid, whereby to assess the risks on both qualitative and quantitative”.

During this step, they started discussing risk assessment and priority until they reached a group consensus regarding the identified risk, which was in opposition to our aim of being inclusive. Reaching a group consensus would ignore how severe these risks emerged could be for a specific or even a group of Scrum Team members, hindering their productivity and performance.

In terms of mitigation, the control group presented mitigations to prevent and avoid emerging risks from their point of view. For example, they could limit public leaderboards to mitigate unwanted competition. If public leaderboards are causing competitive stress, consider removing or limiting their visibility. Instead, they could focus on more private and individualized feedback methods. However, the absence of a structured framework made the process hard to handle, and no system was in place for the timely/routinized risk processing.

Barriers and Challenges Identified by Participants:

• Unstructured Approach to Risk Management: Participants felt that, without a structure, the risk identification and mitigation process appeared incoherent and inconsistent.
• Need for a Structured Process: These discussions highlighted the need for a structured approach to making the risk management process in agile environments more coherent and effective.
• Difficulty in Prioritizing Risks: Most participants recommended using traditional matrices, but they indicated that prioritization was not possible with these tools alone as they lacked a comprehensive “big picture”. A comprehensive framework would have provided the necessary overview for effective prioritization.
• Subjective Mitigation Discussions: Without a defined process, participants discussed mitigations subjectively, with no clear guidelines to follow.

6.2. Results of Phase 2 Case Study (with AGRM)

This section presents the results of the proposed risk management method for the two teams, focusing on its application in real-world settings to identify, assess, and mitigate gamification risks in agile Scrum environments. The results from the case study confirmed that the proposed risk management process effectively identified, assessed, and mitigated gamification risks within agile Scrum environments.

6.2.1. AGRM: Risk Identification and Assessment

Scrum Teams could use the risk reporting form to report gamification risks within and outside sprints. The risk reporting description sheet helped them accurately complete the form during their sprints.

Table 7. Sample of Gamification Risk Register for Team 1.

Time Stamp	Emp ID	Personality Type	Risk Title	Risk Likelihood	Risk Impact	Task	Game Elements
08/08/2024 14:56:12	E4	Extraversion	R28—anxiety & unconfident	High	High	No task	Competition
08/08/2024 14:56:12	E4	Extraversion	R18—Anchoring Bias	Medium	High	Testing & Quality Assurance	Leaderboard, Points, Badges
13/08/2024 20:32:03	E3	Agreeableness	R67—Lower task quality & efficiency	High	High	Code Reviews	Other
14/08/2024 20:32:03	E5	Agreeableness	R43—Increased Stress, Anxiety	Medium	High	Sprint Retrospective	Progress Bar
16/08/2024 14:56:12	E1	Openness	R3—Fear of Incompetence	High	High	No task	Avatar

and

Table 8. Sample of Gamification Risk Register for Team 2.

Time Stamp	Emp ID	Personality Type	Risk Title	Risk Likelihood	Risk Impact	Task	Game Elements
09/08/2024 20:29:26	E9	Extraversion	R43—Increased Stress, Anxiety	High	High	Testing & Quality Assurance	Competition, Progress Bar, Time Pressure
10/08/2024 20:32:03	E9	Extraversion	R57—Technical debt	Medium	Medium	Testing & Quality Assurance	Points, Challenges, Competition
12/08/2024 18:56:12	E6	Agreeableness	R13—Distraction & Shift of Focus	High	High	User Story Creation	Leaderboard, Points, Competition, Time Pressure
13/08/2024 16:56:12	E10	Agreeableness	R43—Increased Stress, Anxiety	High	High	Sprint Planning Meeting	Points, Challenges, Competition, Time Pressure, Communication Channel

show a sample of the risk register GRR with the two teams’ identified risks. All identified risks were tagged as “new” until the Scrum Master reviewed them in the next step. Here is a link to the GRR available at https://shorturl.at/E4te3 (accessed on 1 February 2025).

6.2.2. AGRM: Risk Review and Prioritization Before the Sprint Retrospective

a.

Check and Refine Gamification Risk Titles

The Scrum Masters for both teams reviewed the gamification risk register during the sprint execution and before the sprint retrospective to ensure the title was clear and represented the identified risk adequately. The total number of risks identified for Team 1 was 12, and for Team 2 it was 8. For Team 1, a new risk was identified, described by an employee labeled E1 as “Fear of Failure”, as shown in the above

Table 9. Sample of Gamification Risk Register after Scrum Master reviewing and prioritization.

Risk	Risk Likelihood	Risk Impact	Risk Exposure	Task Impact	Task	Risk Status
R28—Anxiety & unconfident	High	High	9	no impact	No task	Escalated
R43—Increased Stress, Anxiety	High	High	9	high	Testing & Quality Assurance	Reviewed
R59—Meet minimum requirements	High	Medium	6	high	Testing & Quality Assurance	Reviewed
R1—Effort misinterpretation	High	Medium	6	no impact	No task	Escalated

, which the Scrum Master mapped into “R3—Fear of Incompetence” previously identified risks in the PRP depending on his description and the identified contextual factors; this would allow them to maintain consistency and prevent duplication.

b.

Update Personalized Risk Profiles

The Scrum Master updates the PRPs with new contextual factors for previously identified and newly identified risks to keep the profiles valid and current.

In Team 2, the Scrum Master followed up with the Risk Register GRR in

Table 10. Sample of Gamification Risk Register (GRR) “Escalated Risk”.

Risk Emerged	Game Elements	Personality Type	Risk Status
R28—Anxiety & unconfident	Competition	Extraversion	Escalated
R1—Effort misinterpretation (Performance Misjudgment)	Competition, Time Pressure	Agreeableness	Escalated
R3—Fear of Incompetence	Avatar	Openness	Escalated

. He noted that “R43—Increased Stress and Anxiety”, initially associated with employees with an Extraversion personality type, was also reported by Employee 10, who was classified as having an Agreeable personality type.

Hence, the Scrum Master updated the development team’s PRP for risk labeled R43—“Increased Stress and Anxiety” to reflect that this risk is associated with two personality types: Extraversion and Agreeableness. This update ensures that PRPs correctly reflect the risks for different personality profiles.

c.

Calculate Risk Exposure

The Scrum Masters of the teams calculate the Risk Exposure (RE) of every risk listed in the Risk Register by multiplying its likelihood and the severity of its impact, reflected in the column of Risk Exposure in Table 9. The calculation gives a quantitative measure of the potential impact of each risk for prioritizing the high-risk items from the affected Scrum team member’s perspectives.

d.

Inspect Risks Against the Task Impact Matrix

This step requires the Scrum Master to review the identified risks against the impact of risks on the sprint tasks in terms of completeness and complexity. Table 10 shows three identified risks without tasks. These risks are tagged as “escalated” and will be deferred in further mitigation steps. All the other risks were tagged from “new” to “reviewed”.

e.

Prioritize Risks using Two Assessment Factors

Based on this, the Scrum Master builds a GRR priority list of risks based on two factors for assessments: Risk Exposure scores of 6 or 9 and the Task Impact Factor labeled high. As defined in Section 6.2.3, color labels visually indicate the risks based on RE and Task Impact; they are 16 highly ranked risks. In

Table 11. Sample high-priority risks with high task impact and RE = 6 or 9.

Personality Type	Risk Title	Risk Exposure	Task Impact	Task
Extraversion	R18—Anchoring Bias	6	High	Testing & Quality Assurance
Openness	R26—Peer conflict and inaccurate achievement	6	High	Development Task
Extraversion	R43—Increased Stress, Anxiety	9	High	Testing & Quality Assurance
Agreeableness	R43—Increased Stress, Anxiety	6	High	Sprint Retrospective
Agreeableness	R13—Distraction & Shift of Focus	9	High	Sprint Planning Meeting
Agreeableness	R42—Task quitting	9	High	Development Task
Agreeableness	R23—Disengagement & Anxiety	9	High	Code Reviews

, a sample of them focusing on risks is labeled as red or orange. This prioritization guarantees that the Scrum Master has focused on identifying and mitigating the most critical risks during the upcoming sprint retrospective, thus optimizing the team’s ability to address any potential challenge effectively.

6.2.3. AGRM: Risk Mitigation During Sprint Retrospective

During the Sprint Retrospective, Scrum Masters and development teams revisited the prioritized risks, their factors, and categories (impact areas) indicated in

Table 12. Understanding risks and risk factors of the risks labeled red.

Risk Emerged	Risk Impact on	Primary Risk Factor
R43—Increased Stress, Anxiety	Psychological Risk	Organizational culture or transparency
R66—Exploited by others)	Ethical Risk	Monitoring & Feedback
R13—Distraction & Shift of Focus	Operational & practical	Monitoring & Feedback
R43—Increased Stress, Anxiety	Psychological and social well-being	Monitoring & Feedback
R67—Lower task quality & efficiency	Task and Sprint Performance	Goal/Task achievement
R65—Increased number of reopened & persistent tasks	Task and Sprint Performance	Goal/Task achievement
R13—Distraction & Shift of Focus	Operational & practical	Goal/Task achievement
R42—Task quitting	Task and Sprint Performance	Game element Setting
R23—Disengagement & Anxiety	Psychological Risk	Goal/Task achievement

by using the Risk Mitigation Repository to identify solutions. The categorization of the risks presented in Section 4.2.2 above allowed for easier matching to effective mitigation strategies.

The Scrum Master with the Scrum Team validated the list risks.

The team members brainstormed strategies and updated the Gamification Risk Register (GRR), and the agreed solutions are documented in

Table 13. Sample of risks against mitigations.

Risk Impact on	Risk Emerged	Mitigation Strategies	References
Psychological Risk	R13—Distraction & Shift of Focus R43—Increased Stress, Anxiety R23—Disengagement & Anxiety	Hold regular meetings to keep members’ concentration on the main tasks and objectives at hand. It is not about gamification rewards; it is about the efficient accomplishment of sprint tasks. Provide rewards for helping others to encourage collaboration and engagement and enable team members to gauge their performance through self-assessment tools that reduce anxiety	[34]
Ethical Risk	R66—Exploited by Others	Auditing: Careful auditing of tasks and responsibilities to prevent exploitation.	[34,111]
Task and Sprint Performance	R67—Lower Task Quality & Efficiency	Put in place peer-rating and self-assessment tools that trail quality in the performance of tasks. Use random monitoring and managerial-level monitoring to keep track of when tasks become closed so that tasks are not reopened when necessary. Clear guidelines as to what constitutes completion are specific to each task. This will limit the instances of persistent issues. Use rotations sensibly to assign diverse tasks, keeping team members engaged and preventing them from quitting. Transparency in task assignment will ensure that tasks are evenly distributed, reducing task quitting tendencies.	[34,111,112]
	R65—Increased Number of Reopened & Persistent Tasks R42—Task Quitting

. Regarding the strategy for the identified gamification risks against ethical, well-being, and performance issues, complementary to those of task-related and strategic risk from the literature, the Risk Mitigation Repository from [34] was added to ensure targeted and, hence, effective risk management during this sprint. The strategic, practical, and task-related risks were identified and gathered from the literature and are all available at http://surl.li/xapagk (accessed on 1 February 2025).

6.2.4. AGRM: Risk Avoidance During Sprint Planning

During the sprint planning meeting, the Scrum Master uses the Personality type/Risk histogram, as depicted in Figure 1 from the Personality vs. Risk matrix, as depicted in

Table 14. Personality vs. Risk Matrix.

Risk	Agreeableness	Conscientiousness	Extraversion	Openness	Total
R13—Distraction & Shift of Focus	2				2
R18—Anchoring Bias			1		1
R20—Embarrassments	1				1
R23—Disengagement & Anxiety	1				1
R25—Disruption of workflow and affecting several completed sprints	1				1
R26—Peer conflict and inaccurate achievement				1	1
R42—Task quitting	1				1
R43—Increased Stress, Anxiety	1		1	1	3
R57—Technical debt accumulation reoccurrence of issues			1		1
R59—Meet minimum requirements				1	1
R65—Increased number of reopened & persistent tasks		1			1
R66—Exploited by others				1	1
R67—Lower task quality & efficiency	1				1

; the risk histogram reveals each personality type’s counts and total counts of risks.

Given the input of the Scrum team members’ personality types, sprint backlog tasks, and the output of the personality type/risk histogram, the Scrum Master then reviews the Personalized Risk Profiles to understand contextual factors and game elements that were the reason behind risk emergence for a specific personality type with the highest frequency. Hence, the Scrum Master will be able to better allocate Scrum team members considering the gamification risks, as shown in

Table 15. Example of Task/Employee allocation matrix.

Task	Game Element	Openness	Neuroticism	Extraversion
Fixing high priority bug	20 pts, Bug Solver Badges	Employee 1	Employee 5	Employee 8
	Progress bar	Employee 1	Employee 5	Employee 8

.

7. Evaluation of the Proposed Model

This section presents the evaluation of the proposed AGRM risk reporting form and the AGRM process itself, highlighting the process’s usability, comprehensiveness, effectiveness, and helpfulness in real work environments. To support this, participants were given supporting materials such as Risk Reporting Description document, Personalized Risk Profiles (PRP), and Risk List Descriptions.

7.1. Evaluation of the Risk Reporting Form

Participants were introduced to the risk reporting form and instructed how to utilize it properly during the training and introduction session, as described in Section 3.3.4. The session started by detailing the structure, the form design with the different sections, and the use of every section. The participants were also provided with supporting materials, including a risk reporting description sheet, Personalized Risk Profiles, and a risk description list. The participants were then asked to evaluate the risk reporting form through Google Forms, available at https://shorturl.at/N2et0 (accessed on 1 February 2025) after using it within their sprints. The evaluation questions were based on several criteria, such as ease of use, navigation issues, clarity of language, length of the form, and the utility of supportive documents accompanying it.

• Ease of Use: Refers to how easy or intuitive the reporting form is for its users to navigate, understand, and operate without much confusion. The ease regarding the risk reporting form was perceived on a 5-point Likert scale, ranging from “Very Easy” to “Very Difficult”. This allowed the participants to provide their feedback in variations about the usability of the form.

Participants were also asked if they encountered any type of navigation issues while filling in the form; if so, in which section of the form did they occur, and what were their suggestions for making it easier to complete. The general results of the response indicated that the form was, overall, easy to navigate and scored well in its rating of ease of use.

• Clarity of Language: Refers to how the participants understood the terms, terminologies, and instructions involved in the form. The clarity of language was perceived on a 5-point Likert scale, ranging from “Very Easy” to “Very Difficult”. This allowed the participants to provide their feedback in variations about the usability of the form.

Most participants reported clarity of language and rated the form “Easy” or “Very Easy”. The language of the form was generally clear and understandable; however, certain responses raised the need for simplicity or explanation of technical terms if accessibility needs to be wider.

• Form Length: Refers to the appropriateness of length for capturing the relevant risk information. It was on a 5-point Likert scale, ranging from “Too Long” to “Too Short”. Most of the participants felt the form length was appropriate since it was comprehensive yet manageable. However, lower ratings from some users have shown that they found the form to be too lengthy or time-consuming, especially with heavier workloads. Suggestions for improvement included streamlining sections and allowing users to skip non-applicable items.
• Relevance of the Supporting Documents: Refers to which Supplementary Materials, such as immersion scenarios, risk reporting instruction sheet, and Personalized Risk Profiles (PRP), effectively support the participants in understanding and filling in the AGRM risk reporting form. It was measured on a 5-point Likert scale ranging from “Very Helpful” to “Not Very Helpful”. The immersion scenarios provided clear contextual information that significantly enhanced participants’ ability to identify and describe risks effectively.

7.2. Evaluation of the Risk Management Process

This section evaluates the usability, completeness, efficiency, and utility of the AGRM process for each sprint event regarding the overall usability experience of the participants. The participants were asked a series of open-ended questions, and selected quotes are presented below. Full transcriptions are available at https://shorturl.at/PDgri (accessed on 1 February 2025)

• Usability: Refers to the extent to which Scrum team members can easily utilize the AGRM process to identify, assess, and mitigate risks throughout their sprint events.

E1: “The AGRM process is structured and organized, with the associated activities, tasks, and responsibilities all were clear, and hence easier to understand and execute effectively”.

E2: “The format of the AGRM process is structured and clear showing the different phases of the sprint cycle, making the content quite clear as to where they stand, who does it, and what the artifacts needed in every step, hence really enhancing readability and usability”.

Several participants criticized how some tasks of the AGRM process were complex. Participant E10 commented, “While the process was user-friendly overall, the process of assessing task quality in conjunction with risk identification felt cumbersome and could be more streamlined”.

• Comprehensiveness: Refers to the extent to which the AGRM process is complete, covering all the risk management activities and tasks involved in-depth without the exclusion of important information. It contained articulate descriptions of the AGRM process activities, tasks, and artifacts needed.

E6 “The AGRM process content and artifacts are very comprehensive in coverage, including all that is needed to identify, assess, and mitigate the gamification risks”.

E2 highlighted, “The process layout for the AGRM process is structured with very distinct sections separating each phase of the sprint cycle in a way that clearly defines tasks, roles, and artifacts, thus improving readability and usability”.

During this step, discussions were had regarding the AGRM process activities. Debates on AGRM: Risk Mitigation activity, especially the risk validation tasks whether to keep or drop the validation step at the beginning of the sprint retrospective. They all agreed to drop this task. Highlighting the pros of having a risk reporting form, not speaking out about the risks that emerged publicly. Otherwise, they would have discussed such risks in public during the retrospective, as E7 explained: “If the gamification risks affected the team members psychologically, they might not even want to talk about them in public. So, to ensure privacy, we decided not to validate the identified risks”. As a result, the validation task is dropped from the risk mitigation activity, as shown in Figure 2.

• Helpfulness: Refers to which AGRM process is helpful, meaning a practical process applied for identifying, assessing, and mitigating gamification risks within sprints by the Scrum Team.

E10: “Well we did properly address the high-priority risks, which were most in line for mitigation”.

E10: “The risk management process gave a very good process for identification, assessment, and mitigation of risks, which allowed for smoother execution of sprints”.

E3: “The risk management process was quite instrumental in resolving issues and bottlenecks. It provided a well-structured process for the identification, assessment, and mitigation of risks.

E1: “The AGRM process identifies risks either during or off-sprint. Structured risk identification and assessment procedures ensure accumulation of risk factors is kept under continuous monitoring and addressed”.

• Effectiveness: Refers to which AGRM process fulfills its objectives most effectively, aligning risk management activities with the project objectives and handling and mitigating gamification risks in general. E5: “Risk-management activities made sure that the activities were toward the ultimate purpose of directing team effort toward critical risk”. E6 “The risk management activities after the sprint contributed a lot to the reduction of the total risk of the project and therefore this shows its success”. E9 noted that the risk reporting forms were “very legible and clear, enabling the team members to showcase and evaluate risk effect, and among these, the benefits that resulted from the AGRM process include thorough identification during any sprint event and not only a retrospective task, assessing risks on two factors depending on both perspectives of the risk owner and the Scrum master”.

While the AGRM process proved to be helpful in the identification and mitigation of risks, it was nevertheless not free from challenges. For the participants, even while the process helped distinguish the likelihood and severity of the risks, for its tools, there were concerns regarding the feasibility of monitoring the risk continuously in practice. As one participant (E9) put it, “Risk continuous assessment during the sprint was effective but often felt overwhelming when balancing it with other sprint responsibilities”.

7.3. Overall Evaluation of the Two-Phased Case Studies

This section presents a comparison of the two-phased case studies between the two teams in Phase 1 without the use of the AGRM process and Phase 2 between the same two teams using the AGRM process to identify, assess, and mitigate the gamification risks within the sprint.

The comparison showed the number of risks identified, mitigated, and escalated, along with the severity levels, categorized as very high, high, medium, or low, by teams using the AGRM process compared with a control group.

The results underlined the importance of structured risk management in agile environments for effective identification and mitigation of high-severity risks that could affect project outcomes. Scrum Teams were also reporting that embedding the risk reporting into their workflow helped them to perform a more efficient, deeper analysis of the root cause of their risks. Figure 3 provides a comparison between the performance of risk management among the two teams in Phase 1 without the AGRM process and with the same two teams with the AGRM process. This was based on three classified categories of risks: identified, mitigated, and escalated. Risk identified: 12 risks were identified by Team 1, 8 risks by Team 2, 20 risks in total, and only 3 risks by the control group. This goes to show that the structured risk identification process in Team 1 and Team 2 was far more effective than the unstructured process of the control group. Risks mitigation teams using the AGRM process (Team 1 and Team 2) mitigated 8 and 5, while the control group had only 2 mitigations. This shows that the proposed AGRM process enabled the Scrum Teams to act more proactively and effectively in the mitigation of risks. Risks escalated using the AGRM process; Team 1 escalated 1 risk, Team 2 escalated 2 risks, and the control group escalated 0 risks. Conclusively, the team that applied the process normally outperformed others, with evidence derived from the identified improvement within identification, mitigation, and risk escalation, unlike the control group.

Figure 4 shows the distribution of risk severity between Phase 1 (without AGRM) and Phase 2 (with AGRM). The teams using the AGRM process identified clear distinctions among very high, high, and medium risks, thus proving the efficiency of the framework in the identification and categorization of critical risks. In contrast, the control group identified risks in only two categories: high and low, underlining the lack of a structured approach. Clearly, the AGRM process shows how a well-guided process ensures a precise risk classification.

The AGRM process thus allowed teams to trace the impact of risk and its root cause, hence outperforming the control group in prioritizing risks and mitigating them more clearly and effectively using the two assessment factors in terms of Risk Exposure and task impact matrix.

Figure 5 shows that teams adopting the AGRM process identified a wider range of risk categories compared with the control group (without the AGRM process), the result of structured categorization which furthers the possibility for easier mitigation strategies because of clearly defined risk categories and risk related factors.

8. Discussion

This research has proposed a gamified agile risk management process supported by novel artifacts and findings from sequential multi-method studies. Two relevant research questions were addressed in this study: RQ1. How to structure a process to handle gamification risks. We proposed a systematic process, evaluated through a two-phase case study approach by two teams from two agile software development enterprises to ensure the usability and comprehensiveness of the AGRM process in real-world agile environments. RQ2. How to use the proposed artifacts in the process. The following artifacts were integrated into the process for the effective management of risks:

• Gamification risk reporting and assessment form: This form can be used either during or off-sprint because this ensures that risks are captured in real-time, thus allowing their dynamic and responsive management. It provides a common format where risks are documented, thus providing a more consistent and clear way of reporting.
• Personalized Risk Profiles (PRP): These are context-inclusive profiles that are used to identify the contextual risk factors of emerging risks in terms of the contextual risk factors related to the gamification of agile software development enterprises, organized by agile roles (described in Section 4.2.3). The contextual risks and risk factors related to the gamification of agile gamification were outputs of the study described in Section 4.1. These profiles provide a means to consider gamification risks from an individual perspective addressing contextual settings that were the reasons behind risk emergence. The PRP can be used during risk identification activity (described in Section 6.2.1) by the Scrum team members to help find the risks that emerged and their contextual settings, and by the Scrum Master during risk avoidance activity to better allocate Scrum team members to sprint tasks considering the gamification risks.
• Gamification Risk Register (GRR): A repository to track gamification risks from identification to mitigation. This ensures comprehensive risk documentation throughout their life cycle. It enables tracking, accountability, and monitoring of gamification risks by keeping a complete record of risk histories.
• Two-factor assessment: This step is conducted by the Scrum Master while reviewing and prioritizing activity. It uses the Risk Exposure Measure and Task Impact Matrix for quantifying and prioritizing the identified risks into the GRR.

Risk Exposure Measure: The Scrum Master will calculate the exposure of each risk by determining its likelihood and severity for quantifying those values identified for each risk. It will indeed provide a clear ranking of the risks viewed from the perspective of the affected Scrum Team members, making the prioritization process much easier and underlining high-priority risks needing immediate attention.

Task Impact Matrix: This is a matrix that assesses the specific impacts of risks on agile tasks, considering completeness and complexity. It makes it easier for the Scrum Master to perceive high-impacted tasks that are affected by risks with focused mitigation measures. Tasks with high-impact risks are labeled red and orange to show visual priority, while low-impact ones (labeled yellow and green) are deferred and mitigated later.

• Resolved Risks and Risk Factors Table: This table is used by the Scrum Master and Scrum team members during the sprint retrospective to help resolve the risks and mitigate the risks in terms of their risk factors and risk categories using the risk taxonomy (described in Section 4.2.2) described above to document risks that were mitigated and the factors contributing to their resolution. This will provide a tool for continuous learning to further enhance risk management strategies in the future. This encourages iterative improvement and sharing of knowledge across teams.
• Risk Mitigation Repository: This repository is used for gathering the mitigation strategies in terms of the risk categories used by the Scrum Team during the sprint retrospective for resolving and mitigating the highly ranked risks. It provides teams with the ability to apply proven approaches to address similar risks. This would promote consistency and efficiency in the implementation of mitigation strategies.
• Personality vs. Risk Histogram: This histogram is generated by the Scrum Master from the list of reviewed risks into the GRR during spring planning. It visualizes the frequency of the occurrence of risks by each personality type to provide insights that are useful for task assignment and resource allocation during optimization.
• Task Allocation Matrix: This matrix is used by the Scrum Master during the sprint planning, while performing the risk avoidance activity. This ensures that tasks are allocated in a responsible and strategic manner, which reduces and avoids the emergence of the risk of gamification. It helps in aligning tasks with appropriate team members based on roles and risk profiles. Benefit: It reduces the occurrence of errors or inefficiencies related to mismatched assignments. This prevents the mismatched assignment of tasks that would lead to an increased risk for some personality traits.

These artifacts supported effective workflow related to the processes of identification, assessment, and mitigation of risks specifically linked to gamification issues in an agile context. The process utilized outputs that came from previous studies to propose a methodology that would introduce an efficient way for agile teams to handle risks. In

Table 16. Advantages vs. disadvantages of the AGRM process.

Aspect	Advantage	Drawback
Systematic Approach	It is a clear, structured process to handle risks, making the practice consistent across teams.	Requires extensive training and knowledge of the artifacts to be applied correctly.
Novel Artifacts	Offers tools specifically designed to deal with gamification risks in agile environments.	Initial preparations of artifacts like the Task Allocation Matrix can be very time consuming.
Risk Review and Prioritization	It requires the Scrum Master to review and prioritize the highly ranked risks to be addressed and mitigated within the sprint	It requires an exhaustive series of steps in terms of the two assessment factors performed by the Scrum Master prior to the sprint retrospective to be able to filter the gamification to be addressed and mitigated within the sprint
Risk Avoidance	It aligns tasks according to personalized risk profiles, reducing and minimizing adverse outcomes using the personality/risk histogram and the task allocation matrix and personality risk profiles for contextual resolution of risk emergence.	It requires the Scrum Master to perform a series of exhaustive steps to be able to allocate spring tasks to personality types and roles not susceptible to experiencing gamification risks. Also, it is highly dependent on accurate data and risk profiling to be effective.

provides a summary describing the list of advantages and disadvantages of the AGRM process.

9. Conclusions and Future Work

This study introduces the AGRM process to agile Scrum to bridge critical gaps that are affecting it in terms of risk management pertaining to gamification. The proposed AGRM process ensures realization of the benefits of gamification, such as better level engagement, motivation, and productivity, without impacting negatively either on individual and team well-being or project outcome. Multi-stage studies underpin the process of AGRM, giving way to an orderly and organized way to identify, assess, and mitigate the gamification-specific risks. The key contributions of this study include the following: Systematic AGRM Process: A proactive and iterative process to be used to manage the risks of gamification through the sprint life cycle. Artifacts of innovation: Risk Reporting Form: This form is used by the affected Scrum Master who encounters gamification risk to be able to capture real-time gamification risks, thereby allowing for their dynamic management. Personalized Risk Profiles (PRP): For agile roles, context-inclusive risk profiles are used to identify the emerged risks and describe their various contextual risk factors for the agile roles. These PRP could be used by the affected team members as a reference for risks previously linked to agile roles and personality types. Also, they are used by the Scrum Master during the risk avoidance activity to better allocate Scrum team members considering the Scrum team member personality types and the previously identified risks. Gamification Risk Register (GRR): A repository to track the realization of risks, from their identification to their closure. This ensures gamification risks will be documented properly. Two-factor assessment: This metric is used by the Scrum Master to combine Risk Exposure measures and the task impact matrix to help in prioritizing risks effectively by generating a list of the highly prioritized risks. Gamification Risk Taxonomy: This categorizes the gamification risks for effectively handling the risk mitigation. Resolved Risks Table: This table is used by the Scrum Team during risk mitigation activity to resolve and understand the risks in terms of the risk impact factors and primary risk factors and making the mitigation of gamification risks easier. Personality/Risk Histogram: This histogram is the used by the Scrum Master in sprint planning, based on the list of risks reviewed in the GRR. It visually presents the distribution of risks according to their personality type. Task Allocation Matrix: This matrix helps in ensuring that tasks are allocated according to the strengths and characteristics of the Scrum Team to avoid mismatches and to improve team performance.

Real-life case studies on the validation of the AGRM process proved that it was effective in enhancing the identification, assessment, prioritization, and mitigation of gamification risk. The AGRM process will enable great enhancement in team dynamics and project outcomes while providing a robust foundation for the sustainable gamification of agile settings. Possible future work will involve exploring the adaptation of the proposed risk management process for application in software engineering education to enable graduate and senior undergraduate students to understand and manage gamification risks into their context.