Using Scrum to Teach Software Engineering:
a case study
Sergio Donizetti Zorzo, Leandro de Ponte, Daniel Lucrdio
Computing Department
UFSCar Federal University of So Carlos
So Carlos SP Brazil
{zorzo, daniel}@dc.ufscar.br
Abstract The diffusion of agile methodologies in software
development makes them more mature for corporative
environment. However, teaching agile methodologies on the
academic environment poses many difficulties and limitations.
This paper describes a case study where an innovative approach
for teaching software development technologies was adopted. In
this approach, the entire course was designed to fit Scrums
principles, so that the students could apply them as they were
learning it. Also, the courses main project was to be developed in
sprints, as proposed in Scrum. After almost two years using this
approach, in this paper we describe our experience and perform
a critical analysis. We observed some positive points, such as the
practical nature of learning by example, and a better preparation
of the students regarding agile methodologies. As negative points,
we highlight the impossibility of delivering complete products in
earlier sprints, and some interaction and collaboration
difficulties. The main conclusion of this study is that, for the
approach to work in our academic scenario, a modified version
of the Scrum methodology was necessary.
Keywordsagile methodologies, software engineering,
academic teaching, SCRUM
I. INTRODUCTION
The software market demands readiness for unexpected and
quick changes, and the earlier software engineering
methodologies did not seem to be appropriate for many
practitioners. Agile methodologies, such as Scrum [1], are a
response to this demand. As a direct consequence of this
evolution, there is an increasing need to place more emphasis
on teaching Scrum in order to prepare students for their
professional careers [2].
It is a known fact that teaching software engineering cannot
be restricted to presenting concepts and methodologies as
abstract ideas. It requires the integration of applied
methodology and theory into the practice of software
development, otherwise students may fail to develop a deep
understanding or appreciation of the most important ideas [3].
For this reason, most software engineering courses have a large
project, meant to be its final piece, also known as capstone
project. Mahnic presents a discussion about the use of agile
methods in capstone projects, based on different literature
reviews [2]. While there are many successful stories that favor
agile methodologies in these scenarios, Mahnic argues that
there are some reports indicating that a more traditional,
978-1-4673-5261-1/13/$31.00 2013 IEEE
disciplined process paradigm would be more suitable for the
still inexperienced students.
We were facing the same dilemma in our university. We
have a two-year lato sensu (specialization) graduate course in
software development, which has been offered since 2003. As
the final part of this course, students must develop a large
project to put into practice the concepts they learn. Until
recently, they followed a traditional process, moving from
requirements to the finished software product in a single
iteration. However, this model was causing problems, mainly
because of the lack of proper time management. Due to
different factors, such as limited availability of the students and
a long wait until they reached enough maturity to start
developing the project, the delivery of unfinished and/or poor
quality projects was very frequent.
An agile methodology seemed to be a perfect solution, as it
is a structured process, but that supports both creativity and
productivity in a team project. It also allows for flexible, self-
controlled time and task management that enables students to
react on the varying workload in their jobs [4]. So, as pointed
out by Schneider and Johnston [5], we asked ourselves: should
we try to change the scenario, and introduce the practices of
agile methodologies in software development education?
We decided to follow this path, by adopting a Scrum-based
approach to teach software development technologies and
software engineering concepts. In the approach, some Scrum
practices, such as iterative and incremental development based
on sprints, were integrated into the academic environment, so
that the learning itself could happen in an iterative and
incremental way. To fit this format, the entire course had to be
reorganized so that the disciplines could deliver the necessary
contents for the sprints to succeed.
In this paper we present the approach in details, and also
perform a critical analysis after two years of experience with it.
We highlight the main positive and negative points, and try to
make suggestions to improve it in the future.
The remainder of this paper is organized as follows.
Section II presents the background and scenario of the study.
Section III presents the sprint planning for this course. In
Section IV we present our critical analysis and suggestions for
the second version of the course. Finally, in section V we
present some concluding remarks and future work.
 II. BACKGROUND
