ABC-Sprints: Adapting Scrum to AcademicGame Development Courses

Jonas SchildEntertainment Computing

University of Duisburg-Essen47057 Duisburg, Germany

jonas.schild@uni-due.de

Robert WalterEntertainment Computing

University of Duisburg-Essen47057 Duisburg, Germany

robert.walter@uni-due.de

Maic MasuchEntertainment Computing

University of Duisburg-Essen47057 Duisburg, Germany

maic.masuch@uni-due.de

ABSTRACTWe propose a course design that ts a practical game devel-opment project into a regular game design lecture course.As this approach requires a consistent structure, our conceptproposes an adaption of Scrum that is based on the gamedevelopment life-cycle: ABC-Sprints consist of three Sprintsto iteratively create Alpha, Beta and Completed versions ofa game. We present a detailed walkthrough of the courseand give results of a formal evaluation. These indicate thatABC-Sprints help students to manage their workload and toincrease productivity over time. Consequently, three teamseach presented a game at the end of the course that tech-nically exceeded typical outcomes of game projects withoutlectures. We hence encourage to apply ABC-Sprints to othercurricula and provide a set of recommendations.

Categories and Subject DescriptorsK.3.2 [Computers and Information Science Educa-tion]: Computer science education; K.8.0 [Personal Com-puting]: GeneralGames

General TermsDesign, Curriculum, Management

Keywordsgames, education, Scrum, curriculum, game development,XNA, team projects

1. INTRODUCTIONTeaching game development in Computer Science (CS) stud-ies is a challenging task. It involves a broad range of disci-plines and technologies (e.g. graphics, interaction, game de-sign, software engineering, arts). As a result, many coursesthat oer a whole game development process are intensiveor capstone projects (e.g. [5]). Other classes have been dis-tributed across multiple semesters [16] or are taught in paral-lel at separate departments [8]. Yet applying such solutionsto other institutions and their curricula may be dicult.

To t a game development course into one semester, previouswork recommends to choose between either giving a lectureor conducting a projectnot both [17]. Such projects typ-ically allow students to create a game but cover only fewtheoretical topics often related to brain storming (e.g. [3]).The focus on game creation is understandable, as makingtheir own game is what students motivates most [2]. In ad-dition, the game industry requires project experience andportfolio examples of self-created games, showing the ap-plicants high devotion and commitment [17]. Yet we feelthat theoretical knowledge on game production and design(e.g formalizing a concept into elements, such as objectives,rules, or game mechanics [7]) is crucial and should not bedismissed from academic courses.

According to these requirements, our challenge was to ta practical CS-based game development process and a setof game design lectures into a non-intensive course for onesemester (15 weeks). The weekly amount of time spent onthe practical part should not exceed 6-8 hours. This raisesspecial requirements for a structured process that supportsboth creativity and productivity in a team project. It shouldfurther allow for exible, self-controlled time and task man-agement that enables students to react on varying workloadin other courses or even projects.

To structure the practical part of a course as a game devel-opment process, we propose Scrum [21] as software develop-ment methodology. Scrum has been successfully adopted bythe games industry, allowing for high quality games to bedeveloped on time [12].

The following section identies practical industry needs tobe met by the game development curriculum. It discussesScrum as a possible solution and gives examples of previ-ous implementations. In section 3, we present a courseconcept combining lectures and project work by adoptingScrum through ABC-Sprints. Section 4 evaluates this de-sign through a walkthrough report and a quantitative sur-vey. Finally, we discuss these results, and provide a list ofrecommendations and best-practices.

2. GAME CURRICULUM AND SCRUMGame courses in CS education can be categorized in two ap-proaches: the rst category uses it as a motivation vehiclefor teaching CS topics, the second teaches development of agame per se. The latter can be further separated into gameprogramming and game development classes [22]. Game de-velopment class should cover a comprehensive list of topics(e.g. design, programming, business, production) [11].

These topics include facts and theoretical models to be ide-ally taught in lectures. However, many industry needs arebest met in practical projects, e.g. having worked on a self-contained project, having created a game that demonstratesthe applicants devotion and perseverance [17]. The threemost important management skills in this regard are an ef-fective communication with team members, the abilities tofollow processes and to meet objectives, and to transformrequirements and feedback into planned goals and action-able items [1]. Regarding process optimization in the gamesindustry, many studios propose applying an agile softwaredevelopment method to improve management of their gamecreation processes [12]: Scrum [23].

Scrum tries to empower small teams, thus placing the ScrumTeam in the center of decision making. Instead of imple-menting a project manager, a Scrum Master acts as inter-face between the Scrum Team and the Product Owner. TheProduct Owner denes the overall objectives in a ProductBacklog and is responsible for the commercial success of theproduct. The Scrum Master guards the team from outsideinterference during each development iteration, known asSprint. This makes the Scrum Team an autonomous or-ganization: The members can dynamically prioritize theirworkload in regard to the goals of a Sprint.

