You are on page 1of 6

MIPRO 2014, 26-30 May 2014, Opatija, Croatia

Agile Management: A Teaching Model

Based on SCRUM
. Pogaj*, N. Vlahovi* & V. Bosilj-Vuki*

Ekonomski fakultet Zagreb, Trg. J. F. Kennedyja 6, Zagreb, Croatia;;

where different roles are assigned to different actors,

specific artefacts are used, respective activities and
iterations. From presenting theoretical knowledge in the
first Scrum, through presentation of practical knowledge
and skills during the development of student projects in
the second Scrum, until the finalisation of the teaching
process with the student exams in the third Scrum.
Students work on their projects in accordance to agile
pairprogramming, presenting features as stories, weekly
meetings, etc.)

Abstract Work presented in this paper is based on the

notion of creating a teaching model based on the principles
of agile management. Developed and described model is
based on Scrum, one of the most widespread agile methods.
Since Scrum is primarily a framework for managing
software projects and software applications development,
during the development of the model it was crucial to
negotiate the differences between Scrum and the teaching
process itself. Teaching model in this paper covers the whole
teaching process from first lessons to the final exam. Model
consists of three separate units: (1) presentation of
theoretical knowledge; (2) practical knowledge and student
projects; (3) exams and admission of grades. Each of these
units represents a Scrum that results with particular
products. Basic characteristics of Scrum like incremental
development, iterations, roles and artefacts are implemented
in the teaching model using the same principles as in the
original Scrum even though their content is adjusted to the
specifics of the teaching process. Model is implemented in
the Managerial Informatics master study course Business
Application Development at the Faculty of Economics and
Business University of Zagreb.


Review of current literature indicates several attempts

of implementation of Scrum in the teaching process. In
most of the available cases Scrum is implemented only in
the segment of the teaching process concerned with the
organisation of student projects. As expected, courses
where Scrum is used in this way usually cover the topic of
software engineering [10]; [5] even though there are a few
examples of using Scrum in courses dealing with other
topics [4]; [1 ]; [6].
The rest of the paper is organised in five separate
chapters. After the introduction, in chapter 2, Scrum
methodology is introduced with descriptions of its basic
characteristics. Chapter 3 is the central part of the paper
where developed teaching model based on Scrum is
described in detail.
Chapter 4 indicates possible
improvements of the organisation of the teaching process.
Finally, Chapter 5 summarizes the key points in the


One of the topics within the curriculum of the course

Business Application Development (cro. Razvoj
Poslovnih Aplikacija) is Agile software development
methods. In order to familiarise students with knowledge
and skills within this topic more closely, we intended to
organise the teaching process according to principles of
agile management. The selected method was Scrum.
Scrum represents a framework for software product
development. Final goal of Scrum project is to create a
product that complies with intended requirements.
Teaching process aspires to reach the same goal as a
Scrum project. Project, in this case, pertains to the
organisation and conduct of the teaching process in
current academic year according to requirements defined
in the curriculum of the course, with the final goal
successfully complete teaching year. Analysis of teaching
process in described manner has shown that teaching
process can be compared and affiliated with any other
process, even with software development process. Scrum
is a typical software product development method.
Characteristics of the method are described in detail in this
paper through the presentation of the proposed teaching
model. Teaching model is achieved through three separate
Scrums; each Scrum containing three phases. Teaching
process is developed in the same way as software product
using all the stages of the software process life-cycle,



The emergence of novel, so-called lightweight agile

software development methods, evolved in the mid-1990s.
The main characteristics of agile software development
methods are iterative and incremental development,
agility, flexibility in requirement definition, collaboration,
self-organizing teams etc. Creators of these methods join
the Agile Movement that publishes Agile Manifesto in
2001. Agile Manifesto details the philosophy and
principles behind agile methods [8]; [9].
In 1995 Ken Schwaber and Jeff Sutherland present a
study where they describe a new software development
method and call it Scrum. The term scrum is derived from
rugby, where a scrum restarts the game after the ball has
gone out of play. Applying the interpretation of the term
scrum to software projects, a software scrum gets the team


back together and gets everyone moving in the appropriate

direction [1].

course, from the introductory lectures until the final exam

and admission of the grades. Three separate integral units
were detected: (1) presentation of theoretical knowledge;
(2) mastering practical skills through student projects; (3)
exam and admission of grades. Each of these units
represents a separate Scrum process and each of these
deliver a specific outcome - product or several products.
Consequently, teaching model for the Business
Application Development course consists of three Scrums,
or three Scrum units.

For Schwaber and Sutherland [7] Scrum is a process