The initiative described in this paper was conceived in the
context of a lato sensu (specialization) graduate course, in the
area of software development for the Web, offered at UFSCar
Federal University of So Carlos SP Brazil, since 2003.
In this course, students learn different software development
techniques and concepts, such as programming, modeling,
database design, human-computer interaction, web
development and project management. The course has also a
practical component, in the form of a mid-size software
project, where the students can put most of the theory in
practice. The course project was supposed to be developed in
parallel with the theoretical activities, in groups of six or less
students.
But since the beginning of the offering, we observed that
many projects reached the end of the course as incomplete, or
with fundamental flaws that could not be corrected in time. We
identified two main possible causes for this problem. The first
one is the fact that most students have a limited availability
because they have jobs and/or work in different areas. They
typically have 6-8 hours per week to work on practical
assignments, and this was causing many delays.
A second possible cause is the fact that many students
seeking this degree have little or no knowledge in computer
sciences, while others have practical knowledge, but never got
a bachelor or engineers degree. We typically have 20% of the
students without knowledge in software engineering and 30%
of the students working in other areas. As a result, the classes
normally start with a very heterogeneous distribution in terms
of academic formation and practical background. Many
students do not reach a degree of knowledge that is sufficient
for the project to start until much later in the course. So the
project normally started only after one year or more.
After many discussions, the course organizers came to the
conclusion that the solution to this problem was not to change
the course duration 444 hours distributed over two years
but to better distribute theoretical and practical effort.
Together with this observation, there was the fact that agile
methodologies were already included in the course program, as
a subject related to project management. But it was being
taught in an abstract way, leading some students to wrong
conclusions or even boredom.
As a response to these two problems, the course was
reorganized to employ the concepts and principles of agile
methodologies. Because it follows the agile ideology [1], even
though it is not specifically tailored for teaching, Scrum was
adopted as the model for the iterative approach to be followed
during the course.
First, it was established that the project was to be developed
iteratively and incrementally. At short periods of time, or
sprints, students should deliver parts of the system, until it is
complete. In parallel, the theoretical disciplines of the course
were reorganized to deliver the necessary content for each one
of these sprints to succeed.
The expectation behind this proposal was that students
could start development earlier, and have less risk of delivering
an incomplete project in the end. It would also make them
practice agile development in a mid-size project, reducing the
gap between theoretical software engineering teaching and
practical agile concepts.
Next section presents the detailed course setup and
description of the course project, according to the agile
approach.
III. COURSE PROJECT
Initially, it was established that the course disciplines
would be divided according to their applicability in the project.
For this reason, the course started with an overview of Scrum,
basic programming, requirements and analysis. More advanced
contents, such as database design and programming
frameworks, were to be introduced later, and so on. This was
done for the theoretical part of the course, which resulted in
four phases, described next.
The first phase had an estimated duration of 3 months, and
consisted in an introductory phase. It was also called pre-
Scrum phase, and was dedicated to the activities that are not
related to actual development. In this period, there were
teaching activities about the development process, environment
preparation and basic programming. The disciplines that were
part of this phase were:
- Agile software development: studies about the software
development methodology that would be used in the
projects. In this course, Scrum was adopted;
- Free software development platforms: preparation of the
environment to be used in the project. In this case, the
students would have to work with CentOS [6], PostgreSQL
[7] database and Java IDEs NetBeans [8]; and
- Java certification: a basic java discipline, intended to help
students get acquainted with the language that should be
used to develop the projects.
The second phase, which had duration of 4-5 months,
involved the actual usage of the agile methodology. In this
phase, the disciplines focused on requirements, analysis and
design. The goal was to enable the analysis and design of the
project to be developed. But since the students should already
be developing part of their projects, some software
development techniques were explored, such as web
development, mobile computing, and database activities. This
would allow them to deliver a few parts of the software that
involved only basic programming. Other parts of the project,
that required advanced knowledge on database persistence or a
more complex framework, would be introduced later.
In the third phase, with duration of 5-6 months, there were
the disciplines that would provide most of the content of the
course. Here the focus was on giving a complete coverage of
most recent web development topics, such as human-computer
interaction, object-relational persistence frameworks, service-
oriented architecture, reuse-driven development, test-driven
development, among others. The content of this phase was
intended to be used by the students during most of the part
when developing their projects.
 In the fourth and final phase, which was supposed to last