As a recent commercial example, the development of Forza3 reportedly became more predictable. Scrum helped to im-prove leadership among small teams through empowermentof individuals, and for the rst time in the studio history,they hit their schedule exactly on the day [10]. Anothermajor release, Left 4 Dead 2, was also completed on time.Scrum improved task prioritization in comparison to the pre-quel which was not developed using Scrum [15]. Other ad-vantages, according to the development team of Brutal Leg-end, are the emphasis on features over systems, on peopleover process, and on iterative design [4].

Opposed to that, the academic domain lacks such positiveexperiences. Gestwicki et al. applied Scrum in an interdisci-plinary project covering two parallel courses on game designand game programming. Yet, no hints were given on the im-pact of Scrum [9]. Fernandez-Vara and Tan applied Scrumto an eight-weeks summer course [6]. They did not recom-mend Scrum for short projects, rather for major softwaredevelopments. According to them, Scrum lacks guidelinesto deal with nalization of a product within a tight dead-line. As a result, the students had to go into crunch time forthe last two weeks and canceled using Scrum for this period.

Despite of these experiences, we applied Scrum to a lecturecourse as a software development method. We thus intend toallow for a complete game creation process next to a transferof theoretical knowledge. With regards to the previouslyidentied industry needs, we further expect Scrum to havea positive impact on the following aspects:

Teamwork is vital in game development. This aects com-munication, reliance, conict management, etc., thusevolving important soft skills.

Flexibility concerns the issue to react on changing require-ments in awareness of the general objectives.

Empowerment makes individuals more condent regard-ing their capabilities. Instead of a central decision in-stance, everyones competence has impact on decisionswhich results in higher motivation and commitment.

Productivity is crucial in respect to both the limited timeframe as well as to the comprehension of tasks to behandled in a game development process.

Playable prototypes accompany the game creation pro-cess, providing a concrete idea of how a product evolves,which features work, and which are missing.

3. COURSE DESIGNIn this section we propose a framework for a game devel-opment course design. This covers the course structure, itsschedule, constraints, and our adaption of Scrum: ABC-Sprints. Moreover, we illustrate the application of the de-sign to our Game Development course held in the winter of2009 at the University of Duisburg-Essen, Germany.

The two primary goals of the course design are to let stu-dents experience, rst, a theoretical lecture on game design,structure and production, and second, a near-to-professionalprocess of developing a game in a team that covers program-ming, game design, and agile development using Scrum.

3.1 Structure and ScheduleIt is vital to parallelize the theoretical and practical lecturethreads as good as possible. Thus, the participants are ableto deepen the knowledge gained in the lectures by practicalexperience and vice versa. To focus their limited workloadon developing game functionality rather than content pro-duction, we inform the students that we do not rate thequality of assets (e.g. graphics, 3D models, sounds), whichis dierent from other course designs [13].

The course covers one semester and consists of 15 weeks ofteaching. Based on the game development life cycle (Pre-production, Production, Testing) [11], we divide the courseinto a Design Phase (Pre-production) and a developmentphase (Production) that we call ABC-Sprints. We omitTesting as a separate phase and give an insight within theProduction phase.

Design Phase. The goal of the Design Phase is to groupthe students into Scrum Teams, each having a distinct gameconcept described in a Game Design Document (GDD). Thisis the basis for the Development Phase. A team comprisesfour to ve students as recommended by [24].

Before the rst meeting, the students write an applicationletter that describes their backgrounds, skills, and expec-tations regarding the course. These proles are intended tobalance the teams as recommended widely (e.g. [18]). In thefollowing meetings, several iterations of brainstorm sessionsare conducted. Each student has to create a high conceptout of a mind map. These ideas are then combined in groupdiscussions, thus the nal GDDs contain ideas from everyparticipant, thus they easily can identify with it. Beforeentering the rst Sprint, the teams create a Product Back-log based on the GDD. In consultation with the ProductOwner, the team members dene and prioritize the neces-sary features.

Table 1: Course Outline

Phase Activity Deliverables Week Lecture TopicsStart 1 Organizational Matters

Des

ign Idea Creation

Game Design Document, Product Backlog,Alpha Sprint Backlog

2 Genres, Innovation and IdeasGrouping 3 Production ProcessConception 4 Production Tools

AB

C-S

pri

nts

Planning 5 Project Engineering

Alpha SprintBasic Functionality, Proof of Concept,Beta Sprint Backlog

