A TAXONOMY AND METAMODEL FOR GAMIFIED AGILE DEVELOPMENT

S

I

, D

E

V

, S

Thesis for the Degree of Master of Science (60 credits) in Computer

Science with Specialization in Software Engineering

A T

AXONOMY AND

M

ETAMODEL FOR

G

AMIFIED

A

GILE

D

EVELOPMENT

Anđela Zorić

azc20002@student.mdh.se

Tamara Knežević

tkc20001@student.mdh.se

Examiner:

Antonio Cicchetti

Mälardalen University, Västerås, Sweden

Supervisor:

Federico Ciccozzi

Mälardalen University, Västerås, Sweden

External Supervisor:

Antonio Bucchiarone

Fondazione Bruno Kessler, Trento, Italy

Abstract

Gamification is applied in several aspects of software engineering. There are several concrete examples of the application of gamification to modern development approaches, such as Agile. Nevertheless, a classification of core elements that gamified Agile development should entail, to be used as a reference for systematically and consistently design gamified Agile development processes, is missing. The goal of this thesis is to, starting from concrete instances of gamified Agile development, generalize the common aspects and propose a classification of core elements as a reference taxonomy. We designed a research method based on the following four core activities: (i) analysis of the state of the art in Gamification applied to Agile development processes, (ii) definition of a taxonomy for Gamified Agile Development, (iii) formalization of the taxonomy in a metamodel, (iv) validation of the metamodel by instantiation of existing concrete examples of gamified Agile development. The contributions of this thesis are a structured taxonomy for gamified Agile development and its formalization in an instantiable metamodel. The metamodel was validated by instantiating it and comparing it to the existing examples from literature.

Acknowledgements

During the preparation of this thesis, we have expanded our knowledge and skills, but we also encountered many challenges. We would like to take this opportunity to express our gratitude to all those who helped us reach the very end.

We would first like to thank our thesis supervisors, Federico Ciccozzi at Mälardalen University and Antonio Bucchiarone at Fondazione Bruno Kessler, Trento Italy. They provided us with constant support, knowledge and expertise. Without them this thesis would not be of such quality.

We must thank Professors Filip Marković and Tijana Marković of the Mediterranean University who have provided continuous support to us during our year at Mälardalen University.

Finally, we must express our very profound gratitude to our families for providing us with encouragement throughout our years of study and through the process of writing this thesis. This accomplishment would not be possible without them.

Table of Contents

How Scrum Works? 8

3. Research formulation 10 4. State of the art and current limitations 11

Potential Gamification Misuse 12

Limitations 12

5. Method 13

6. Results 16

Taxonomy for Gamified Agile Development 16

MDA framework 16

Dynamics 16

Mechanics 17

Aesthetics 18

Formalization of the taxonomy into a metamodel 20

EMF 21 Metamodel 21 Achievement 22 Widgets 23 Action 24 Feedback 24 Goal 24 Measurement 25 Player 25 7. Discussion 27

Validation/evaluation of the approach/metamodel 27

Lessons learned 31

8. Conclusions and Future Work 33

References 34

1. Introduction

The key to achieving goals is the willingness to devote to its accomplishment, i.e. motivation. In software engineering it is important to keep up the motivation of developing teams, especially in Agile settings, where the "team" and its motivation are crucial to effective development. High motivation is very important since it makes the team more productive, and increased productivity is the main advantage of Agile development [1]. In order for a team to be productive, and therefore Agile to be effective, each team member’s motivational level for completing her tasks should be kept high. Unfortunately, repetitive, mundane and tedious tasks are also a part of the development process, and they might lead to motivational issues for some individuals. To prevent decrements in the motivational level and boost enthusiasm of team members, thus increasing productivity, appropriate rewarding systems could be used.

Gamification concerns the application of game elements in a non-game environment and is widely used to improve user engagement [2]. It is based on game mechanisms, e.g. badges, points, levels, included in other processes in order to engage people and motivate them to achieve their goals with different kinds of non-material rewards. Gamification is used in many different aspects of life, including business, education, marketing, and it is also present in Software engineering. Gamification is used in [3] for analyzing the positive impact on programmers’ adoption of Scrum, where it is concluded that gamification can have this positive impact by making programmers do more Scrum practices than if they had not been in contact with gamification.

We believe that a gamified rewarding system could be the answer to keep up motivation and boost enthusiasm in Agile development teams and in this thesis we focused on identifying and formalizing the core features of such a rewarding system for Agile.

The goal of this thesis was to analyze the state of the art, provide a taxonomy for gamified Agile development, and formalize it into an instantiable metamodel. The taxonomy could be used as a starting point for anyone interested in further research of this topic, while the metamodel could be used to implement gamified Agile development and even automate the rewarding aspects of it.

The structure of this thesis is as follows. Section 2 describes the background of the work. Section 3 provides the problem formulation, in which problem, objectives and aims are defined and described as well as the two contributions of this thesis. Section 4 presents the related work with a comparison to this thesis work. Section 5 describes the research method that we designed and followed and limitations. Section 6 describes the thesis contributions in detail, with focus on the description of the taxonomy and its formalization into a metamodel. Section 7 describes the evaluation of the metamodel as well as a discussion on the whole process of writing the thesis. Section 8 concludes the thesis with possible future works and conclusions.

2. Background

Gamification

Given that the lack of motivation is a common problem that can always be improved in any team and in various fields, as well as in Agile development, it is very important to try to motivate developers in the best and most efficient way. Just as it is easiest for children to learn the basics by playing games in order to progress later in life, this problem can also be solved through a certain type of play, i.e., gamification.

Gamification describes the application of gaming elements and mechanics to contexts in which gaming is not the primary business goal [4]. The concept of gamification engages and motivates people to adopt new behaviors simply by adding games and game elements to non-game processes [5].

As we all know, we all face various obligations and tasks every day. They can very often be very boring, monotonous and very likely to cause dissatisfaction. The main problem of the worker arises and a feeling of lack of motivation is created. When that happens, certain changes in work are needed for a person to be able to motivate themselves and get a stimulus. It is quite normal for this to happen at work or anywhere when we are doing something that we find boring or not useful, but this is very easy to solve. We can say that the very concept of gamification actually refers to the use of game elements to some real problem that is not from the domain of games. Its main goal is to enable the problems and their solutions to be solved interestingly, as the name tells us. With gamification, we can achieve an increase in productivity, above all in a very interesting way. It is important to design a game in which all participants will achieve better success, primarily through fun. This is probably the main goal of gamification. Therefore, various aspects must be considered and the goals of the game must be well researched, what needs to be achieved, in what way, who is going to be involved in the game and similar things. Gamification can not be strictly divided into categories so that we can say that it consists of certain parts, it is a matter of how a certain person will address the problem and try to solve it through this whole process. We can simply imagine this approach as an opportunity to make the tasks so much more interesting, i.e. make work assignments simply more fun.