2 months, the disciplines involved advanced topics, to close the
theoretical part of the course. Project management, advanced
development topics, such as data warehouse and optimization,
and even scientific methodology, helped to give students a
better understanding of which topics could be further explored
later in their career.
These four phases characterize the theoretical part of the
course; however they were not applied in a sequential way.
Since we were following an iterative process based on Scrum,
the actual division of activities was different. The course was
organized around the project, and thus it was divided into eight
sprints of three months each. At the end of each sprint, students
were supposed to deliver part of their projects, as working
software.
TABLE I.
Sprint Disciplines
- Agile software development
Pre-
- Free software development platforms
Scrum
- Java certification
- Web programming
- Pattern-based software modeling
- User interface design and evaluation for the web
1
- Object-relational patterns and frameworks
- Agile software development
- Database design
- Pattern-based software modeling
- User interface design and evaluation for the web
- Object-relational patterns and frameworks
2
- Database design
- Mobile computing
- Agile software development
- Mobile computing
- Web development frameworks
3 - Sharing of public messages
- Object-relational patterns and frameworks
- Agile software development
- Service-oriented architecture and web services
- Reuse-driven software development
4 - Multiple timeline visualization
- Scientific methodology
- Agile software development
- Test-driven development
- Service-oriented architecture and web services
5
- Reuse-driven software development
- Scientific methodology
- Reuse-driven software development
- Performance optimization of Relational DBMS
6 - Images and visual effects in web applications
- Software development topics
- Agile software development
- Data warehouse
7 - Scientific methodology
- Reuse-driven software development
- Project management in agile software development
8 - Technical issues
- Scientific methodology
To support these deliveries, the disciplines had to be
arranged to provide students with the necessary knowledge in
each sprint, in order to allow a logical evolution from sprint 1
to 8. So, early sprints have more focus on disciplines from the
phase one of the theoretical part of the course. And late sprints
have more focus on the disciplines from phase four.
There had to be some repetitions, as some disciplines had
too much content. In these cases where the same discipline
appears in more than one sprint, only part of the content was
given at each time. For example, the agile software
development discipline appears in six sprints, each time
introducing new concepts, starting with basic concepts and
ending with practical examples and guidelines. Object-
relational patterns and frameworks is another example,
appearing in three sprints, basic concepts in the first and
BASIC COURSE SCHEDULE
Sample deliverables of one of the groups
None
- Class models
- Database models
- Basic CRUD operations for users
- System authentication
- Advanced CRUD (different user types)
- Community creation
- Update in the system layout
- Update in the documentation
- Profile visualization
- Profile data update
- Timeline visualization
- Pending issues in authentication
- Design for mobile devices
- Login/logout for Mobile
- Information visualization
- Basic CRUD for other information
- Message posting
- Project mockup
- Technical issues
- Visual adjustments in the interface
- Image posting
- Contact acceptance
- Search for contacts and communities
- Inclusion of contacts and communities
- Community visualization and adding
- Video posting
- Invitation/inclusion of people in communities
- Administrative interface
- Access privilege control
- Community reports
practical knowledge in the end.
Although it may seem that these sprints take longer than
most sprints in industrial projects, which typically last between
2-3 weeks, in terms of work hours the duration is
approximately the same, because students were supposed to
work 8-10 hours per week on the course project.
Table I shows the basic course schedule, together with an
example of the deliverables that one of the groups should
provide at the end of each sprint. The deliverables refer to a
system to help in the organization of scientific events, which
was the domain of their project. In the next section more
details about the project and the deliverables are presented.
The students must complete a mid-size software project as
part of their course. In our approach, this should be done
iteratively, to reduce the risk of incomplete projects in the end.
So, the students had to plan what should be delivered, in term
of user stories [9,10], at the end of each sprint. Due to the
limitations of the academic environment, in comparison with
an industrial project, in our approach students were allowed to
deliver incomplete products in some sprints. In other cases,
students could plan to deliver only enhancements or
adjustments, instead of a product, in a sprint. Table I shows
some examples of these cases in sprints 5 and 8. But every
sprint should include some form of deliverable.
There was a product owner (PO) [9,10] assigned to each
team of six students. The PO would be responsible for the
definition of the stories and for following the results of the
development. As this was also an exercise of Scrum itself,
students had to practice the role of Scrum Master [9,10]. So, in
each sprint, a different member of the team should act as
Scrum Master, to put in practice the different concepts of the
method and also learn his/her responsibilities.
Another important point of the project setup was the
definition of the domain. We have observed that, in this course,
the groups almost always follow a pattern: normally, students
are professionals working on the software market, with little
time to develop the activities. They also normally live in a
distance from each other only a few groups are composed of
people living in the same city. The different areas in which
Fig. 1. Example of a kanban sheet
they work also caused a great degree of heterogeneity and a
knowledge gap between the members of a group.
To minimize the negative impact of these factors, we
defined that all groups, without exception, should work on one
out of two possible projects. Half of the groups would develop
project A, and the other half would develop project B. With a
regular class size of 35 students, this results in six teams with
5-6 students.
Two teachers would play the role of PO, one for each
project. They were supposed to help during the planning
meetings and give technical support regarding the development
technologies and/or correct application of Scrum principles.
Control during the process would be performed with the
help of an on-line sheet. In this sheet, students and teachers
should include and maintain all the necessary information to
allow a proper management of the development in each sprint.
Basically, when planning a sprint, the students would insert
the stories in the sheet, together with the activities to be
performed. With all activities available on-line, each member
perform it. The Scrum Master (of that particular sprint) was
responsible for maintaining the sheet, and also making sure the
others keep it updated, so that he/she could follow the
burndown chart [9,10]. In this sheet, the chart was
automatically updated each time an activity was marked as
completed. The following information was part of the sheet:
- Product backlog: list of stories of the system, with a detailed
description and the acceptance criteria;
- Sprint: stories of the current sprint and the tasks needed to
finish them;
- Kanban: repeats the tasks from the sprint part, and
includes a status column (to do, blocked, doing and
done) and a task finish date column. Fig. 1 shows an
example of this part of the sheet;
- Burndown data: based on the tasks table of the kanban
sheet, this part keeps a comparison between the planned
dates and the actual dates; and
- Burndown chart: graphical visualization of the burndown
 data. Fig. 2 shows an example of this part of the sheet .