6 Structure of Games7 Gameplay and Balancing8 Interface Design9 M1 ALPHA VERSION

Beta SprintFeature-complete Game, Final Assets,Completion Sprint Backlog

10 Christmas Gaming Session11 Interactive Storytelling12 Character Development13 M2 BETA VERSION

Completion Sprint Bug-free, Balanced, Polished, and Finalized Game13 Code Review and Refactoring14 Games Business15 M3 RELEASE

ABC-Sprints. The development phase is subdivided intothree iterations: Alpha Sprint, Beta Sprint, and CompletionSprint. We hence call this outline of sprints ABC-SprintsDuring a Sprint, each Scrum Team is supposed to work auto-nomously and self-organized. Therefore, the teams mustprecisely determine their activities for the upcoming Sprint,to be acknowledged by the instructor. One student perteam, the Scrum Masters, regularly update the backlogs andprovide periodical status updates to the instructor. Theinstructor also monitors the log les of the versioning sys-tem. At the end of each Sprint, the students present theirprogress to the whole class. This concerns the Sprint goalsas well as utilization of Scrum. This way, the teams canexchange their experiences. At the end of the four-week Al-pha Sprint, the students should have developed a rst proto-type in which the games basic functionality is implemented.The prototype proofs the game concept, optionally indicat-ing necessary adaptions. During the four-week Beta Sprint,additional levels/enemies/tactics need to be realized, mak-ing the game feature-complete. The two-week CompletionSprint is for debugging, polishing and nalizing the assets.Table 1 shows this structure and gives an exemplary lectureoutline facing the practical phases and goals. The lecturebasis was own material in combination with [7] and [19].

3.2 Other Changes to ScrumUsing Scrum within a class curriculum requires modica-tions [20]. Due to the reduced work schedule, we proposeto replace daily Scrum meetings with meeting at least twicea week. In our design, the Sprint durations vary from two(Completion Sprint) to four weeks (Alpha and Beta Sprint).

Another adaption of Scrum concerns the roles. We proposea student taking the role of the Scrum Master despite beingpart of the Scrum Team. Other solutions are not feasible dueto a lack of resources. The instructor acts as Product Owner,with one exception regarding the creation of the ProductBacklogs: In industry projects, the publisher is the client ofthe game developer and as such the Product Owner. But,besides market-driven game concepts such as advertisementgames, the game ideas and rst prototypes are created bydeveloper teams rst and then pitched to a publisher. So the

functional requirementsand thus the Product Backlogcan only be dened by the Scrum Team (the students). Thisproposal then has to be acknowledged by the Product Owner(the instructor).

In addition to the Scrum meetings, all Scrum Masters meetwith the instructor once a week in a Scrum of Scrums. Inthese meetings, the instructor participates as such, not asProduct Owner. Thus, only communication problems, ortechnical issues are discussed, not the features itself. Aftereach meeting, the Scrum Masters report back to their teams.Table 2 summarizes the proposed changes.

3.3 Constraints and ToolsConstraints can help to manage a project, but usually thequality and creativity of games is higher without constraintsas more freedom induces more motivation among students[17]. One technical constraint for our course was to use Mi-crosoft XNA Game Studio 3.1 which has been successfullyapplied to several student courses (e.g. [13]), and we hadgood experiences in previous courses. Code managementshould be supported through versioning systems, such as

Table 2: Scrum Modications

Scrum ABC-Sprints

Team size 5-7 4-5

Sprint duration 30 days 2 to 4 weeks

Weeklyworkload

40 hrs 8 hrs

Product Backlogcreated by

Product Owner instructor andstudents

Sprint Backlogcreated by

Scrum Team Scrum Team

Scrum Master outside ScrumTeam

part of ScrumTeam

Scrums daily twice a week

Subversion or Git. Another constraint aects the game de-sign: To limit complexity, the games were restricted to 2D.Developing 3D games requires much more development ef-forts concerning aspects like modeling, texturing, collisiondetection, animation, and interaction without necessarilycontributing to a good and entertaining gameplay.

4. EVALUATING THE COURSE DESIGNWe evaluate the course design using two methods. We rstprovide a detailed walkthrough of our course during the win-ter semester 2009, in which thirteen students have partici-pated in total. The second part shows results of a quanti-tative evaluation. At the end of this section, we discuss theresults and formulate a set of recommendations for applyingthe course to other curricula.

4.1 Applying the DesignAWalkthroughIn the following, we provide detailed insight to each phaseof the course in chronological order.

4.1.1 Idea Creation in the Design PhaseThe Design Phase was a very fruitful period. The vari-ous ideas were collected and shaped up to dierent groupconcepts. A momentum appeared by which the studentsreached a common ground regarding their concepts and pro-actively formed three teams. We desisted from rearrangingthe students afterwards1 in order to keep the momentumalive.