framework that has been used to manage complex product
development. It is not a process or technique for building
products; rather, it is a framework within which one can
employ various processes and techniques. Speaking in
terms of agile management, Cervone describes Scrum as
an agile, lightweight process for managing and controlling
software and product development predicated on a teambased approach [2]. It consists of three groups of phases:
Pregame, Game (or Development) and Postgame (Fig. 1.).

A. About the course

Course Business application development is an
elective course in Managerial Informatics master study at
the Faculty of Economics and Business University of
Zagreb. This elective course consists of 20 hours of
teaching (10 hours of lectures and 10 hours of practical
work in computer lab). During the course students use
software tools for UML diagrams, eDraw UML Diagram,
and programming language Visual Basic, Visual Basic
2010 Express Edition. Workload of the course is
expressed using European Credit Transfer and
Accumulation System (ECTS) and the course is worth 4
ECTS credits. As we can see the number of course hours
is relatively small and the number of ECTS credits is quite
substantial, students are expected to work in teams outside
the supervised part of the teaching process. Therefore
students have additional time reserved for their
independent teamwork in the computer lab, and they can
choose from three different two-hour periods during the
week. Teaching is provided by two lecturers, one for the
theoretical topics and the other one for the practical part of
the course. In the academic year 2013/2014, 33 students
chose this elective course. They were allowed to organise
themselves into working teams and, as a team, negotiate
and define their project assignment topics.

Detailed description of activities and artefacts in each

phase of Scrum is given in the rest of the paper.
According to 7th Annual State of Agile Development
Survey for 2011. 54% software developers use Scrum.
Scrum together with Scrum variants methodologies is
used by 72% of software developers which makes Scrum
the most popular agile methodologies being used [12].


Teaching is a process, teaching process is a project.

Every project, including teaching projects, has its own
respective goal (for teaching projects, according to the
curriculum, the goal is to provide students with particular
knowledge and enable them to master particular skills), its
starting point and its ending point (during the semester).
Complex projects, such as teaching project, require
teamwork, mutual collaboration and cooperation. This can
be seen through the relationship of teachers and students.
Following the ideas of agile approach to project
development, Scrum methodology was used for the
creation of the teaching model for the Business
Application Development course.
Due to undeniable differences between teaching
process and software process Scrum methodology had to
be adjusted accordingly. First of all, every Scrum
represents a complete wholesome processing unit that
results with a particular product. This methodology is to
be used to cover the complete teaching process of the

Figure 1.

B. Roles, sprints and artefacts in the model

Basic roles in the teaching model are Scrum Master
and Scrum Team [7]. Teacher takes on the role of the
Scrum Master. Scrum Master is the person responsible for
the entire Scrum process and in this case Scrum Master is
responsible for the realisation of the complete teaching

The Scrum phases [3]


process. This is why the role of Scrum Master includes the

organisation of lectures and exercises, student
consultations, advising students during project assignment
topic selection, monitoring student progress and providing
additional help during the development stages of student
project assignments, grading of completed projects
assignments, preparation and conduct of examinations,
admission of grades, and so on. Role of Scrum Team is
assigned to each student team. Students form teams by
themselves and together as a team define project
assignment topic. They delegate particular tasks among
themselves during the development of the project, they
communicate and consult with the Scrum Master, they
observer the deadlines, write project documentation and
present the project work when done. Role Product Owner
is assigned to the team leader. Since student teams for the
course Business Application Development consists of
only two member, this role is not intended in this
particular teaching model. In teaching processes where
this role exists, Product Owner coordinates teamwork,
takes care about the details pertaining to the project
development progress and communicates with the Scrum
Master. Product Owner represents the middleman between
team members and Scrum Master. Soria et al. [10]
recommend introduction of the additional role of Agile
Coach in situations where students develop projects.
According to [10] the Agile Coach encourages the teams
throughout the Scrum process by cleaning the team's
obstacles and emphasizing the use of tools. Designated
Agile Coach represents the middleman between team
members and Scrum Master and this role would be
appointed to the lecturer that delivers the practical part of
the course topics and exercises conducted in the computer.
Sprint represents a set of activities that are sequentially
executed during each iteration of the development phase.
In the teaching model, types of activities that will form
each sprint are directly dependent on the Scrum unit the
sprint cycle belongs to. For example, in the first Scrum
unit activities within the sprints pertain to elaboration of
theoretical knowledge about the topics of the course. In
the second Scrum unit activities within the sprints follow
the stages of the life cycle of the software product
Artefacts of the teaching model are specifically related
by their content to the Scrum unit within which they are
used. For example, in the first Scrum unit Product
Backlog list, and later on Sprint Backlog list also, relate to
requirements defined by the process of studying the
theoretical knowledge about the topics of the course,
while in the second Scrum unit both Product Backlog and
Sprint Backlog lists relate to requirements defined by the
project assignment topics i.e. particular software product
being developed by the team. Project Topic Registration is
also an artefact that is submitted by the student teams to
the Scrum Master and it is only used in the Postgame
phase of the first Scrum unit.