All these ideas concerning the approach itself actually relate to achieving short-term or long-term goals, in what way? One of the easiest ways is to ask for feedback. Let's make a certain task that will be solved through the game and ask the person (the player in our case) to give feedback on all that, whether it was interesting, what they think can be improved or removed, what is good, what's wrong and so on. One of the main factors that show whether a game that has been developed is good can be measured by the progress of individuals or teams toward achieving a goal.

There are different approaches to the division of gamification and we will explain some of them. According to [6], one of the most commonly applied game structures is MDE: Mechanics, Dynamics, Emotions, which is appropriate in explaining gamification. The authors explain that "mechanics'' refers to rules, progressions and control systems during the gamification process, while dynamics refers to player behavior, and emotions represent positive attitude when interacting with the gaming system [6].

On the other hand, there is another approach called MDA framework, which stands for Mechanics, Dynamics, and Aesthetics. Robin Hunicke et al. explain in [7] it as a formal approach that tries to connect the gap between development and game design.

Gloria Teresita Huaman et al. [8] describe gamification as having three components, dynamics, and mechanics. As for our work, we stuck to the following: Player 'plays' the game which consists of dynamics, mechanics and aesthetics.

MDA Framework

There are a lot of ways for defining metamodel and taxonomy for Gamification but they do not cover all the aspects. As Bucchiarone A. et al. stated in [4] a large number of theories have been proposed regarding game design, but there are two of them which stand out, the two most cited frameworks which are MDA and the Elemental Tetrad. Authors have stated that from the designer’s perspective, mechanics create dynamics,

dynamics then create aesthetics. On the other hand, from the user’s perspective, MDA converts into rules, system and fun [4]. Hence, the focus of this research is on MDA.

As the name itself says, the gamification concept consists of mechanics, dynamics and aesthetics.

Mechanics are game elements which are in this framework described as actions, behaviors and control mechanisms that a player can make during the game, e.g. points, levels, badges, rules. Dynamics are presented as the behavior of mechanics during the player's interaction with the game, e.g. achievements, constraints, behaviors. Aesthetics are described as the player's emotional response to the game they play, e.g. feels, looks. This classification is widely used in gamification, and we chose it as a starting point for our taxonomy, which we later describe.

Agile

Agile is defined as a methodology where continuous iterations and testing take place throughout the whole Software Development Life Cycle [9].

In the [10] the authors have described Agile development as a philosophy, a way of thinking about software development. Agile methods consist of individual elements known as practices and these practices combine using version control, setting up coding standards, and presenting work to stakeholders weekly. It also focuses on achieving personal, professional, and organizational successes. In Agile methodologies, success is achieved by focusing on the delivery of value and cost reduction [10].

In Agile, the focus is placed on small units of work and with an accent on values and principles instead of on process. Principles of these methodologies are: customer satisfaction, accommodate changing requirements, frequent delivery of working software, collaboration between the business stakeholders and developers, support, trust, and motivate the people involved, face-to-face interactions, working software as the primary measure of progress, Agile processes to support a consistent development pace, attention to technical detail and design, simplicity, self-organizing teams, regular reflections on how to become more effective [11].

Vibhu Saujanya Sharma et al. [12] presented an approach for including gamification in Agile development. They combine gamification with Agile in a way that processes and software development data was the input to the gamification. They introduced this approach to real-life projects through a digitized process governance tool called Agile Workbench. From their experiments, they concluded that gamification motivates teams to deliver user stories as quickly as possible within respective sprints. Nitin Naik and Paul Jenkins [13] propose a Game-Based Learning (GBL) approach for Agile Scrum using Trello which is a web-based application used for designing any project in a collaborative environment [14]. It is stated that by Trello-based gaming activity, students can learn the SCRUM which is an Agile approach as a game and not as a complex methodology [13].

Scrum

Among numerous methods of this nature, Scrum is the most common in practice.

Scrum is a framework that provides steps to manage and control the software and product development process [9]. This framework, which is a combination of proven methods was designed to increase speed of development. The development team in short iterations (sprint) develops part by part of the whole product. The basis of Scrum is Sprint which is a time-limited iteration, from one to four weeks, during which the development team works intensively to achieve the set goals. Each sprint aims to deliver a potentially shippable product and it ends with a Sprint Review (meeting), where the functional results are presented and a review of the previous Sprint is made. Short Standup Meetings are scheduled to follow the achieved plan for a sprint. If the team does not manage to complete all planned activities during Sprint, the remaining work is transferred to the Backlog.

Figure 1: Scrum process inspired by Tuleap [15]

In the following, we will explain the whole Scrum process in more detail.

The main concept of Scrum is to develop the product step by step through iterations. Workflow of Scrum is basically a collaboration of the team and Scrum Master with the Product owner. This process involves a Scrum Master, the Product Owner and the Scrum Team [9]. The 3 main roles we distinguish are:

Scrum Master - works for the team, needs to educate and guide the rest of the team in the skillful use of Scrum

[16]. They should be taken to ensure that everyone on the team understands and is guided by the principles and practices of Scrum. Their task is also to help the team stay motivated when there are changes in product development, not to negatively affect them but to continue working at the same pace and to be successful. It is important that the person is motivated and understands the whole team because they should be the wind in the team’s back and when a certain problem arises they should try to help every member of the team. If the Scrum Master is not a motivated and energetic person, problems can occur, as it was said, because they should give positive energy to the team, even when things are not going well. It is not the person who determines who will do what, but the person who supports the team. This role can change during sprints if the team so chooses, but it is probably a better option to be the same person throughout the process.

Product owner - is responsible for maximizing return on investment by recognizing the most important and

generally all the characteristics of the product, after which it is necessary to translate them into a priority list of characteristics [16]. It is also important to decide which of the characteristics should be at the top of the list for the next Sprint. The whole process is necessary to be continuously repeated and to constantly determine the priorities of the list. There is also one specific case when the Product Owner and the customer are the same people. It is important to emphasize that the product owner and product manager are not the same.

Development team - the team is responsible for making the product itself. More precisely, they make the

product according to the customer's wishes and it has a very high degree of autonomy and accountability [16]. Because of all of this we can say that it is also self-organizing. If we are talking about a software product then the development team can include programmers, testers, designers etc. They suggest some ideas to the Product Owner to make the final product the best possible. It is a matter of agreement on how the team will be divided in the execution of jobs, whether more people will do one job or maybe just one person will do one job, and so there are many variations, but everything is in the agreement of the whole team to best organize the work.

How Scrum Works?