The three teams (A,B, and C) iteratively created a highconcept and a game design document, pitching it to theProduct Owner who accepted the proposals, while request-ing changes. Especially Team B had to strip down their con-cept as it suered from feature explosion. The experiencealso helped the other teams on prioritizing their features forthe Product Backlog.

4.1.2 Alpha SprintDuring Sprint planning, all teams encountered problems indierentiating between features for the Product Backlog andthe more ne-grained activities to dene for a Sprint. Theirrst task sets were vague and separated in too large chunks,similar to the Product Backlog. Hence, the instructor gaveconcrete examples on how to create a set of manageabletasks. While this individual feedback was useful for twoteams (Team A and Team B), Team C still had problems.They hardly succeeded in regularly updating the Sprint Back-log, or in adopting requested changes.

During the Sprint, a new member entered the course. Hejoined Team C, which had the most problems at this pointof progress. The new member brought in experience in soft-ware development the team had been lacked so far. Thisled to a good redesign of their game concept, while keepingthe core concepta tower defense game. In the next updatemeeting, the Scrum Master reported that the new memberalso boosted the teams moral.

At the end of the Sprint, Team A reported an issue with net-work multi-player support. The feature had been requested

1originally, we planned to group the teams based on theirapplication proles

by the instructor in order to add more depth and lasting ap-peal to the gameplay. The team invested a great amount oftime in analyzing the requirements and consequences of sup-porting network gameplay. At the end of the Alpha Sprint,they expressed the wish to replace this feature as imple-menting it in a suciently balanced quality would threatenthe overall quality of the game. Together with the team,we assessed their technical problem and network support inXNA and chose to agree on the teams request. Gratefully,the team announced to invest the gained time in balanc-ing and in even creating new features that contributed tothe core gameplay. Although this issue caused some seri-ous discussions, it was easy to handle in terms of projectmanagement. The team updated the Product Backlog andderived the necessary activities for the Beta Sprint.

In the Sprint milestone presentations the students reporteddiculties on estimating the complexity of tasks. This wasto expect, since it was the rst Sprint for a new team workingon a previously unknown task. Moreover, all teams outlinedthe importance of regular communication and everyonescommitment to the project in order to work with Scrum.The Sprint Backlogs displayed a high but evenly distributedworkload among the teams during the rst Sprint. All teamsaccomplished their Alpha status within time, delivering abasically functional prototype.

4.1.3 Beta SprintDuring the Beta Sprint, all teams entered into crunch mode.While this being expected to happen in the CompletionSprint, all teams set very ambitious goals for the Beta Sprint.They intended to avoid crunch time during the CompletionSprint, especially in consideration of their other courses andthe exams on schedule at the end of the semester. Anotherreason for the early crunch time was the time consumingcontent creation. Although it was explicitly demanded notto spend too much time working on assets, all teams werevery enthusiastic on delivering also a good looking game.Some teams even tried to acquire external artists, but withmoderate success.

Regarding self-management, Teams A and B made exhaus-tive use of the Sprint Backlog and the Burndown Chart inorder to coordinate and rearrange their activities. They uti-lized these tools as a basis for discussion. Team C, however,moreover neglected these tools. They were rarely updatedand did not seem to reect the latest state of the game, alsocompared to the Subversion log les. The instructor dis-cussed these problems with the Scrum Master of Team C,leading to a meeting with the whole Scrum Team. It helpeda lot to talk about their communication problems. Obvi-ously, the new team member had taken over the programlead, implementing many features all by himself. Yet, hedid not use the Sprint Backlog for his activities and had thusundermined the Scrum Masters role. From that discussionon, the Sprint Backlog was updated more regularly and allparticipants consistently committed code to the repository.

In the Beta presentation, all teams stated an improved es-timation of eort, even Team C, but also complained abouta very high workload compared to other courses. Somestudents also faced technical issues, especially architecturalproblems, concerning their implementations. They requested

more guidance in how to structure software, since they haddiculties with adding or changing features in their existingcode structure. Other updates showed integration of contentfrom the accompanying lectures, e.g. Team B created theirdialogs and some characters based on concepts taught in thelectures during the Sprint. In the end, they all managed topresent a nearly fully functional prototype with improvedfeatures, a front-end with GUI and even extended assets.

4.1.4 Completion SprintIn the Completion Sprint, we provided a code review as wellas a lecture on refactoring. The students showed a highinterest in this topic, even further on in unit testing. As aresult, they recommended earlier integration of code reviewsin the course design. For polishing gameplay, the teamsinvited external beta-testers on their own initiative. Thus,they gained useful feedback on balancing the gameplay aswell as on existing bugs.