from students during the teaching process. Activities

defined for the first Scrum unit are providing students
with the information about the course, presentation of
theoretical knowledge about the topics of the course and
preparation of students for the upcoming phases of the
process. Key artefacts of this phase are Planning, Product
Backlog list, Environment Architecture. Activities
associated with the mentioned artefacts are performed by
the Scrum Master. Artefact Planning involves creation of
the teaching process agenda (possible innovations in the
selection of the course topics in relation to the existing
curriculum, determining scope of lectures for each topic
by dates, planning the dates of midterm test and
examination tests, defining methods of examination,
determining primary and additional literature, determining
dates for computer lab exercises, selection of software
tools that will be used, and so on) Product Backlog list
contains features important for lecturer and students. So
Product Backlog list contains each topic title, each weekly
date for each lecture and corresponding topic that the
lecturer will present, dates for the exam tests, instructions
for the submission of student project assignment topics,
deadlines for each activity, and similar information.
Environment Architecture defines the required
presentation equipment, lecture room features, computer
equipment and corresponding software that is required
during computer lab exercises and project development.
Game phase in the proposed teaching model spans
over five weeks and in this period the teacher presents all
of the theoretical knowledge topics as defined in the
curriculum of the course. Product Backlog list is the basis
for the creation of the Sprint Backlog list. Sprint Backlog
contains a list of tasks to be completed during the Sprint.
This is an ordered list of topics that the lecturer needs to
present and they follow the stages of the software product
life cycle. As topics are presented students gain required
knowledge to be able to come up with project assignment
topic for their own software product prototype during the
second Scrum unit. List of basic and fundamental topics is
enriched with topics such as software project
management, software product quality metrics, and so
on List of tasks in Sprint Backlog that are to be
completed by the students includes forming of project
teams, completion of the Project Topic Submission forms,
and similar activities.
Central part of this phase is dedicated to Sprints, i. e.
incremental approach to completion of the tasks given in
the Sprint Backlog list during separate iterations. Since the
final number of hours of lectures for this course is ten, and
there are two hours of lectures per week, model presumes
five Sprints (5 x 2 hours). Each Sprint deals with one
lecture. With the end of each Sprint, teaching process
advances its progress in accomplishing the goals given in
the Sprint Backlog list. Each lecture starts with the weekly
meeting. The meeting agenda includes revision of topics
presented on the previous weekly meeting, introducing
students with the basic characteristics of the topic (or
several topics) that will be presented during lectures and,
finally, students get assignments for activities they should
perform until the next weekly meeting (familiarise
themselves with the content of a particular paper, retrieve
particular information using Internet and similar). Fifth

C. First Scrum Theoretical introduction

Pregame phase contains activities that will enable
students to participate in the upcoming Scrum units of the
teaching model while successfully accomplishing and
meeting the requirements that are continually requested


Sprint is different from the previous four since the

location of the lecture is not in the lecture room but in the
computer lab. Topic of this print is the modelling of
business processes so the theoretical foundations are
complemented with the drawing of particular UML
diagrams using appropriate software tools.

Game phase consists of five Sprints. After first three

Sprints students were able to master the basics of
programming and acquired required skills they are ready
to start with the development of their projects. Final two
weeks of the semester are allocated for the development of
the projects, which corresponds to the last two Sprints of
the teaching model. Scrum Teams have absolute
autonomy over the organisation of their work on the
projects, but within the limitations set by the rules of
Scrum. This means that Scrum Teams compile their Sprint
Backlog lists, define activities for each Sprint, define
goals of each Sprint, delegate work tasks among team
members, estimate timing and deadlines for particular
Sprint activities, and so on Since the amount of lecture
hours in this period is reasonably small, Scrum Teams
spend additional time and effort doing teamwork outside
Sprint teaching model. This is why weekly meeting have
pronounced importance during these two Sprints, since
Scrum Teams report their progress from the previous
week to Scrum Master. They report of what has been
achieved in the previous period but also activities that they
have planned for the next Sprint. This allows Scrum
Master to follow the dynamics of the project development
for each Scrum Team, giving them appropriate advice for
the next Sprint, and so on Each Scrum Team develops
their project according to requirements given in the Sprint
Backlog list, consequentially through the activities of each
Sprint (Analysis, Design, Evolution, Testing, Delivery),
iteratively using adequate number of Sprints and
incrementally until all of the requirements are reached and
the final version of the software product is developed.

