2015 12th International Conference on Information Technology - New Generations
Project management using the Scrum agile method:
A case study within a small enterprise
Breno Lisi Romano
Federal Institute of Education, Science, and Technology
of Sao Paulo - Sao Joao da Boa Vista, SP - Brazil
blromano@ifsp.edu.br
Abstract — This paper tackles the use of the Scrum agile method
within a Brazilian small business enterprise. It provides
monitoring activities for software project management. It
involves the use of human, financial, and temporal resources
during a project development, increasing the rate of its successful
deliveries. In order to enable the Scrum adoption, the following
four distinct steps were defined: infrastructure set up, team
training, Scrum agile deployment, and deployment refinement.
An analysis of its main results was obtained from the application
of a survey to all project stakeholders. The major improvements
were identified since the first sprints, mainly involving
communication, team motivation, and adaptation agility, during
the chosen case study within a small enterprise.
Agile method; Scrum; small enterprises; project management
I. INTRODUCTION
Several new enterprises have emerged over the years to find
this demand for new IT projects. With this new competition, it
has increasingly demanded quality, reduced costs, and fulfilling
deadlines [1]. According to Beck (2004), the software
development has problems mainly in software delivery and in
given values and these failures have enormous human and
economic impacts. Consequently, it is necessary to find a way
to develop quality software and frequent deliveries [2].
From that context, new approaches to project management
called agile methods were created, mainly aiming to be flexible
to the dynamic nature of the environment, which is frequent in
software development with value creation and innovation.
Even with all the progress in software development, as
previously mentioned, there are still many difficulties to be
solved within enterprises [3] [4] [5].
Within this context, for this paper it was chosen a small
business enterprise environment to perform a survey aiming to
present the adoption of an agile solution. This choice was made
because the enterprise has a number of development problems,
often of small and medium-size, involving mainly the lack of
work processes in the development of new projects [4].
This paper tackles the use of the Scrum agile method within
a Brazilian small business enterprise. It provides monitoring
activities for software project management. It involves the use
of human, financial, and temporal resources during a project
development, increasing the rate of its successful deliveries.
II. THE SCRUM DEVELOPMENT APPROACH
To identify the effectiveness of agile in a small enterprise a
software house was chosen for a survey. It was located in Sao
Joao da Boa Vista, a small city of São Paulo state in Brazil,
978-1-4799-8828-0/15 $31.00 © 2015 IEEE
DOI 10.1109/ITNG.2015.139
Alan Delgado da Silva
Federal Institute of Education, Science, and Technology
of Sao Paulo - Sao Joao da Boa Vista, SP - Brazil
alan.delgado@hotmail.com
having different sales representatives in various parts of the
state o Sao Paulo.
The chosen enterprise clearly presented the same
difficulties, but its main difficulties were the lack of a life cycle
model to guide the development in steps that should be
implemented. It was found out that the enterprise operates
currently as follows: requirements are raised unstable and
passed to developers during the implementation phase; the
analysis phase is performed during the coding phase; and the
testing phase is virtually nonexistent and unit tests are done by
developers.
For this research, it was decided to use the Scrum agile
method as a solution to be deployed mainly for being the most
agile method used in Brazil. The Scrum method is simple and
fast applicability; so that the team will not need to change
much of their development practices to be using the method but
only will be looking for to adapt to the method characteristics.
Once defined the agile method, to conduct its deployment in
the enterprise, it became necessary to carry out a cycle of the
following, as shown in Figure 4.
Figure 1. Steps of Scrum Deployment within a small enterprise
In the Step 01, all elements related to the development team
environment was resolved, so that everything is ready before
starting the development process, aiming to avoid the lack of
these elements during the early projects.
In the Step 02, the trainings were conducted by dividing
roles of agile method, namely: Scrum Master, Product Owner
and Team Developers. This division is justified because each
requires different responsibilities and may thus provide a better
use of the training.
After defining the infrastructure and undertake all necessary
training, it is time to set up the practice of concepts of Scrum
774
agile method in Step 03. A new project was chosen on the
adopted enterprise that did not have a defined schedule.
In the Scrum Agile Deployment (Step 03), the composition
of the project members was defined, by identifying its
responsibilities (roles). It is noteworthy that the team was
composed of one Product Owner, one Scrum Master and four
Developers with varying levels of technical knowledge. The
concepts of Kanban for monitoring tasks, Planning Poker to
assist in the estimation of the staff time, and the Burndown
Chart for visual control of the progress of the team were
adopted.
At this time, three sprints have already been successfully
implemented. For each sprint, the following ceremonies Figure 3. Burndown Chart – Sprint 003
occurred, as planned within the Scrum meetings: the Release
Planning Meeting, the Sprint Planning Meeting, the Sprint III. RESULTS ANALYSIS AND CONCLUSION
Review and the Sprint Retrospective.
At the end of the first development cycles, which were
Table I highlights the performance and progress of the team reported in the first 3 sprints of the project, it can be observed
in executing each of sprint. the way in which the proposed method followed and the
obtained results during the process.
TABLE I. TEAM PERFORMANCE ON SPRINTS
In order to verify the gains from this deployment, it was
Sprints Initially Hours Planned Complete Conclusi decided to perform a standard survey to collect the opinions of
Planned Held in Tasks d Tasks on (%)
hours Practice the members who participated in the use of agile method
Sprint 27h 35h10 23 8 34,78% Scrum, making a comparison between the developments before
01 the deployment of agile method in relation to after deployment.
Sprint 65h 77h50 39 16 41,02%
02 It was necessary to establish the possible responses of the
Sprint 102h 85h 37 37 100% participants in order to perform a standardization of the same.
03 Four types of responses were established as shown in Table II.
It was also elaborated a Burndown chart for each performed
sprint. Figures 5 and 6 show the Burndown Charts of Sprint TABLE II. STANDARD ANSWERS TO THE QUESTIONS
001 and 003. Classification Explanation
Finally, after the method to be used in practice, it became
S Satisfied The situation complies with the item in most
necessary to perform the Step 04 refining the process in which cases or at least 90% of cases.
they must look for improve the method processes, analyzing MS Mostly The situation partially complies with the item,
and improving the difficulties previously encountered. When it Satisfied i.e. more than 60% of cases.
identified the need for adjustments, which was planned to be D Dissatisfied The situation does not complies with the item
corrected in the next projects. It is emphasized that this step of partially, i.e., less than 60% of cases.
refinement also happens at the end of each sprints executed, U Unknown Unknown or chose not to evaluate.
mainly through discussions at meetings of Sprint
Retrospective. From the established characteristics, it was made available
to those involved answering a questionnaire on the set items.
The final rating is a weighted average of all results of the item.
If a tie occurs, it was considered the lowest rating in order to
regard the worst scenario. Table III shows a final comparison
between the two results, comparing before and after the
deployment of Agile Scrum method.
In all cases there were positive changes, even considering
the team's participation in items rated satisfactorily. The results
also indicate a significant improvement in quality and time
estimate that reportedly were flawed or non-existent when there
was not agile.
In the realized questionnaire, it was offered an opportunity
Figure 2. Burndown Chart – Sprint 001 for participants to provide their suggestions, opinions or
criticisms about the agile method deployment, being of great
importance to understand the environment after deployment.
One of the positive results that the team was highlighted
improvement in internal communication, they all began to