At the nal presentation, all teams successfully deliveredfully playable, feature complete prototypes. In their talks,Teams A and B vividly compared their Burndown Chartsacross the Development Phases. They could easily pin-pointproblematic phases or crunch time moments and were ea-ger to analyze their progress. In conclusion, they perceivedScrum as being very supportive through all phases of theproject with one exception: During the Completion Sprint,Team A primarily used their bug-tracker to maintain theirtasks, not the Sprint Backlog.

Opposed to that, Team C admitted that they hardly usedScrum except for the meetings. They used the Sprint Back-log as a short list of software requirements but did not reallyarrange their work according to the Backlog. They still up-dated the document according to their progress but ratherperceived it as documentation overhead.

All in all, the students seemed very pleased with their out-comes and proudly demonstrated their games to other vis-itors. One of the visitors, coming from Microsoft, was pos-itively surprised by the games qualities and recommendedone of the games for upload to their website covering inde-pendent games.

4.1.5 The Resulting GamesThe three dierent games (Figure 1) all looked great andwere fun to play. They ran smoothly and featured multi-ple levels that go far beyond prototypical demonstration ofa pure concept. Compared to games developed in previousfull-time projects, these games were more complex, oeringfully functional, much more polished, and balanced game-play. The most compelling aspect in our opinion was thatthe games actually reected their creators intentions. Theteams really liked their own games and were proud of them.To further improve the quality, polishing should focus onproviding more direct feedback to user interactions, as somecontrols were dicult to learn without instructions.

4.2 Quantitative EvaluationWe asked the participants to anonymously ll out a surveyfor the purpose of further improving the course in the fu-ture. All 13 students participated. We used four- and ve-level Likert-scales to assess the students experiences with

Scrum during the practical part of the course. The follow-ing evaluation provides analysis of results through median,arithmetic mean, and standard deviation; N = 13, if notstated otherwise.

Overall, the participants were very pleased with the project( = 1; = 1.31; = .63; with 1=very pleased to 4=veryunpleased) as with the project outcome: their own games( = 1; = 1.15; = .38).

Ten of the thirteen students (76.9%) had prior project ex-perience working in a group. Eight (61.54%) had previouslyheard of Scrum. Only one of the group had practical ex-perience with all Scrum components (Sprints, Scrum Meet-ings, Product Backlog, Sprint Backlog, Roles and BurndownChart). Two more had participated in a Scrum Meeting be-fore.

Generally concerning the contribution of Scrum methods tosuccess of a team project, we asked to rate the eectivenesson a ve-level scale, ranging from 1=very eective to 5=noteective. The students rated Scrum meetings as very eec-tive ( = 1; = 1.46; = .66). Separating a project intoSprints was perceived as eective ( = 2; = 1.85; = .80),as was using a Sprint Backlog ( = 2; = 2.54; = 1.13).The Product Backlog ( = 3; = 2.67; = 1.15; N = 12;),the roles ( = 3; = 2.57; = .62; N = 12), and the Burn-down Chart ( = 3; = 3.08; = 1.5) were regarded asneutral. The Burndown Chart caused the most inhomoge-neous ratings with half of the students regarding it neutraland the others equally distributed to both sides of the scale.

Regarding project work in general, we asked for a yes-/no-decision on which of the following aspects were importantto them. Twelve of thirteen (92.3%) each stated that team-work, individual responsibility, and structured planning wereimportant. Among those who had positively answered, wecollected forced-choice ratings regarding the game develop-ment project on a four-level scale. The students were verypleased with their teamwork ( = 1; = 1.33; = .49;N = 12; with 1=very pleased to 4=very unpleased). Indi-vidual responsibility within the team was rated high ( = 2; = 1.58; = 0.51; N = 12; with 1=very high responsibil-ity to 4=no responsibility). The project work seemed ratherstructured to them ( = 2; = 1.83; = 0.58; N = 12; with1=very structured to 4=very unstructured).

Inspired by [18] to identify the biggest problems in team-work, we further asked for the three most positive and threemost negative aspects related to their own teams. The mostmentioned on the positive side were even distribution of workamong team members, mutual motivation and support. Onthe negative were communication problems and lack of dis-cipline or attitude among team members, further on orga-nizational issues. One other aspect was the workload whichwas commented to be very high compared to other courses.