Figure 1 illustrates the Scrum process. The whole process in Scrum starts with the Product Owner first defining the requirements, what needs to be fulfilled, what are the characteristics necessary to be on the list of requirements. All this is put in a list of features called Product backlog [16]. It consists of items, which are primarily new customer features. A number of people also call items "user stories". In order to fulfil changes that the customer requires, the Product Owner needs to continuously update the product backlog and he/she together 8

with the team holds meetings (which will be explained below) and decides on various important things. One of them is the priority of a certain item so that all team members vote on what they think is the difficulty of a certain task. Generally, this voting is done by each member giving the number of points for a certain task and an agreement is made on which a number of points the majority voted for. It is also the practice to have up to 30 points per sprint. We can deal with a situation where some of the items in the Product Backlog can be pretty large so that we need to break them into smaller items. On the other hand, some of the items can be too small so that they can be merged. This is happening during the Product Backlog Refinement workshop or the Sprint Planning Meeting.

Before each sprint begins, there is a meeting called sprint planning. At the meeting, the team goes through the backlog, one item at a time, and for each of them it is discussed whether it is perhaps too complex and it needs to be divided into two parts or too simple to be a "user story". Tasks are set for each of the items and for each task it is determined which team member is in charge of it.

When the sprint starts it is necessary to hold daily meetings called daily scrum. These are short meetings, mostly no longer than 15 minutes and the team can determine whether these meetings will really be held on a daily basis or whether it is enough to organize them 2-3 times a week. The goal of these meetings is for each team member to say what they have done so far, whether they have encountered any problems and need help. Three things are common to be reported at that meeting: 1. What has been done since the last meeting?, 2. What is a person (team member) planning to finish by the next meeting?, 3. Whether the person encountered an obstacle while completing the task [16].

Each day, all members need to fill in how much time they have spent on a particular task. This results in a diagram called the Sprint Burndown Chart. This graph shows a new estimate of how much work remains until all the tasks are completed [16]. Sometimes that diagram is good, sometimes it is not, but it is important to give the team a graphic presentation of how they are progressing through sprints. It is good practice, as always, to complete tasks as soon as possible, so that there is no problem in transferring tasks to the next sprint and that there is no delay in product delivery.

One of the important features of Scrum is that the sprint never lengthens, it is of fixed length and must not be changed. It can happen, and the most common occurrence is that in the first sprint the team is overestimated so that it fails to do everything planned, but even in those conditions, the sprint is not extended, but only unfinished tasks are transferred to the next sprint. After the sprint is over, a meeting called a sprint review is organized. At this meeting, it is talked about the work done so far and this is the moment when the Product Owner and stakeholders have the opportunity to see what is going on with the product so far. After the sprint review, there comes a meeting called a sprint retrospective. This is an opportunity for the team to discuss the work so far, how it is progressing, whether everything is working or there are problems, what can be improved for the next sprint, what changes are needed and what is good and should be maintained.

One of the solutions when it comes to learning Scrum through a process of gamification, i.e. game is described in [17]. It is about a game called The Scrumheads, which has a purpose for practising the Daily Scrum activity. Since there are different members in the Scrum team, with different roles, it can be a problem that one person works too much while the other does nothing. Considering we are not always all aware of our actions and behaviours, this game aims to make each player aware of what their behavioural personality is [17].

3. Research formulation

Lack of individual motivation in development teams leads to decreased productivity and lower throughput of developers. Agile development is based on distributing smaller tasks among the team members to improve productivity. A common issue is lack of motivation of some team members can lead to a much lower performance of the entire development team.

Gamification has proven to be an efficient way to engage people in non-game activities using basic game principles and mechanisms [2]. It relies on users’ competitiveness and human nature and predisposition to engage in game-like situations. Basic functionality of the game is to attract players and motivate them to play by having a reward-punishment system for different achievements and errors. Since humans are born competitive, some more than others, game design elements and mechanisms such as points winning, levels reaching, badges collecting and comparing accomplishments with others, make a perfect means to motivate developers.

In the past decade, a lot has been achieved in gamification applied to software engineering. Some research efforts describe the potential of applying gamification to the development process, some propose design of gamification in Software engineering, and some give feedback on testing the implemented designs. Although the literature on gamification for Software engineering is rich, there does not seem to exist any formalized taxonomy to be used as reference when establishing gamified software development processes, especially in relation to Agile.

The goal of this thesis was to provide a reference taxonomy for gamified Agile development. To achieve this goal we needed to tackle the following research challenges:

1. Identify the core aspects of Agile development and gamification, and put them together to define a taxonomy for gamified Agile development

2. Formalize the taxonomy in a structured and instantiable format

The formalized taxonomy for gamified Agile development provided by this work is expected to:: ● Help in comprehending the Agile concepts in a gamified manner for beginners.

● Boost motivation of Agile team members for contributing more (or achieving specific goals). ● Use challenges based on Agile tasks to boost individual learning and team’s throughput.

Existing research works mostly describe gamification in the development context or give specific designs for it. In this thesis, we focused on the overall concept of gamification, and by carefully analyzing the state of the art in this area, we provided a taxonomy form understanding the essence of gamified development. We formalized the taxonomy into a metamodel, in order to enable the modelling of specific gamified applications for Agile development. Along with the taxonomy, this metamodel describes how the elements of gamification are interconnected and how they affect and depend on one another. The results section includes a comprehensive description of both contributions.

4. State of the art and current limitations

In this section, we will describe the already existing solutions and research related to gamified Agile development that we have found in the literature.

In the [18] Félix Garcíaa et al. propose a complete framework for the introduction of gamification in software

engineering environments and in their case study of a proposed GOAL framework implementation was in a real

company. It is composed of three main elements: an ontology - provides a set of concepts for gamification in SE

environments, and how they are related to each other., a gamification methodology - provides a step-by-step process for gamifying a SE environment, and a technological framework - tool that allows organizations to gamify their tools. It concentrates on the definition of rules of the game, achievements (punishments and

rewards) and behaviors in a way that the current tools that are used by the organization have to communicate only with the user’s behaviors. Basically, the main goal of this architecture is integrating existing tools in the workplace with a gaming-supported software engine that would evaluate the participants' behaviors, and reward them according to the rules of the game. As Rita Marques et al. [19] said software development teams still have difficulties to meet requirements which are partly due to a lack of motivation to apply Agile techniques. So, they proposed a gamification software tool that aims to make Scrum techniques more fun and also engage practitioners. The solution is designed by 6D Framework, an iterative game design process composed of six steps. Behaviors that players are performing and the metrics for measuring directly correspond to different Scrum techniques. Target players for this gamification solution are practitioners. As players perform their daily tasks, they are receiving feedback which should guide them to take further action and motivate them. When it comes to points and rewards, two types are defined: badges and gems (the virtual currency that can be traded for