775
work together to achieve a goal. The group became stronger, in levels of internal communication to satisfy the requirements of
which a teammate began to understand the tasks of other Scrum, which has sought to improve over the last Sprint
employees, knowing the qualities, defects and that they could presented.
help.
Another negative result, not of the agile method, but of the
TABLE III. RESULTS OF THE INTERNAL SURVEY - BEFORE AND AFTER small business environment, it is the excess of external
SCRUM DEPLOYMENT interrupts. They are businesses with few employees and,
generally, each playing more than one role in the organization,
Characteristics Before Deployment After
developers often were interrupted to resolve issues related to
Deployment other projects.
Communication Mostly Satisfied (MS) Satisfied (S) By Agile method requires that the team is focused on the
project, these external interruptions disturb the project
Motivation Mostly Satisfied (MS) Satisfied (S) progress. Unfortunately, it is difficult for the members
Participation Satisfied (S) Satisfied (S)
themselves did not stop with the project to solve these extra
Commitment Mostly Satisfied (MS) Satisfied (S)
demands, because if they do there will be no one to do. These
Systems Dissatisfied (D) Mostly Satisfied (MS)
Documentation
situations were not detected previously, by not having any
Development Dissatisfied (D) Mostly Satisfied (MS) method of assessment and review of internal processes.
Performance
Dissatisfied (D) Mostly Satisfied (MS)
The only limitation would be on the environment have an
Interruptions
Tests Dissatisfied (D) Mostly Satisfied (MS) organization that will allow the team to work on these projects
Quality Assurance Dissatisfied (D) Satisfied (S) focused mostly on time of day. The Scrum method is flexible
Time Estimation Dissatisfied (D) Satisfied (S) to tolerate some these interruptions, but cannot become
Comply with the Dissatisfied (D) Mostly Satisfied (MS) frequent in the development environment.
estimated deadline Additionally, the agile Scrum method proves to be easy to
Additionally, developers have recognized the flaws that learn, but a little tricky to use, because it requires a lot of
they were committing, for lack of having a development control of its events and artifacts. With a simpler
method to support decision making. This created a desire in documentation, communication has to become more frequent
employees and the direction of correcting the faults and among participants. An advantage for small/midsize
commit to deliver a higher quality product. enterprises is that they generally lacked complex
Regarding the use of the Kanban board, the development documentation. Therefore, they easily adapt the rules of the
team adopted its use where noted ease to observe the running method.
tasks, which before was not visible by everyone involved. It Due to the lack of information regarding the development
was recommended the use of Kanban board to other sectors of of some previous project in relation of Scrum Agile
the enterprise, such as technical support managing service Deployment, it was not possible to perform a quantitative
orders. According to reports in the questionnaire, the daily analysis of improvement relative costs, human resources and
meetings gained focus to be held in front of the Kanban board, development time. In future works, the authors of this paper
which facilitated the understanding of the goals and tasks. seek to analyze and monitor the use of agile method after the
adjustment period.
Another praised point and that proved very useful was the
use of Planning Poker and Burndown chart. According to the REFERENCES
team, when performing the time estimation tasks with the deck
[1] SAVOINE, M.; et al. Análise de Gerenciamento de Projeto de Software
of Planning Poker, leveling skills, in which developers with Utilizando Metodologia Ágil XP e Scrum: Um Estudo de Caso Prático.
little experience occurred could expose their difficulties and, In: XI Encontro de Estudantes de Informática do Tocantins, 2009,
more experienced, guide regarding which path to be adopted. Palmas. Centro Universitário Luterano de Palmas, 2009. p. 93-102.
In addition, the team praised the effectiveness of the Burndown [2] BECK, K. Programação Extrema (XP) explicada: acolha as mudanças.
chart provides the time to show the progress of the Sprint and Bookman, Porto Alegre, 2004.
there are still many tasks to complete. [3] TOLEDO, José C.; DA SILVA, Sérgio L.; MENDES, Glauco H. S;
JUGEND, Daniel. Fatores críticos de sucesso no gerenciamento de
Finally, a positive result that could be observed is the projetos de desenvolvimento de produto em empresas de base
motivation of the team to face the new projects with the tecnológica de pequeno e médio porte. Gest. Prod., São Carlos, v. 15, n.
support of the agile method, especially for her build confidence 1, p. 117-134, jan.-abr. 2008.
and provide useful tools for any project, whether complex or [4] CHAGAS, N. Melhoria do Processo de Desenvolvimento de Software
em uma Pequena Empresa Utilizando a Norma NBR ISO/IEC 12207.
not. Maringá: Conclusão do curso de Bacharelado em Informática, 2005.
56p. Cap. 4: Levantamento e Análise dos Dados Obtidos.
On the other hand, it was observed by the team a few
negatives points during the performing of the three Sprints, [5] MACULAN, A. M. Ambiente empreendedor e aprendizado das
pequenas empresas de base tecnológica. In: LASTRES, H. M. M.;
mainly caused by lack of experience on the team with the CASSIOLATO, J. E.; MACIEL, M. L. Pequena empresa: cooperação e
process. It was highlighted by the team it needs to improve the desenvolvimento local. Rio de Janeiro: Relume Dumará: UFRJ, 2003. p.
311-327.

776