The students rated their workload and productivity dis-tributed over the Design Phase and the three Sprints onforced-choice four-level scales. The workload was low in theDesign Phase ( = 2; = 2.77; = .93; with 1=very lowto 4=very high) but very high during the Alpha ( = 4; = 3.77; = .44) and Beta Sprints ( = 4; = 3.69;

(a) Game A: A four-player arcadegame using slingshot interactionon asteroids.

(b) Game B: A side-scrolling adventure featur-ing a dramatic story on ve dierent rotatingplanets.

(c) Game C: A tower defense game with adynamic playground of moving asteroids.

Figure 1: The games created during the ABC-Sprints.

= .63). The Completion Sprint shows still a high work-load ( = 3; = 3.15; = .62) but lower than the previousSprints. Conducting a non-parametric Friedman-Test con-rms a signicant statistical dierence between the phases(2 = 14.663; df = 3; p = .002). Asked about the workloadof the project in total, the students rated it very high ( = 4; = 3.85; = .38).

Correspondingly, their productivity was rated as very highduring the whole project ( = 1; = 1.15; = .38; with1=very productive to 4=very unproductive). Across thephases and sprints, the ratings indicate a slight increasein perceived productivity from the Design Phase ( = 2; = 1.69; = .48) and the Alpha Sprint ( = 2; = 1.62; = .51) to the Beta ( = 1; = 1.31; = .48) and theCompletion Sprints ( = 1; = 1.42; = .38). Accordingly,a Friedman-test shows a trend in signicance (2 = 6.556;df = 3; p = .087; N = 12).

Looking back to their previous university projects, the stu-dents, now used to Scrum, were asked if Scrum would haveimproved those projects. Their ratings on a four-level scale(1=signicant improvement to 4=none at all) indicate thatthese projects would have had rather beneted from adopt-ing Scrum ( = 2; = 2.10; = .99; N = 10;). Further on,regarding the choice on participating in future courses us-ing Scrum, the Students rated positively on a ve-level scale( = 2; = 2.15; = .99; with 1=yes, sure to 5=no way).The vast majority, 72.7% (N=11), would even use Scrum infuture projects on their own initiative.

4.3 DiscussionAs a major success, the proposed course design enabledthe participants to develop their own playable and balancedgame during a lecture course. The participants gained com-prehensive practical experience in game development butalso in setting their own goals and following them througha plan, and to take responsibility in being part of a self-controlled team.

4.3.1 ScrumWe think that Scrum has strongly contributed to the projectoutcome and both ratings and comments arm this impres-sion. Mapped onto a stripped version of the game develop-ment life-cycle, the ABC-Sprints provide a decent frame forself-deployed game development in a student team. Moststudents also know the concept of alpha and beta versions

from commercial products and like this paradigm. Theyprovide clear goals for them. Further on, it was very helpfulto always have a running prototype with a functional alphaversion by half of the semester and we strongly recommendto follow this iterative approach.

Monitoring the project through Burndown Charts and ver-sioning log les allowed easy supervision for the instructorand for the team members. Though, not all teams alwaysmaintained their logs. Especially Team C had problems up-dating their Backlogs and, as a result, did not use it. So, toapply Scrum even more consistently requires that all teammembers, particularly the Scrum Master, is trained in usingScrum. In unbalanced teams a member who signicantlyoutperforms the others, should act as Scrum Master or atleast actively support using Scrum.

4.3.2 Lecture ContentRegarding the content of the lectures, we managed to nd asequence of topics that corresponds quite well to the gamedevelopment process. Yet, not all content needed can be pro-vided before the Sprints start. Thus, some students wouldhave preferred to have more lectures at the beginning of thecourse. This would provide further insight on the game de-velopment process and leave more time during the semesterfor practical work. From our point of view though, the ideacreation phase should not be overloaded to still allow for acreative process. We also feel that the weekly lectures pro-vide a rhythm for meeting with the whole group that sup-ports the overall structure of collaboration. We intend oneadjustment regarding teaching game interaction: we wouldrecommend to emphasize more on interactive feedback dur-ing the beta sprint as some game features were dicult tolearn without instructions.

4.3.3 WorkloadOne main issue according to both comments and the evalua-tion was a very high workload. Of course, the ability to han-dle high workload is a success criteria in the games industry.Previous research highlights industry demands for devotedstudents, who have proven the right attitude and persever-ance, even spent their own time on creating a game untilnished [14, 17]. Moreover, the instructor had announced ahigh workload at the beginning of the course. Despite thecourse being optional for most participants, no one left thecourse during the semester which we consider an enormoussuccess, taking the high workload into account.

However, besides a lecture course, students have to fulllother obligations. Creating a game tempts to leave othertasks unnished, rather focusing on content creation (whichwas announced not to be rated). In order to reduce work-load there are two options: One is to further reduce the con-cepts and their features which the Product Owner alreadydid by up to 80%. The second is to externalize contentcreation or to oer pre-created content from web-databases.Still, though, workload always remains high with the spiritof a teamwhich was great among our group. Even better,the workload went back down during the Completion Sprintwhich is the opposite of what we expected and of what weexperienced in other courses. The ABC-Sprints seem to havesignicantly improved planning over time. This is also indi-cated by the slight increase in perceived productivity acrossthe course duration.