real prizes in a marketplace). Authors have defined the fun elements, for example: a progress bar displaying the

user’s current experience points and the ones which are needed to pass to the next level. In that way, feedback on the player’s progression in the game is provided. Users are receiving tips on how to improve an issue’s specification. This offers users a wide range of emotions, allowing them to establish relationships and understand their progression. The use of game elements is currently used in many domains to help with motivating people in nongame scenarios and engaging users with high interaction, as described in [20]. Authors have described the experience of introducing Gamification design with a 6D framework that changes developer behavior. They created Scrum behaviours and badges as a measure of changing behaviours. When it comes to badges, there are: Scrum planning lover, Daily Scrum Lover, Sprint Review Lover, Sprint Retrospective Lover, Best Quality Product, Team-top task killer, the best team work, the best quality documents, the best presenter. In their described project there were 10 teams that participated in meetings for jobs such as estimation and planning, daily Scrums, review meetings, and retrospectives. Meetings were time-boxed, with well-defined start and end times. At the end of the Sprint (which lasted one day), the team product was checked to verify the quality followed ISERL UX/UI and coding standards. Finally, only one team won the prize of Team Top Task killers. Although only one team won the Team Top Task Killer award, it turned out that all the teams tried to complete the user stories. Sherly Hermanto et al. [21] concluded that the most efficient motivation elements are: money, team success, personal success, vacations and customer satisfaction. It is shown that people’s motivation will increase when they feel rewarded and valued. On the other hand, motivation can increase when the atmosphere of the competition is done well to support team performance. In the described prototype design about gamification in Scrum development they have used badges (each badge received a specific reward (movie ticket, shopping voucher, holiday trip, etc.) to influence users to do their best. In [22] the necessary components of the gamification framework are described, as well as important requirements of future gameful solutions: ''proper game design and runtime layers and a means to exchange events with the outside world''. This framework explains the adoption of gamification elements in pre-existing applications. The great importance of this framework is that the scalability and maintainability of the game mechanisms are increased. Will Snipes et al. [23] have proposed an automated system to monitor patterns of developers and finding best practices for the development process and recommending those practices to others in a gamified way with rewards for motivating them to adopt those practices. This is a way to improve productivity and proficiency of developers. This system can measure whether or not researchers' tools lead to increased efficiency for a particular task. In [24] the gamification approach in teaching students Scrum using the Minecraft game is described. The focus of research is to teach students Scrum methodology by pushing them to collaborate to achieve their goal in the game. This approach helps to focus on the project management part and learning Scrum methodologies. Using gamification to engage a team in the software engineering development process proposing RPG-like mechanics to incorporate in activities is presented in [25]. Erick B. Passos et al. showed how software development is closely related to a game. In [3] the prototype which is presented is a Java Application. It was developed to extract data from Jira. The prototype gave users real-time information about their performance in Scrum. The prototype can be

configured according to each company and its particular problem. Manal M. Alhammad1 et al. [26] performed a systematic mapping to show how gamification can be effectively used to support and motivate Agile practitioners. Authors have stated that points and badges were the most frequently used gaming components. Also positive (pair programming, refactoring, and testing, performance, knowledge and understanding), negative and non-significant impact of gamification on the different goals are described.

Limitations

Even though the first papers about gamified development date from a decade ago, and there are many concrete examples of its implementation, the problem is that it has not been done in a systematic way and with a consistent method. All of the existing papers propose a gamification design for agile development, but each has a specific approach to this process.

The goal of this thesis is to methodically categorize gamification elements, generalizing from concrete instances in existing papers, and try to derive a general approach that covers all the existing and future attempts on implementing gamified systems for agile development. The right way to do this is to first define all the needed concepts by developing a taxonomy, starting from the core concept of gamification and narrowing down the classification of element types and instances included in the literature. After that, it is necessary to explain how the terms depend on each other and what are the relations between them.

All of this can contribute and lead to the definition of a Domain Specific Language (DSL) [27] for such systems.

5. Method

There are a number of different scientific methods [39] that could be used to carry out research in the field of software engineering. Since none of the existing methods were completely adequate for our work, we designed a research method based on the following four core activities:

● Analysis of the state of the art in Gamification applied to software engineering, especially to Agile processes.

● Definition of a taxonomy for Gamified Agile development. ● Formalization of the taxonomy in the form of a metamodel.

● Validation of the metamodel by instantiating it to create models representing gamified Agile development from the literature.

The method and the process of our work are illustrated by the steps presented in the Figure 2 below.

First, we carried out a deep analysis of the existing literature regarding the use of Gamification in software engineering in general and in Agile development in particular.

Figure 2: research process shown in steps

The first and second steps were to identify papers that provided more information on the topic of our work (step 1). We did this in a semi-systematic manner, but we did not focus on the systematic aspects since we only needed to identify a comprehensive set of papers in our scope. During this phase, we searched for papers in relevant databases such as IEEEXplore, Scopus, Springer, ResearchGate, etc. in order to find papers that refer to gamification in software engineering in general, with special attention to agile development. We started looking for papers with search string (“gamification” AND “software engineering”), but the number of results was not satisfactory. Then we decided to expand our search string, so we included the following keywords mentioned in metadata: ((“gamification” OR “gamify” OR “gamified” OR “gaming”) AND (“software engineering” OR “agile” OR “scrum” OR “SE”)). This resulted in around 1000 papers, but there were many duplicates in different databases. After reading the abstracts of the papers (step 2), we ruled out a large number of them, since they just mentioned gamification and software engineering, but their scope was not gamification application in the field of software engineering (step 4). Parallel to collecting (1) and reading (2) the papers, we gained an understanding of gamification and its principles along with its characteristics both from those papers, and from the Internet and relevant literature about gamification itself (step 3). After reading abstracts of all papers we found and excluding irrelevant ones, we were left with around 200 papers mentioning gamification in SE in the way that seemed relevant, so we read all of them. In this process, we looked for papers that not only mention gamification in software engineering, but explain or propose a new design for gamified SE or show the results of implementing such systems in real scenarios, since those papers could actually contribute to the derivation of the taxonomy that was our goal. This step left us with 13 papers that we found relevant, in a way explained previously. Steps 1, 2 and 4 were limited to papers that we had access to in full-text, and that were in english. We did not have any other exclusion criteria, other than the relevance to our work.

Relevant papers were organized in a table (step 5) and helped us derive the taxonomy. Gamification elements were extracted from the papers, and added to the table gradually (step 6).

Taxonomy definition was an iterative process and we looked for more papers until the taxonomy was complete (step 7). After we collected the papers, we continued with the step of writing a short summary for each paper. We wrote the summary for the simple reason so that we can quickly recognize what is the content of a given paper. Table 1 shows the procedure described.

For each of the papers, we tried to single out the parts that referred to the three core elements of gamification (step 6) being dynamics, mechanics and aesthetics [28]. This resulted in the definition of the taxonomy that represents the first contribution of this thesis (step 7).

By further and more detailed reading of the papers, we were able to single out the types for each element of gamification (step 8).

Moreover we identified specific instances of each type of gamification element (step 9). These types refer to the Agile method - Scrum, and in this way, we were able to connect elements from the Agile method with elements of gamification.

After completing all of these steps, we formalized the taxonomy into a metamodel (step 10) defined in the Eclipse Modeling Framework [29]. The metamodel was then used to validate the taxonomy (step 11) by creating models representing the gamified Agile development cases extracted from the literature. In this way, we could show that the metamodel (and the taxonomy) is legit and that it provides the needed elements to model gamified Agile development processes.

ID TITLE SUMMARY

1 gamification in softwareA framework for engineering

Case study of a proposed GOAL framework implementation in a real company. Gamified areas were project management,

requirements management and testing. 2

A Gamification Approach for Distributed Agile

Delivery

The Distributed Software Development team is divided into smaller teams, and gamification is used to improve cooperation between smaller teams, but to encourage competitiveness between different teams. The researchers developed Agile Workbench, a tool that monitors development process, and awards teams for their accomplishments.For each user story, a team receives points based on how fast and well it is completed. Scrum master, and Product owner have a possibility to add additional points to reward certain team. Progress of the teams

can be followed in the dashboard that shows individual progress of teams, and how they stand compared to others. Agile tools that can be gamified are Jira,

Rally and RTC.

3 A gamification solution

for improving Scrum adoption

The solution is designed by 6D Framework, an iterative game design process composed by six steps.

4 Engaging and Motivating_{Developers by Adopting}

Scrum Utilizing Gamification

6D framework that changes developer behavior while developing software by following a Scrum framework.

5 Gamified SCRUM Design_{in Software Development}

Projects

Authors concluded that the most efficient motivation elements are: money, team success, personal success, vacations and customer satisfaction.

8 Towards Engineering

Future Gameful Applications

The necessary components of the gamification framework are described, as well as important requirements of future gameful solutions: ''proper game design and runtime layers and a mean to exchange events with the outside world''. This framework explains the adoption of gamification elements in pre-existing applications. The great importance of this framework is that the

scalability and maintainability of the game mechanisms are increased. 9

Towards recognizing and rewarding efficient developer work patterns

Proposed system for monitoring patterns of developers and finding best practices for development process and recommending those practices to others in a gamified way with rewards for motivating them. This is a way to

improve productivity and proficiency of developers

10 Training Scrum with

Gamification

Gamification approach in teaching students SCRUM using the Minecraft game. Focus of research is to teach students SCRUM methodology by pushing them to

collaborate in order to achieve their goal in the game.

Turning Real-World Software Development

into a Game

Using gamification to engage team in software engineering development process proposing RPG-like mechanics to incorporate in

activities. 11

Using Gamification to Increase Scrum Adoption

A Java Application was developed to extract data from Jira. The prototype gave users real-time information about their performance in

Scrum. The prototype can be configured according to each company and its particular problem.

12

13

What is going on in agile gamification?

A systematic mapping is performed in order to show how gamification can be effectively used to support and motivate agile practitioners. Authors have stated that points and badges were the most frequently used gaming components. Also positive (pair programming, refactoring, and testing, performance, knowledge and understanding), negative and non-significant impact of gamification on the

different goals are described.

6. Results

Following the workflow explained above, we started by collecting relevant papers we had access to, in order to gather all the important information we needed for the taxonomy. By reading through these papers, we learned a lot about how gamified development works, and how it has been implemented until now. After carefully selecting relevant papers, we began creating the table for our taxonomy. We started generating the table from the three main gamification elements according to the MDA framework - mechanics, dynamics and aesthetics, as shown in column one of Table 2. As we further read the papers, we marked and entered in the table all the elements they mentioned that fall into these categories, classified by their concept, presented in column two of Table 2. The second column was mainly based on the GOAL framework ontology [18], since they covered most part of the elements. After this, we started dividing the elements by different types, explained in the papers, providing a deeper explanation of the elements, as shown in column three of Table 2. After that, we looked for element instances, which represent the concretization of the element types, along with the references to the papers they were stated in, presented in columns four and five of Table 2. References to the papers in Table 2 and Table 3 do not match reference numbers in this report, but the numeration from the first table we derived. That table is available here: https://bit.ly/3hB4Jrh. Column two of Table 3 shows description, or definition of each of the element instances, for clearer understanding, and column three of Table 3 contains concrete examples of instances from the papers, with reference to its source.

After this recursive process of constantly rereading the papers in order to go deeper into the division and essence of gamified development, we provided the complete taxonomy of gamification in Agile development.

Since the taxonomy only shows the classification of the elements mapped to the MDA framework, we began to formalize the taxonomy in the form of a metamodel, which would explain the relations between different elements, and their dependence. The metamodel was created using the Eclipse Modeling Framework [29], by defining each row from Table 2 as a separate class. We will elaborate both taxonomy and metamodel in the sections below.

Taxonomy for Gamified Agile Development

As we have already stated, the very notion of gamification cannot be strictly divided and we cannot say that it consists exactly of certain elements, it is a matter of seeing how we decide to divide. As can be seen in Table 2, our division refers to the Player [18][12][19][20][21][30][25][3] who 'plays' the GAME which consists of dynamics, mechanics, and aesthetics, based on the MDA framework [28]. We opted for this division because it was the most acceptable to us, the easiest to understand and single out which are the elements of gamification that fall into a particular category.

Every game of course must have its players, and in our case, that player can be an individual [18][19][20][21][30][3] or a team [18][12][20][25][3]. When it comes to Scrum the division is simple, an individual can be a Scrum Master [19][20][21], Product Owner [19][20][21], developer [19][21][3] or practitioner [18][19][30]. If it is a team, it is of course a development team that works on the creation of the final product, but it can be divided into smaller sub teams, which are working on different parts of the project.

MDA framework

As for the dynamics part, the division is made into achievement [18][12][19][20][21][30][31][25][3], goals [18][12][19][20][21][30], measurement [18][12][19][20][30][3] and feedback [18][12][19][20][30].

The player establishes a certain success and these achievements can be good or bad, i.e. unsuccessful. So, they can be divided into punishments [1][3] in a bad case and rewards [18][12][19][20][21][30][31][25][3] in a good case. When it comes to player punishments we found that these can be negative points[18][25]. These negative points can be obtained when a player, for example, does not complete a task on time.

When it comes to rewarding players this is a very important part and we can say that it is the biggest or one of the biggest motivations for a player or development team. It is in the nature of people to feel good and satisfied after a well-done task, and it is important to reward them in the right way so that everyone feels like their efforts are appreciated, and be motivated, which is the main idea of our entire report so far. When a player knows that they will receive a reward for a certain job, they will try harder than they would otherwise, because there is more 16

reason for that. According to the analyzed papers, we divided the rewards into 3 instances which are badges [18][19][20][21][30][3], medals [18][25] and points [18][12][19][20][21][30][3] (in this case positive).

For an easier understanding, examples of badges retrieved from the papers are: Clerk badge, which is given to players after 10 issues are resolved [19]; Daily Scrum Lover badge which is given to players for attending all daily meetings in a sprint [20]; Helper badge, given to Scrum Master for intervening to help the team, etc. Medals [25] are given to players for specific achievements, based on the percentage of completed achievements (50%, 75%, 100% respectively).

Points can be calculated based on the revenue of the story, number of days needed to complete the story and total number of days in a sprint [12]; or they can have fixed value, e.g. 20000 points per one user acceptance story [20]; 100 points for sharing knowledge with others [3].

Every game would not be complete if it did not define the goals nicely and as a rule. These goals are presented in our table and divided into gaining points [18][12][20][21][30], boosting productivity [19] and reaching levels [18][19][30]. Players can collect points for various tasks. We have a division to collect points for a completed task [18][21][30], a completed story [12][20] and a completed final product [20]. When we talk about boosting productivity, we generally mean as few unfinished tasks per sprint [19] as possible. And the third goal is to reach the level that in our case refers to gaining points [18][19][30] by successfully completing the story from the backlog.

How to measure how successful a team or individual player is? Pretty easy, we just need to define metrics [18][12][19][20][30][3] according to which it will be known exactly how an individual's productivity is measured. For the metrics element type, we have 3 instances relating to the number of user stories set per sprint [18][12][19][20][30][3], the number of user stories successfully done per sprint [18][19] and the number of meetings an individual attended per sprint [30][3].

Feedback [18][12][19][20][30][3] has always been very important for the development of everything because in that way we get information on whether something is wrong, what needs to be changed, what is good, interesting, what needs to be improved and the like. Feedback is also very important for the players themselves because when they get positive feedback [18][12][19][20][30] it gives them the wind in their backs, they gain self-confidence and want to continue at the same pace. On the other hand, like positive criticism, negative criticism[18][19][30] is important in a person's development because in that way the player knows what his weak points are and what things he/she needs to fix. Players also give feedback for the game itself because it was made primarily for them, motivating them to work better in an Agile environment. So, it is quite clear that we recognize positive and negative feedback. When it comes to positive feedback, we are talking about instance recognition, and when it comes to a negative instance is alert. Reminders can be shown to players in the form of a popup message [12], or a reminder [19].

In [18] Garcíaa F. et al described dynamics as a group of concepts that were linked to the satisfaction of player desires. Achievements are presented as rewards or punishments. In [18] Garcíaa F. et al described dynamics as a group of concepts that are linked to the satisfaction of player desires. Achievements are presented as rewards or punishments.

In [18] Garcíaa F. et al described dynamics as a group of concepts that are linked to the satisfaction of player desires. Achievements here are presented as rewards or punishments. In [3] authors stated that dynamics have significant importance on the game and described dynamics as something not visible, emotions and relationships.

Mechanics

As for the mechanics part, it refers to the action of the game. Following section describes the action with its divisions. It is divided into player behavior [18][12][19][20][30][3], player performance [18][19] and artifact

characteristics [18][12].

As for player behavior, we divided them into attendance at a sprint planning meeting [18][19][20][30][3], attendance at sprint reviews [18][19][20][30][3], attendance at daily meetings [18][19][20][30][3], encouraging cooperation [20][3] and completing tasks.

In the related papers [20][3], examples of wanted player behaviors are: A player attends one Sprint planning meeting, or A player attends all Sprint planning meetings, which result in gaining points and badges if completed. The same goes for attending Sprint review meetings. For Daily meetings, players can receive different amounts of points and different badges for attending: one daily meeting; five sequential meetings; 10 sequential meetings; 15 sequential meetings; or all daily meetings [3]. Encouraging cooperation is a desired behavior, which brings players additional points and badges, e.g. if an individual player shares knowledge with other players, or Scrum Master helps the development team [20][3]. Completing tasks is also very important player behavior, and it gives different results if all stories in one sprint are completed or all stories in the whole project are done successfully [3].

Attendance at meetings is an important thing in Scrum . These meetings should not be missed. In this way, the player is actually involved in the whole process and in that way he/she can also collect points or certain rewards, as well as lose points for absence. In addition to different types of meetings, an important factor is to encourage cooperation, which is crucial in a good relationship in the team for successful work and successful development of both tasks and product. Finally, the basic action for both, the process of product development and development in general and also for Scrum that must be followed is the completion of tasks.

Hermanto S. et al. in [21] presented badges, which are an integral part of mechanics. Players can collect them and depending on the number they can replace them for a specific reward (movie ticket, shopping voucher, holiday trip, etc.). This is described as a great motivator for influencing players to do their best. In [18], it is stated that the game is composed of a set of actions that can be formed into missions, according to specific rules. Actions which are described are related to the behaviour and performance of the player and artifact characteristics. There are also described missions that are a way to systemize the effort of a player.

Aesthetics

As for the part related to the aesthetics element in gamification are widgets [18][12][19][20][21][30][32]. Widgets refer to dashboards [18][12][19][30], profiles [18][19][21][30], performance graphs [32] and leaderboards [18][20][21]. It is useful when a player knows what "levels" he /she has reached, in fact, what achievement he/she has reached in a certain moment, and for that, we are using leaderboards and scoreboards. Such a sense of progress if they see that they have achieved better success compared to others is very important even if it is small, because the main point is for players to stay motivated, and as soon as they see that they are progressing, motivation goes without saying. We can say that this is very big for players even if they see them falling on these boards because it is also a motivation to work even better to rank better.

In [21], the part of the aesthetic related to the profile of a player is mentioned. So, players can write down their feelings or some quote to give information to other members about what his current feeling is. A player can also see his points and the points of other players on the leaderboard and in that way stay motivated or gain motivation to be on the top of the list. In [18], aesthetics is defined as having a visual representation of the players and their results. Widgets are divided into 3 types: Profiles, Leaderboards and Dashboard.

In table 3. we have a little more detailed explanations and for some of them and additional examples.

Table 3: addition to table 2

Formalization of the taxonomy into a metamodel

The taxonomy is a good way to generalize classification, and has often been used in software engineering with the purpose of providing deeper understandings of what already exists in specific fields [33]. Since the purpose of taxonomy is to classify something, we considered it necessary as a starting point for our work, with a goal to classify different gamification elements used in existing papers, proposed by other researchers, in accordance with the MDA framework. The taxonomy shows which are the core elements of gamification, used in Agile development, and how they can be divided, with provided instances of the elements extracted from the papers, but what is not clear from the taxonomy is the relations between different elements and how they decided to formalize the taxonomy by creating a metamodel of gamified development processes.

Taxonomy was formalized in terms of a metamodel by using Eclipse Modelling Framework [29] which is described below. We decided to use EMF on the recommendation of our supervisors, as it is the core of all the model-based tools in Eclipse. Before we explain our metamodel and all parts of it, it is important to understand what the term metamodel actually means. “Meta” means a superstructure over some object [34]. So, it is logical 20

that the term metamodel refers to the very process of creating models from already existing models. We can say that they are tools for creating models [34].

EMF

Eclipse Modelling Framework (EMF) is a modelling framework based on Eclipse. It is a code generation platform that is used to develop tools and applications based on a structured data model [35]. Through this framework, we can automate the process of creating metamodels and integrating them with modelling software. Other output formats, such as HTML, can also be achieved using the syntax; the syntax itself can be interpreted by an application at runtime [36]. The Ecore meta-model is the key aspect of the EMF. It defines the model that can be applied to user-defined models.

The ecore file allows defining:

EDataType: represents the type of an attribute

EClass: it represents a class, which can have zero or more attributes and zero or more references EAttribute: it represents an attribute, it is required that it has a name and a type

EReference: it represents one end of a relationship between two classes. It has flags to indicate if it represents a containment as well as to point to the reference class.

The ecore file shows a root object that represents the entire model. The children of the model represent packages, while the children of packages represent classes. Next, if we continue, children of classes represent the attributes of those classes.

Metamodel

Below is a Figure 3 of a metamodel where in the very center there is a game element that is connected to all its elements. The diagram clearly shows how certain elements are related to the ''game'' and their relations. The entire metamodel was not included in this report because it could not fit taking into account its size, but is available at: https://bit.ly/2RyyDlk.

The metamodel's figure shows that in the centre is "Game", which is the core of the diagram. All elements are related to the "Game" since it is the root of this metamodel. The "Game" has a relation to all the elements in such a way that each element is part of only one game. This relation [1,1] is because in our case, all elements refer to only one game. When it comes to the inverse relation, i.e.. between the "Game" and each of the elements, the relation is [1, *] for all elements except for "Narrative". The reason for this relation is because in the game there may be no narrative. On the other hand, a game involves having multiple players, goals, achievements, feedback, widgets, measurements, and actions. Figure 3 shows the core element, Game, related to all the gamification elements from the taxonomy. The further division on the elements and relations between them are explained below.

Figure 3: metamodel

Achievement

In Figure 4 we can see the achievement element in more detail. This class has three attributes, a name, a message and whether it is visible. Each achievement must have a name that is implied as well as a description of what has been achieved and how, the visible attribute refers to whether that success is visible or not.

Figure 4: Representation of element Achievement

Widgets

In Figure 5, for the part related to widgets, a generalization has been made so that there are leaderboards, dashboards, profiles, and performance graphs. The profile has the attribute avatar, which would represent, for example, a picture of the player or an avatar by which he/she is recognized. As for the leaderboards, the board presents the players with their points, they can see where they are at the moment, that is, their position, ranking on the list, and of course who it is, the name of the player or team for which the information is presented.

Figure 5: Representation of element Widget

Action

In Figure 6 we can see the part of the diagram related to the action. The action is divided into three parts relating to player performance and behavior and artifact characteristics. When we talk about all three types of action there is a certain further division. Regarding player behavior, we distinguish five types, they are related to sprint planning, sprint review, making backlog, daily meetings and completing tasks. When it comes to player performance, we distinguish only two types, and that is actually only whether the task is done or not, so we have two attributes for the number of completed and the number of uncompleted tasks. The characteristics of the artifact involve three elements. They relate to the product backlog, sprint backlog and coding.

Feedback

When it comes to the part related to feedback, in Figure 7 there is a type of feedback that can be either positive or negative. In addition to the type of feedback, affirming comments and corrective comments are also included. These comments serve that in addition to knowing whether the feedback is good or bad, we can also have more detailed information so that we can improve things which proved to be not so good.

Figure 7: Representation of element Feedback

Goal

Figure 8 shows the goal element with its division. The term goals are related to productivity, levels, and points, that is, increasing productivity, crossing levels and collecting points. As for the levels, it is considered that the levels are crossed when a certain story from the backlog is done. Points are collected as we have already explained for different types of problems, so we recognize collecting points for a completed task, collecting points for a completed story and collecting points for a completed final product.

Figure 8: Representation of element Goal

Measurement

Figure 9 shows the measurement element. For each measurement, we have a name and a unit. The unit tells us what is the number of a measurement which has been made. It is also important to identify how the measurement is performed so that for this part there are three variants related to the number of user stories to be done per sprint, the number of meetings the player attended per sprint and the number of user stories done during one sprint.

Figure 9: Representation of element Measurement

Player

Figure 10 shows the element player. A player can be an individual or a team. Each player has a name and a role in the team, the company. As for the individual player, we identify the roles that are defined in the scrum. It is about Scrum Master, Product Owner, tester, practitioner or developer. For the type team, there is only a development sub-team. It’s a matter of the team agreeing on how they will split.

7. Discussion

In this thesis, we were looking at concrete instances in existing papers and we tried to characterize a more general solution that can be applied to any implementation attempt on gamification for Agile development in the future. The first papers about this topic date from a decade ago, but overall, there are not many papers that might actually be helpful when trying to implement gamification in Agile development. That is why we believe that this thesis will help those who want to motivate their development team in order to make it more productive and devoted to their work.

While there were some difficulties, such as the absence of concrete results in the papers, we were able to find a significant number of papers that provided results that we used to validate the metamodel.

Another challenge was the fact that a certain number of papers were exclusively focused on either gamification or only Scrum or Software Engineering in general. Regardless, we think that we have overcome this barrier and that we have managed to combine these two different aspects in the work. Our experience through reading papers that only addressed specific topics helped us gain a deeper understanding of both approaches and brought them closer together.

Authors cannot always cover just about every aspect related to the development or gamification process itself, and in most cases, this is something that is taken for granted. Thus, our metamodel may have some shortcomings and we may be experiencing the same problem. Despite that, at the time of writing, we tried to include all aspects into consideration by developing a taxonomy.

Validation/evaluation of the approach/metamodel

Since our metamodel was created based on the related papers we found and had access to, in order to validate the metamodel, we instantiated it using EMF by creating models based on three papers [18][20][12] we used for taxonomy. Eclipse modeling framework allows us to create metamodel in Ecore format, and generate Java code for each created class [37]. By running our metamodel with generated classes as a new runtime Eclipse, it allows us to instantiate models from our metamodel by predefined classes and relations. Each model contains elements presented in the papers, compliant with our metamodel structure.

By validating models extracted from the three related papers [18][20][12] by our designed metamodel, we wanted to prove that the metamodel we created, and the rules that define the structure of the schema, comply with different structures and designs from the papers. For the instance models, we used A framework for gamification in software engineering [18], Engaging and Motivating Developers by Adopting Scrum Utilizing Gamification [20] and A Gamification approach for Distributed Agile Delivery [12] papers. We will show and explain the results below.

For A framework for gamification in software engineering [18] paper, following the GOAL Framework ontology they explained, we created a model based on the metamodel schema.

We added two Individual Players, named Player one, with player type of a Practitioner, and Player two with player type of Scrum Master, as shown in Figures 11.1 and 11.2.

Since Feedback in the GOAL Framework ontology can be positive and negative, we added Positive Feedback of type Recognition for completed tasks, and Negative Feedback with type Alert for uncompleted tasks.

As mentioned in the paper [18], the measurements used were Measurement for Task completed, and Task uncompleted, and Metrics Number of given stories per Sprint. Measurement Task completed and Metrics Number of given stories were related to Positive Feedback Task completed successfully, and Task uncompleted to Negative Feedback Task not completed.

As for Achievements from the paper, we designed two Rewards of type Point, one with 100 points value, and the other with 300 points value.

We also added a Reward of type Award, named Badge, to represent the badges that players collect.

Action Player Performance was formed with type Finished Tasks, and was assigned Rewards 100 points, and Badge, to show which achievements the player can get by fulfilling that action.

Goals of the proposed framework were Gain Points and Reach Levels, so we added them for Completed task and Gained Points respectively. Both Players were assigned Goals Gain Points Completed task, and Reach Levels Gaining points, since all the players should strive to accomplish them.

As an example, we assigned Achievements Reward 100 points, Reward 300 points and Reward Badge to Player one, and Reward 100 points and Badge to Player two. They were also both given Action Player Performance Finished task. Positive Feedback for completed task was given to both Players, and Negative Feedback for uncompleted task was assigned to Player two.

Another element mentioned in the paper which we included in the model is Widget associated to both Player one and Player two.

The complete structure of this model is shown in Figures 11.1 and 11.2 as Ecore model and XML file, respectively.

Figure 11.1

Figure 11.2

The second paper we used to validate our metamodel was Engaging and Motivating Developers by Adopting Scrum Utilizing Gamification [20].

The paper introduces the design of gamification in Scrum, so similar to the previous model, we followed the design to generate a model in Ecore.

Since the paper is about gamification in Scrum, we added Individual Players Scrum Master and Product Owner, and Team Player Development subteam, as mentioned in the paper.

We included Positive Feedback for Meeting attended and Helping teammate, as those are defined in the design. Since the Measurements mentioned were for Attended meeting. Helping teammate and Story completed, we included them into the model, along with Metrics Number of stories per sprint, used to calculate number of points to be assigned. Measurement Attended meeting was associated with Feedback Meeting attended, Measurement Helped teammate was associated with Feedback Helped teammate, and Measurement Story completed and Metrics Number of stories per sprint to Positive Feedback Story completed successfully.

Achievements we defined were Reward Badge, since Players collect badges for tasks, and Reward Points per sprint, because they gain points for completed stories.

As for Actions, we added Player Behavior for Attending Sprint Planning Meeting of type Attending Sprint Planning, which results in Rewards Badge and Points per sprint; Player Behavior Attending Sprint Reviews of type Attending Sprint Reviews, also with both Rewards as Achievements; Player Behavior Attending Daily Meetings of type Attending Daily Meetings with the same Rewards; Player Behavior Helped teammate of type Encourage Cooperation with both Rewards; and Player Behavior Task completed of type Completing Tasks, with the same Rewards.

Goals we added according to the paper are Gain Points For completed story and Gain points For Project completed, and Individual Player Scrum Master, and Team Player Development subteam were assigned both Goals, and Individual Player Product Owner was assigned Goal Gain Points Project completed.

Individual Player Scrum Master was given Actions Player Behavior Attending Daily Meetings, Attending Sprint Planning Meeting, Attending Sprint Reviews, Helped teammate and Task completed,

followed by Achievements Reward Badge and Reward Points per sprint, and Feedbacks Helped teammate, Meeting attended and Story completed successfully. Individual Player Product Owner was given Actions Player Behavior Attending Daily Meetings, Attending Sprint Planning Meeting and Attending Sprint Reviews, followed by Achievements Reward Badge and Reward Points per sprint, and Feedback Meeting attended. Team Player Development subteam was given Actions Player Behavior Attending Daily Meetings, Attending Sprint Planning Meeting, Attending Sprint Reviews, Helped teammate and Task completed, followed by Achievements Reward Badge and Reward Points per sprint, and Feedbacks Helped teammate, Meeting attended and Story completed successfully.

An additional element from the design in the paper was Leaderboard, which was associated with all the Players in the Game.

Figures 12.1 and 12.2 represent the explained Model as Ecore and XML files respectively.

Figure 12.1

Figure 12.2

Another paper that served us to validate our metamodel was A Gamification approach for Distributed Agile Delivery [12].

Since the paper is about distributed agile development, the Players we included were Team Players Subteam one and Subteam two.

The paper mentions only Positive Feedback, so we added it for Story completed successfully.

Measurements used in the paper were Quality of code for additional points, and Metrics Number of stories per subteam per sprint used to calculate points given to the Players. They were both associated with Positive Feedback Story completed successfully.

Achievements that Team Players can gain in the paper are Rewards Points For completed story and Bonus points.

Since in the paper they mention Player Behavior Completing tasks and Artifact Characteristic Code quality, they were included in the model, associated with Achievements Reward Points for completed story and Bonus points respectively.

The Goal of the proposed design in the paper is Gain Points For completed stories, and it was assigned to both Team Players.

Team Player Subteam one was added Action Player Behavior Completing tasks, with Positive Feedback Story completed successfully, which resulted in Achievement Reward For completed story; and Team Player Subteam two was given Actions Player Behavior Completing tasks, along with Artifact Characteristic Code quality, with Positive Feedback Story completed successfully, resulting in Achievements Reward Points for completed story and Bonus points.

The Widget that they proposed was Dashboard, which we added both Team Players to. Figures 13.1 and 13.2 show this model as an Ecore and XML file respectively.

Figure 13.1