Fig. 2. Example of a Burndown Chart
IV. CRITICAL ANALYSIS
In general, the approach was successful, as both of its goals
were achieved:
1. All groups were able to deliver the complete project in
the end of the course; and
2. Students managed to put some of the agile principles in
practice, using them as they were learning them. This resulted
in a better learning of agile concepts.
There were also some additional positive observations. In
our case, both teachers acting as POs had previous experience
with Scrum in practical scenarios, which has proven to be
essential to provide a good alignment between the course
content and the principles of agile development. The presence
of these teachers as POs, and their constant availability, was
also a positive result, since it allowed students to clear their
doubts without taking too much time. The fact that the POs
were teachers, specialized in Scrum and technical development
concepts, and not business experts, did not result in a negative
influence. This happened because the projects involved a
domain which they were actually very familiar with scientific
events. The rotation of the Scrum Master role was also
benefitial, allowing each student to play this part at least one
time.
However, we observed many problems with the approach,
and we believe these could be addressed to provide even better
results in the future.
A first problem relates to the gradual evolution of the
learning process in a normal course, and its contrast with the
incremental and iterative approach proposed by most agile
methods. There is a natural incompatibility between these two
approaches, because each sprint represents a small, but
complete, development iteration. This means that, in each
sprint, the development team must perform activities that are
related to almost all software engineering disciplines, even if
only a little part of them at a time. Although we attempted to
introduce these disciplines at the same time, much content was
only really assimilated by students after two or three sprints,
after the discipline was finished.
This explains why most groups were unable to deliver
complete software in earlier sprints, because they simply did
not have enough knowledge to implement a complete piece of
software. For example, service-oriented architecture is only
introduced in sprint 4, so it was impossible for some groups to
implement a distributed part of the software in sprints 1, 2 and
3. More basic concepts, such as object-relational frameworks,
were introduced only in the final stage of sprint 1. Some
framework concepts were left to sprints 2 and 3, so many
stories could not be completely implemented in these sprints.
When interviewed by us, some of the students reported this
exact problem. Many complained about the mandatory
deliveries in the early sprints, arguing that they still had not
learnt the necessary concepts to implement what was being
planned. Those ended up delivering incomplete software or
software with conceptual errors. Of course, there were those
students that already had the necessary knowledge, because
they already work with development, but this is far from ideal.
A second problem we observed relates to inspection and
self-management, two central aspects of Scrum [9,10].
Students reported that, because they are not physically close to
each other, and because many of them had other time-
consuming activities, some of the interaction tasks required for
control in Scrum were not properly executed, or not executed
at all. One example is the interaction between the Scrum
Master and the rest of the team, which turned out to be very
difficult under these conditions. The physical distance and the
lack of responsibility and discipline of the other members of
the team made it nearly impossible for the Scrum Master to
control task execution in a continuous fashion. This is a serious
flaw, because personal interactions is a strong principle of
Scrum and agile methods in general.
Another issue is that, because there were only two possible
projects, shared by all groups, there was always some kind of
comparison happening between the students. Some felt
pressured to keep up with the most experienced students, while
others, less experienced students, felt intimidated by the top
groups, becoming even frustrated in some cases.
We do not see any ideal solution for the first two issues, as
we consider them to be innate to this particular academic
environment. It is not possible, for example, to obligate
students to be physically present at the university all the time,
since this is a postgraduate course, and most students have their
regular jobs. However, we did identify some improvement
possibilities, that we intend to test in a future version of the
course. These are described next.
A. Changes in the second version of the course
A first change relates to the definition of the POs. In the
first version, two teachers acted as POs for all groups. This was
not seen as a negative point in the first version, but only
because the projects involved a domain the teachers were
familiar with. As we wanted to change the domains, we
decided to use actual business experts as POs. We also defined
that they should not be familiar with technical details. The idea
is to make the students experience what it feels like to deal
with potentially real customers, having to work harder to
establish the communication and capture the POs knowledge.
A second change is that, differently from the first version,
where there were only two projects from which students could
choose, in this second version there were more options,
allowing each group to work in a different project. This should
reduce the comparison effect we observed earlier.
Another change in this second version is related to
corrections and improvements made in the software, from one
sprint to another. In the first version of the course, we observed
that many groups were spending time in one sprint to correct
mistakes made in the previous one. This happened because of
the irregular learning curve discussed in previous section. In
this version, we made it possible for students to include these
corrections and improvements as valid deliverables. So, instead
of delivering one complete piece of software in each sprint, a
group was allowed to deliver an incomplete, or erroneous part
of software, in one sprint, and plan its correction in a future
sprint.
The changes described here are being currently tested, in a
second offering of the Scrum-based version of the course. We
expect to observe improvements related to some of the issues
described in the previous section.
V. CONCLUDING REMARKS AND FUTURE WORK
Although we observed many problems and issues, the
merging between teaching and an agile process has proven to
benefitial to students. It leveraged the overall experience, from
simpler theoretical classes, to a richer practical activity
revolving around actual development, simulating the real
challenges of this dynamic environment. Students were forced
to not only understand the concepts and principles of agile
development, but put them in practice and feel the difficulties
faced by practitioners. In particular, they had to deal with
technical challenges, process enactment challenges, personal
interaction and inter-team relationship.
We perceived that some aspects of the methodology, such
as scoping and delivery restrictions, had to be adapted to make
the experience viable in an academic environment. Some of
these adaptations were aldeady made during this first
experience, while others are being tested in a second version.
In either case, the adaptative nature of the course made this
experiment possible.
Regarding the difficulties and problems that were observed,
we conclude that some can not be easily solved, such as those
related to the physical distance between the students and their
lack of time and dedication. For others, we are currently
experimenting some changes, as described in previous section,
and we expect good results. Feedback from the teachers and
the students will enlighten our path, and possibly raise new
issues.
Besides these changes we already described, future work
should deal with:
- Better distribution of the disciplines alongside the sprints, to
provide a closer alignment with the deliverables. Perhaps
there should also be some kind of guidance during the
initial planning, in order to help students to start with
simpler stories;
- Better choice of projects, to only include those that are
amenable to a more logical division from simpler
functionality to a more complex one; and
- Self-management formalization, to help Scrum Masters to
deal with their teams. Currently, it is up to the team to
define how they should be managed. However, this has
proven to be problematic, because of the distance between
its members. A more formal process, requiring more rigid
control, would force students to have discipline and an
active participation, specially in process control. Even if it
goes against the agile principles, we believe this could be
benefitial in this particular environment.
The experience, although in its first version and with
glitches and corrections to be made, forcing students to not
only understand the concepts wrapped up the process, but also
to apply them and feel the difficulties faced by professionals
who choose to use the method, as both procedural and planning
relationship with the team.
It is felt that some aspects of the methodology, such as the
closing of scope and delivery restrictions, sometimes must be
adapted so that it becomes feasible to use the method in
practice academic environment. The vision of the labor market
and experience in agile methodologies presented by those
involved was importance to design and optimized coordination
of the course. Some strategies may not be considered agile, as
the time between sprints and little interaction between the team
members. The time between sprints is necessary because the
teams need learn how to do and do it. The increase of
interaction between the team members can be made and we
have recommendations how to solve it in the next experience.
In the next experience some points will be analyzed to
reduce the difficulty required to develop the full functionality
in the sprints with only part of knowledge, requiring only the
scope that has already been taught. The process for the
development of Sprint requires weekly meetings replacing the
daily meetings of the original conception of Scrum. The
meetings will relate the status of the worksheets and they will
show the progress of activities in parallel. These points will be
not abandoned and they are essential for the correct handling of
the use case, where someone can perform a checkpoint of these
activities during the sprints, assessing whether the performance
is occurring in the team. However, attention must be given up
lest they undermine the progress of activities and the
motivation of participants with a big load evaluation.
REFERENCES
[1] Rising, L. and Janoff, N.S. Jul-Aug 2000. The Scrum software
development process for small teams, Software, IEEE , vol.17, no.4,
pp.26-32.
[2] Mahnic, V. A Capstone Course on Agile Software Development Using
Scrum Feb. 2012. IEEE Transactions on Education , vol.55, no.1,
pp.99-106. doi: 10.1109/TE.2011.2142311
[3] Dahiya, D. 2010. Teaching software engineering: a practical
approach. SIGSOFT Software Engineering Notes, Vol.35, pp.15.
[4] Schild, J., Walter, R., and Masuch, M. ABC-Sprints: adapting Scrum to
academic game development courses. 2010. Proceedings of the Fifth
International Conference on the Foundations of Digital Games (FDG
'10) ACM, New York, NY, USA, pp. 187-194.
[5] Schneider, J.G. ; Johnston, L. and Joyce, P. Curriculum development
in educating undergraduate software engineers - are students being
prepared for the profession?. 29 March-1 April 2005. Software
Engineering Conference. Proceedings. 2005 Australian , pp.314-323.
[6] CentOs Internet: http://www.centosbr.org [Apr 02, 2013] [9] Singh, M. "U-SCRUM: An Agile Methodology for Promoting
[7] Welcome to NetBeans. Internet: http://www.netbeans.org [Apr 02, Usability," 4-8 Aug. 2008. AGILE '08. Conference , Proceedings, pp.
2013] 555-560.
[8] PostgreSQL: The world's most advanced open source database [10] Schwaber, K. and Beedle, C. 2002. Agile Software Devlopment with
Internet: www.postgresql.org [Apr 02, 2013] Scrum, Prentice Hall.
[11] Sink, E. "Stories from My Experiences Learning Scrum," 7-13 Aug.
2011. Agile Conference (AGILE), 2011 , pp.216-222.