4.3.4 Adaption to Other CurriculaWe intend to provide a basis for establishing more gamelectures in other curricula based on ABC-Sprints. The pro-posed course design ts in one semester while providing boththeoretical background and practical experience on develop-ing a game. Based on the preceding evaluation, we providethe following recommendations for adapting the course de-sign:

Design Phase

Grouping is a dynamic process where the game andthe motivation for a certain concept is more importantthan balancing skills among team members.

Iterative planning from high concept to GDD and fur-ther into the Product Backlog requires a loose guid-ance, best given by example.

To maximize motivation it is crucial that all teammembers agree on a common vision and identify withthe game.

Regarding software engineering, students may requireearly guidance on how plan the structure of game ob-jects and game components.

Alpha Sprint

The main goal is getting used to Scrum (especially us-ing Backlogs and Burndown Charts) and establishingregular communication.

This Sprint is in danger of a too rough planning, asstudents tend to underestimate the complexity of theirtasks.

Early code reviews and providing support on architec-tural problems can help on the development side.

Beta Sprint This Sprint planning might be over-detailed in order

to compensate aws from the Alpha Sprint.

Content creation is a time-consuming task, studentsare in danger of creating assets beyond the feasible.

The beta version should be played by external testersbefore the end of the Sprint to allow integration offeedback into the Completion Sprint planning.

Completion Sprint

Bug-tracking can be supported with appropriate soft-ware tools. It should still be maintained as a task inthe Sprint Backlog.

The nal presentation should be open to visitors, es-pecially from the industry, creating a release event.

Announcing such an event or popular guests duringthe semester has a positive impact on motivation. Thisshould be saved for dicult moments.

Overall

The proportion of 4:4:2-weeks for the ABC-Sprints de-nes a structure and leaves enough freedom for indi-vidual responsibility. Other proportions might t aswell, but we recommend neither having less than threeSprints nor to have more two-week Sprints. LongerSprints help to build the team.

Not every student makes a good Scrum Master. As therole might be misinterpreted (e.g. as leader who givesorders), switching roles between Sprints could providea solution.

Constant reviews of documentation and giving feed-back on managing Backlogs is crucial.

Further integration of agile software development meth-ods such as Test Driven Developments should be con-sidered.

Interactive feedback on user input is important forgameplay which is often not realized by students. Theyshould learn about this before the Beta Sprint startsin order to adjust the Completion Sprint.

Lectures and practical phases could be re-arranged.They should consider holiday seasons or other events.

5. CONCLUSIONSIn this paper we presented a course design that allows apractical game development project within a regular gamedesign lecture course, resulting in a fully playable game. Asdescribed, this approach requires a consistent structure forallowing both ambitious teamwork and exible time man-agement. As a solution we propose ABC-Sprints, an adap-tion of Scrum that is based on the game development life-cycle.

We successfully conducted a course using this design. Threeteams could each present a decent, well-functional game atthe end of the course. They reported a very high workloadbut were very pleased with the course as with the outcome.

Scrum, despite being used for the rst time of most of thestudents, was easily applied. The majority even would useit in the future on their own initiative. For future itera-tions, we plan to move coding and refactoring issues to therst phase and oer additional training on using the SprintBacklogs and the Burndown Charts before the DevelopmentPhase starts. To strengthen the role of the Scrum Master,we consider switching roles between the Sprints.

To conclude, ABC-Sprints allow easy integration of Scrumin student game development projects. They provide a fea-sible structure that cultivates both individual responsibilityand communication in a small team, resulting in exible andgoal-oriented teamwork. The ABC-Sprints help students todevelop their planning skills through multiple iterations ofmanaging high workload, thus improving productivity. Pro-viding that the students are supported in applying Scrum,we highly recommend to use ABC-Sprints in other gamedevelopment projects, even ifas in our casethey are nointensive full-time projects.

6. ACKNOWLEDGEMENTSMany thanks go to the participants of the course at the Uni-versity of Duisburg-Essen: Team Mario, Team Luigi, andTeam Yoshi.

7. REFERENCES[1] Q. Brown, F. Lee, and S. Alejandre. Emphasizing Soft

Skills and Team Development in an EducationalDigital Game Design Course. In Proc. of the FDG09,pages 240247. ACM, 2009.

[2] D. Cliburn and S. Miller. Games, Stories, orSomething More Traditional: The Types ofAssignments College Students Prefer. In Proc. of the39th SIGCSE Technical Symposium on CS Education,pages 138142. ACM, 2008.