After all of the items from the Sprint Backlog list are
achieved, final phase of the Scrum unit begins Postgame
phase. For the lecturer this means that all of the required
topics have been presented to the students. For the
students that means that project teams are created, project
topics determined and Project topic registration forms
completed and submitted to the Scrum Master.
D. Second Scrum Practical skills
Second Scrum unit of the teaching model is the most
similar to typical Scrum that is originally defined as agile
software development method. Since during second
Scrum unit students develop their own software
applications, Scrum is used as a framework for managing
software applications development. Students develop their
applications using Microsoft Visual Basic 2010 Express
edition. Exercises are performed exclusively in the
computer lab. Even though the primary part of this Scrum
unit is dedicated to the development of software
applications, basic information about programming in
Visual Basic as well as the tutorial for the usage of the
Integrated Development Environment is also covered.
This is why in the Game phase during first three Sprints
students are provided with necessary theoretical
information after which exercises are performed using
typical problem assignments that are similar to
requirements in their project topics. Final two Sprints are
dedicated to project work and the development of the
software applications themselves.

Organisation of the work done during student projects

is aligned with the recommendations of agile development
of software products [9] and Extreme Programming (XP)
[8]. Some of these recommendations include pairprogramming and pair- process modelling using drivernavigator approach [11], writing stories (describing
features and requirements) within the Product Backlog list
and weekly meetings.

In the beginning of the Pregame phase activity plan of

the second Scrum unit is created. Product Backlog list is
updated with the agenda of the practical part of the
lectures. During planning Scrum Master is involved with
defining the dynamics of presentation of programming
basics by the topics and particular dates, defining practical
examples of case studies related to specific lecture topics,
defining required perquisite knowledge required for
successful mastering of particular programing problems,
defining deadlines for student projects and so on Since
in the previous Scrum unit 18 student teams submitted
Project Topic Registrations, in the Product Backlog list
only teams and their topics are entered in order to track
basic features of student projects. This is why each Scrum
Team compiles its own internal Product Backlog list. In
these lists features of the software projects being
developed are entered as well as corresponding

In the Postgame phase Scrum Teams continue their

work by creating and compiling project documentation.
Project documentation contains detailed description and
disposition of the project assignment topic, UML
diagrams (namely, decomposition diagram, use-case
diagram at the system level, activity diagram and
sequence diagram for a particular segment of the software
product that was developed as a prototype), description of
basic functionalities and characteristics of the software
application, description of user interface, source code,
course of testing activities, and final conclusions. Integral
part of the project documentation that Scrum Teams attach
to the documentation itself is the software product in both
source code and executable form. All of these are
submitted to the Scrum Master.

As mentioned earlier during the first Scrum unit,

requirement for the particular software tools is defined as
artefact in the Environment Architecture. Now, the testing
of the installed computer resources is performed, and
possible corrections are made if needed. When the final
verification of the computer equipment is successful
Game phase is ready to commence.

E. Third Scrum Examination

Third Scrum represents the finale of the complete
teaching process. By this Scrum everything that was set
out by the curriculum of the Business Application
Development course is completed. All of the topics given
in the curriculum are presented, practical part of the
course in the computer lab has been completed as well,


Scrum Teams have developed their software applications

along with the appropriate project documentation and they
have submitted the resulting work (project documentation
and software applications) to Scrum Master. The last thing
that remains in the teaching process to complete the
course is the organisation and realisation of the
examination. Third Scrum is concerned with examination
on a particular date that is carried out as one complete
unit. Final product of this Scrum for the Scrum Master is
the conclusion of the exam date (project assignments are
graded, exam is conducted, grades are registered) and for
the students, grades are admitted in their indexes while the
course Business Application Development has been
successfully passed.




The presented teaching model introduces a number of

advantages and benefits for the students but it also faces a
few challenges that need to be overcome and allow for
improvements. Limitations of the model do not influence
the structure of the teaching model but influence the
suboptimal improvement of the teaching process quality.
Some of the most prominent limitations are:
Restrictive number of hours of lecture and exercises
for the rich content of the course topics defined by
the curriculum
Limited background knowledge of the students that
take this course that may require additional effort
from the students to successfully finish their project

Pregame phase
In the Product Backlog list main properties for the
examinations are registered: planned date of the
examination, requirement that students that want to take
the exam need to register for it, requirement that students
need to have their index with valid entry noting that they
have applied for the course in the beginning of the
academic year. One of the most important artefacts that is
entered in the Environment Architecture is the list of
rooms that are reserved in the appropriate time when the
examination is planned to take place. The method of
publishing examination details is organized at the level of
the Faculty and thus is not a part of the model.

Relatively small number of students that creates

challenges while forming student teams.
In order to improve the quality of the teaching process
and resolve at least some of the limitations for the
Business Application Development course an increase of
the number of hours was proposed. From the current 20
hours additional 10 hours were suggested. This proposal
was accepted by the Faculty bodies, so the next academic
year there will be 10 hours of lectures reserved for the
theoretical introduction to the course topics and 20 hours
allocated for the practical part of the course that covers the
development of student projects as well.

Game phase
Sprint Backlog list contains the information about the
exam date, including precise time and place where the
exam will take place, as well as the list of students that
have applied for the examination. Duties of the Scrum
Master at this point are to compile exam questions and
exam tests and prepare adequate number of test. Students
are expected to take the test at the published date, time and
place of the exam, while providing their indexes for
Since the model covers only one exam date, Game
phase consists of only one Sprint cycle. Sprint lasts for a
predetermined time period after which students submit the
completed tests and after Scrum Master grades the written
exams, students that have achieved minimum
requirements and passed the test continue with the
Postgame phase of the Scrum unit. Rest of the students are
returned to the Pregame phase of this Scrum unit and are
referred to the next exam date as it becomes available.
Postgame phase
In this phase for the students that have successfully
passed the written exam Scrum Master calculates the final
grade for the course where the final grade is structured as
follows: 50% of the final grade is made from the grade of
the written exam, 40% is contributed by the project
assignment grade and the final 10% is contributed by the
student activity during the course. The final grade is
admitted in student index and registered in the exam list of
the Faculty Information System.


Next possible improvement pertains to the

organisation of student project topics. The key idea here is
that entire generation of students would develop the same
complex software application and all of the Scrum Teams
would make their contributions. They would still be
independent self-organising and self-managing, but each
Scrum Team would have 3 to 5 members. The project
assignments would be given by the Scrum Master to the
Scrum Team leaders. Scrum Team leaders would be
assigned with the role of Product Owner according to the
model described earlier in this paper, and each Product
Owner would be assigned one segment of the software
application that would be developed my their respective
Scrum Team. The only restricting factor in this case
would be the complexity of the student projects since
there is limited background and prior knowledge of the
students about course topics and programming. This
limitation can be somewhat alleviated by the increased
number of hours of practical work in the computer lab and
Visual Basic.


Paper clearly shows how teaching process can be

customised according to methodology initially planned for
realization of completely different kind of processes.
Scrum is chosen due to its specific advantages in
comparison to other agile methodologies: (1) Scrum is
presented as an integral part of the course in the topic
Agile software development methods; (2) teaching
process, as well as Scrum, is achieved through the
incremental development: through presentation of
theoretical knowledge, practical work and student project


M.E.Grimheder: Can agile methods enhance mechatronics

education? Experiences from basing a capstone course on
[5] V. Mahnic: A case study on Agile Estimating and Planning Using
[6] R. Pope-Ruark, M.Eichel, S.Talbott, K.Thornton: Let's Scrum:
How Scrum
Methodology Encourage Students to View
[7] K. Schwaber, J. Sutherland: The Definitive Guide to Scrum: The
Rules of the Game,
[8] Scrum
[9] Scrum Alliance, Core Scrum Values and Roles available at:
[10] A. Soria, M.R. Campo, G. Rodriguez: Improving Software
Engineering Teaching by Introducing Agile Management,13th
Argentine Symposium on Software Enginneering, ASSE 2012,
[11] R.L. Upchurch, L. Williams. In Support of Student Pair
Programming. ACM SIGCSE. ACM Publications, March 2001.
[12] VersionOne, 7th Anual Survey: 2011, The State of Agile
Development, Full Data

as well as examination; (3) theoretical knowledge and

practical skills are presented and thought iteratively: topic
by topic; (4) student projects are organised and developed
according to Scrum methodology: roles are assigned;
required computer equipment is defined as a part of
Environment Architecture; features of software products
being developed are entered on the Product Backlog list;
software requirements are defined according to Product
Backlog list and the team member responsibilities are
delegated through the Sprint Backlog list; software
product is developed incrementally and iteratively through
a number of Sprint cycles until final version is developed;
(5) project documentation is created and compiled.
In this paper some of the limitations and possible
improvements of the teaching model are given that could
further raise the quality of the current teaching process.



M. Broussard: The J-School Scrum: Bringing Agile Development

H. F. Cervone: Understanding agile project management methods
using Scrum, available at:
Development process, ProfIT Labs Ltd Custom software
development company,