[3] S. Duvall. Creating a Games Class: A Walkthrough.In Proc. of the FDG09, pages 279284. ACM, 2009.

[4] C. Esmurdoc. Postmortem: Behind The Scenes OfBrutal Legend, 2009. http://www.gamasutra.com/view/news/25799/Postmortem_Behind_The_Scenes_

Of_Brutal_Legend.php, last access: 04.02.2010.

[5] A. Estey, A. Gooch, and B. Gooch. AddressingIndustry Issues in a Multi-Disciplinary Course onGame Design. In Proc. of the FDG09, pages 7178.ACM, 2009.

[6] C. Fernandez-Vara and P. Tan. The Game StudiesPracticum: Applying Situated Learning to TeachProfessional Practices. In Proc. of the Conf. on FuturePlay08, pages 2532. ACM, 2008.

[7] T. Fullerton. Game Design Workshop, Second Edition:A Playcentric Approach to Creating Innovative Games(Gama Network Series). Morgan Kaufmann, 2008.

[8] P. Gestwicki, F. Sun, and B. Dean. Teaching GameDesign and Game Programming ThroughInterdisciplinary Courses. Journal of ComputingSciences in Colleges, 24:110115, 2008.

[9] P. Gestwicki and F.-S. Sun. Teaching Design PatternsThrough Computer Game Development. Journal onEducational Resources in Computing (JERIC), 8,2008.

[10] K. Graft. Racing Evolution: Forza 3 and the ChangingDriving Sim.http://www.gamasutra.com/view/feature/4144/

racing_evolution_forza_3%_and_the_.php, lastaccess: 04.02.2010.

[11] IGDA. IGDA Curriculum Framework: The Study ofGames and Game Development, 2008. http://wiki.igda.org/images/e/ee/Igda2008cf.pdf, lastaccess: 04.02.2010.

[12] C. Keith. Scrum Rising. Game Developer Magazine,2007. http://www.agilegamedevelopment.com/Articles/ScrumRising.pdf, last access: 24.01.2010.

[13] J. Linho and A. Settle. Teaching Game ProgrammingUsing XNA. In Proc. of the 13th Annual Conferenceon Innovation and Technology in CS Education,volume 40, pages 250254. ACM, 2008.

[14] M. M. McGill. Dening the Expectation Gap: AComparison of Industry Needs and Existing GameDevelopment Curriculum. In Proc. of the FDG09,pages 129136. ACM, 2009.

[15] C. Nutt. Q&A: Valves Swift On Left 4 Dead 2sProduction, AI Boost. http://www.gamasutra.com/view/news/25701/QA_Valves_Swift_On_Left_4_

Dead_2s_Production_AI_Boost.php, last access:04.02.2010.

[16] I. Parberry, M. B. Kazemzadeh, and T. Roden. TheArt and Science of Game Programming. ACMSIGCSE Bulletin, 38:510514, 2006.

[17] I. Parberry, T. Roden, and M. Kazemzadeh.Experience with an Industry-Driven Capstone Courseon Game Programming: Extended Abstract. ACMSIGCSE Bulletin, 37:9195, 2005.

[18] H. Pournaghshband. The Students Problems inCourses with Team Projects. In Proc. of theTwenty-First SIGCSE Technical Symposium on CSEducation, volume 22, pages 4447, 1990.

[19] A. Rollings and E. Adams. Andrew Rollings andErnest Adams on Game Design. New Riders Group,2003.

[20] D. Sanders. Using Scrum to Manage Student Projects.Journal of Computing Sciences in Colleges, 23:79,2007.

[21] K. Schwaber. Scrum Development Process. InOOPSLA Business Object Design and ImplementationWorkshop, volume 27, pages 1019, 1995.

[22] K. Sung. Computer Games and Traditional CSCourses. Communications of the ACM, 52:7478, 2009.

[23] J. Sutherland and K. Schwaber. The Scrum Papers:Nuts, Bolts, and Origins of an Agile Process, 2007.

[24] U. Wolz and S. M. Pulimood. An Integrated Approachto Project Management Through Classic CS III andVideo Game Development. In Proc. of the SIGCSE07, pages 322326. ACM Press, 2007.

IntroductionGame Curriculum and ScrumCourse DesignStructure and ScheduleOther Changes to ScrumConstraints and Tools

Evaluating the Course DesignApplying the DesignA WalkthroughIdea Creation in the Design PhaseAlpha SprintBeta SprintCompletion SprintThe Resulting Games

Quantitative EvaluationDiscussionScrumLecture ContentWorkloadAdaption to Other Curricula

ConclusionsAcknowledgementsReferences