ArticlePDF Available

A Case Study on Agile Estimating and Planning using Scrum

Authors:

Abstract

We describe a case study that was conducted at the University of Ljubljana with the aim of studying the behavior of development teams using Scrum for the first time, i.e., a situation typical for software companies trying to introduce Scrum into their development process. 13 student teams were required to develop an almost real project strictly using Scrum. The data on project management activities were collected in order to measure the amount of work completed, compliance with the release and iteration plans, and ability of effort estimation, thus contributing to evidence-based assessment of the typical Scrum processes. It was found that the initial plans and effort estimates were over-optimistic, but the abilities of estimating and planning improved from Sprint to Sprint. Most teams were able to define almost accurate Sprint plans after three Sprints. In the third Sprint the velocity stabilized and the actual achievement almost completely matched the plan.
123
ELECTRONICS AND ELECTRICAL ENGINEERING
ISSN 1392 – 1215 2011. No. 5(111)
ELEKTRONIKA IR ELEKTROTECHNIKA
EDUCATION IN ELECTRONICS AND ELECTRICAL ENGINEERING
T 000
STUDIJOS ELEKTRONIKOJE IR ELETROTECHNIKOJE
A Case Study on Agile Estimating and Planning using Scrum
V. Mahnic
University of Ljubljana, Faculty of Computer and Information Science,
Trzaska 25, 1000 Ljubljana, phone: +386 1 4768 447, e-mail: viljan.mahnic@fri.uni-lj.si
Introduction
Introducing agile methods into their development
process represents an important challenge for many
software companies. In the last few years several
successful implementations of agile methods have been
reported in the literature, e.g., [1–4]. According to Agile
Adoption Rate Survey [5] performed by Dr. Dobbs Journal
in 2008 agile teams report significant improvements in
productivity, quality, and stakeholder satisfaction, and
reasonable improvements in cost. A similar survey
conducted by VersionOne [6] additionally reports
enhanced ability to manage changing priorities and
significantly improved project visibility. For this reason,
agile methods are especially suitable for development of
information systems with changing and emergent user
requirements, e.g., [7]. On the other hand, the same survey
has revealed that the lack of experience with agile methods
and the conflict between the company’s culture and core
agile values are the leading causes of failed agile projects.
In spite of the fact that Scrum [8, 9] is the most
widespread method in industry (according to [6] Scrum is
used by 58% of respondents, Scrum/Extreme Programming
hybrid by 17%, custom hybrid by 5%, Extreme Program-
ming by 4%, etc.), a systematic review of empirical studies
on agile software development [10] found only one study
investigating Scrum. Consequently, one of the clear
findings was that the coverage of the research area should
be increased placing more focus on management-oriented
approaches such as Scrum, which Dingsøyr et al. [11]
consider an example of an area where there is a large gap
and should be given priority.
In order to fill this gap empirical studies with students
as subjects can be helpful in further assessment of the
applicability of Scrum before it is actually deployed in
industrial software environments. A properly designed
study [12] can provide preliminary evidence about its
strengths and weaknesses, thus reducing risks
accompanying its adoption in practice.
In this paper we describe a case study that was
conducted at the University of Ljubljana with the aim of
studying the behavior of development teams using Scrum
for the first time, i.e., a situation typical for software
companies preparing to introduce Scrum into their
development process. Within the framework of the
capstone course in software engineering, which (as
recommended by [13]) students take in their last semester
13 student teams were required to develop an almost real
project strictly using Scrum. The data on project
management activities were collected in order to measure
the amount of work completed, compliance with the
release and iteration plans, ability of effort estimation, etc.,
thus contributing to evidence-based assessment of the
typical Scrum processes for possible use in software
engineering practice.
Aims of the study and research questions
The aim of the study was twofold: (1) to analyze
development teams’ abilities of adopting Scrum concepts
(e.g., estimation of user stories, release and iteration
planning, concept of a user story being ‘done’), and (2) to
gather their opinions regarding the importance of particular
practices for a successful Scrum project.
Regarding the first aim our hypothesis was that the
estimates and plans will be less accurate at the beginning,
but will improve from Sprint to Sprint. There is substantial
evidence reported in the literature that the expert estimates
tend to be over-optimistic [14] and that the planning poker
estimation technique used by Scrum does not completely
eliminate the over-optimism [15]. Therefore, we expected
our study to yield similar results. Considering our previous
experience [16] and results of a study on behavior of
Scrum teams [17] reporting the problem of unclear
completion criteria we also decided to pay special attention
to the notion of ‘done’. It was agreed that the Product
Owner could accept only those stories that were fully
tested and robust enough to survive an encounter with end
users.
With regard to the second aim a survey was
conducted at the end of the study in order to find practices
that contribute most to the success of a Scrum project.
Practices were rated using a 5-point Likert scale, the grade
1 representing the lowest and the grade 5 the highest level
of importance.
124
The remainder of the paper is organized as follows:
In the next two sections we describe the case study design
and its results. Then a description of students’ opinions
regarding the importance of particular Scrum practices
follows. Finally, the limitations of the study are discussed
that should be considered when applying the results in the
industrial environment.
Case study design
The case study was conducted in the Summer term of
the Academic Year 2009/10 as a part of the capstone
software engineering course that lasted 15 weeks and was
taken by 52 students who were divided into 13 groups.
Each group played the role of a self-organizing and self-
managing Scrum Team responsible for the development of
a Web-based student records system covering enrollment,
examination applications, examination records, some
statistical surveys, and a special module for the
maintenance of all data required for the proper functioning
of the system (i.e., the maintenance of various code tables,
lists of required and optional courses, data about teachers
of each course, etc.).
The initial Product Backlog comprised 60 user stories
and was the same for all teams. It was prepared by the
teacher who had considerable experience in developing the
University of Ljubljana student records information system
[18, 19], thus being able to play the role of the Product
Owner. 55 stories described the required functionality for 4
different user roles (i.e., student records administrative
staff, students, teachers, and data administrator), whereas
five stories described constraints that had to be obeyed
(e.g., the system had to enable remote access to data
through the Internet, all outputs should also be printable,
etc.). Each story contained a short description and a set of
acceptance tests that had to be used to demonstrate that the
story had been correctly and fully coded.
The Product Owner divided the stories into 4 groups
on the basis of priority. There were 24 ‘must have’, 5
‘should have’, and 4 ‘could have’ stories required in the
first release, which should have been finished by the end of
the course. The remaining 27 ‘won’t have this time’ stories
were specified merely to illustrate the desired functionality
in the next release.
At the beginning of the course students were given 12
hours of formal lectures on agile principles, Scrum, and the
use of user stories for requirements specification and
iteration planning. The first three weeks also served as a
preparatory Sprint (Sprint 0) before the start of the project.
During Sprint 0 the development environment was
prepared and students were given the aforementioned
initial Product Backlog.
At the end of Sprint 0 each team was asked to
estimate the stories of the first release using planning poker
[20] and (considering its estimated velocity) prepare the
release plan. A story point was treated as an ideal day of
work and the estimates were constrained to specific
predefined values of 0.5, 1, 2, 3, 5, 8, 13, and 20 as
proposed by Cohn [21]. Initial estimates and release plans
of all teams were recorded for further analysis.
The rest of the study consisted of three Sprints, each
of them lasting 4 weeks. Strictly following the Scrum
method each Sprint started with a Sprint planning meeting
at which student teams negotiated the contents of the next
iteration with the Product Owner, and developed the initial
version of the Sprint Backlog. During the Sprint the teams
had to meet regularly at the Daily Scrum meetings and
maintain their Sprint Backlogs decomposing the user
stories into constituent tasks and assigning responsibility
for each task. Each student individually estimated how
many hours it will take to accomplish each task he/she had
accepted. The instructors did not interfere in the
distribution of tasks among team members and the
estimation of effort, but merely paid attention that the
process ran smoothly and everybody obeyed Scrum rules.
At the end of each Sprint the Sprint review and Sprint
retrospective meetings took place. At the Sprint review
meeting the students presented results of their work to
instructors while at the Sprint retrospective meeting
students and instructors met to review the work in the
previous Sprint, giving suggestions for improvements in
the next one. After three Sprints the first release had to be
completed and delivered to the customer.
Since it was impossible to expect students to work on
the project every day, two Daily Scrum meetings per week
were prescribed, one on Monday and the other on Thurs-
day. At the Daily Scrum meeting each team member had to
record the number of hours spent and the amount of work
remaining for each task he/she was responsible for. When
the team finished a story the Product Owner was asked to
evaluate its implementation. The Product Owner strictly
enforced the concept of ‘done’, rejecting all stories that did
not conform to user requirements. If the shortcomings were
not removed by the end of the Sprint a new story was
defined in the Product Backlog requiring the completion of
missing features in one of the remaining Sprints.
At the end of each Sprint the actual velocity of each
team was computed considering only the stories that were
accepted by the Product Owner. The unstarted stories and
stories that were either rejected or newly defined by the
Product Owner were re-estimated in order to create a more
realistic plan for subsequent iterations.
Case study results
Results of the study are presented for each Sprint
separately in Tables 1 to 3. Data clearly confirm the
hypothesis that the plans are less accurate at the beginning,
but improve from iteration to iteration.
In the first Sprint the planned velocity estimates were
too optimistic and only one team out of 13 (i.e., team T04)
actually completed all functionality committed at the
Sprint planning meeting. The actual velocity of all other
teams was far behind the planned (mean value 11.00,
median 8.00). The teams completed on average only 42%
(median 35.71%) of story points planned and spent on
average much more than one ideal day of work per story
point (mean value 27.86, median 15.88 hrs/story point).
Analysis of results at the Sprint retrospective meeting
revealed two important reasons for such a great difference
between plans and actual achievement: (1) non-compliance
with the concept of ‘done’ and (2) insufficient communi-
cation with the Product Owner on the part of students.
125
Many stories that teams declared completed were rejected
either because of the Product Owner’s strict insistence on
providing fully tested, integrated and usable code or
because they did not fully match the user requirements.
Some teams complained that the non-compliance with user
requirements was due to user stories not being precise
enough in describing all the requirements details instead of
being aware that the details should be worked out in
conversations with the Product Owner. Therefore, all
teams were strongly encouraged to increase the commu-
nication with the Product Owner during the subsequent
Sprints and submit their user stories for review as soon as
they were completed, not waiting till the Sprint review
meeting.
Table 1. Planned and actual achievement in Sprint 1
Team Velocity [Story Points] Plan fulfillment
[%]
Work spent
[hours]
Hours worked per
Story Point
Planned Actual
T01 35.50 1.50 4.23 240.00 160.00
T02 30.50 11.00 36.07 141.00 12.82
T03 52.00 43.00 82.69 146.50 3.41
T04 13.00 13.00 100.00 74.00 5.69
T05 22.00 12.00 54.55 132.70 11.06
T06 23.00 8.00 34.78 127.00 15.88
T07 36.50 7.50 20.55 242.00 32.27
T08 14.00 5.00 35.71 103.00 20.60
T09 32.00 14.00 43.75 138.00 9.86
T10 25.00 6.00 24.00 126.50 21.08
T11 20.00 13.00 65.00 114.00 8.77
T12 25.00 7.00 28.00 134.50 19.21
T13 12.00 2.00 16.67 83.00 41.50
Mean 26.19 11.00 42.00 138.63 27.86
Median 25.00 8.00 35.71 132.70 15.88
Table 2. Planned and actual achievement in Sprint 2
Team Velocity [Story Points] Plan fulfillment
[%]
Work spent
[hours]
Hours worked per
Story Point
Planned Actual
T01 43.00 23.00 53.49 140.00 6.09
T02 46.00 31.00 67.39 255.00 8.23
T03 46.50 46.50 100.00 109.00 2.34
T04 20.00 12.50 62.50 160.00 12.80
T05 36.00 36.00 100.00 180.00 5.00
T06 33.50 23.00 68.66 170.50 7.41
T07 35.50 14.50 40.85 148.00 10.21
T08 36.00 35.00 97.22 181.00 5.17
T09 25.00 20.50 82.00 116.50 5.68
T10 40.00 26.00 65.00 137.50 5.29
T11 33.50 25.50 76.12 199.00 7.80
T12 33.50 21.50 64.18 155.00 7.21
T13 18.50 18.50 100.00 108.00 5.84
Mean 34.38 25.65 75.18 158.42 6.85
Median 35.50 23.00 68.66 155.00 6.09
Table 3. Planned and actual achievement in Sprint 3
Team Velocity [Story Points] Plan fulfillment
[%]
Work spent
[hours]
Hours worked per
Story Point
Planned Actual
T01 35.00 35.00 100.00 181.00 5.17
T02 34.50 31.50 91.30 175.00 5.56
T03 7.50 7.50 100.00 29.00 3.87
T04 15.00 14.00 93.33 94.00 6.71
T05 25.50 25.50 100.00 60.50 2.37
T06 36.50 30.50 83.56 116.10 3.81
T07 25.00 15.00 60.00 125.00 8.33
T08 20.00 20.00 100.00 98.00 4.90
T09 24.00 23.00 95.83 111.00 4.83
T10 29.50 22.50 76.27 93.00 4.13
T11 36.00 36.00 100.00 169.00 4.69
T12 23.50 23.50 100.00 106.00 4.51
T13 29.00 27.00 93.10 144.25 5.34
Mean 26.23 23.92 91.80 115.53 4.94
Median 25.50 23.50 95.83 111.00 4.83
126
Strictly following the aforementioned recommenda-
tions the difference between planned and actual
achievement diminished significantly in the second Sprint.
The actual velocity more than doubled and (in spite of the
fact that the planned velocity was unreasonably high) the
teams completed on average 75.18% (median 68.66%) of
story points planned. They spent on average 6.85 (median
6.09) hours per story point which was almost in line with
the concept of a story point being equal to 6 hours of work.
The initial problems and learning curves were to a great
extent mastered, and those teams that established good co-
operation among team members, improved testing and
integration, and delivered regularly user stories for
evaluation, fulfilled their plans completely.
In the third Sprint the teams estimated their velocity
to be approximately the same as in the second Sprint,
which proved to be the right decision (mean value 26.23,
median 25.50). The actual achievement was very close to
the plan (mean value 23.92, median 23.50). The teams
completed on average 91.80% (median 95.83%) of story
points planned and 5 teams achieved 100%. Two teams
(T03 and T05) completed all the stories planned for the
first release even before the end of the Sprint. On the other
hand, it became evident that the teams that had not
established good internal communication remained far
behind the plan (e.g., team T07).
The results of the study show that (in spite of over-
optimistic and sometimes unrealistic initial estimates) the
ability of estimating and planning quickly improves. Most
teams were able to define almost accurate Sprint plans
after three Sprints. In the third Sprint the velocity stabili-
zed and the actual achievement almost completely matched
the plan. Empirical data also show a continued increase of
productivity. These findings can be considered when
introducing Scrum into industrial software development.
Students’ opinions regarding Scrum practices
Students’ opinions regarding the importance of
particular Scrum practices for a successful project are
gathered in Table 4. Each practice was rated using a 5-
point Likert scale, the grade 1 indicating the practice was
not important and the grade 5 indicating the practice was
very important. In order to test the extent to which the
students’ judgments are consistent, the intra-class
correlation coefficient (ICC) was computed using the
absolute agreement type of the two-way random effects
model. The average measure reliability ICC value was
0.935, indicating that the survey data were reliable enough
to be generalized. The one-sample t-test was used to
determine how much students’ rates deviate from the null
hypothesis that their opinions were neutral having the
arithmetic mean value of all questions equal to 3. Results
in Table 4 show that all hypotheses were rejected;
therefore, we can accept the alternative hypothesis that
students considered all practices important.
Students rated highest team-work and good
communication among team members. Student teams that
established good communication and team-work indeed
achieved far better results than teams that acted as a group
of individuals.
Good communication with Product Owner received
the second highest grade which was not a surprise since the
Product Owner played a central role in students’ projects.
Projects’ progress to a great extent depended on his timely
answers to students’ questions and prompt evaluation of
user stories.
The concept of ‘done’ was also rated very highly
although we were afraid that the students would perceive
the Product Owner’s insistence on producing stable and
highly reliable code as an unnecessary pedantry. However,
it seems that through the project work they recognized that
only fully tested code that meets all user requirements can
be used in practice.
Table 4. Students’ opinions regarding the importance of Scrum
practices (N=51)
Mean Std.
dev.
One-sample
t-test
(p-value)
1
Team-work and
communication
among team members
4.82 0.44 < 0.001
2 Good communication
with Product Owner 4.72 0.45 < 0.001
3 Concept ‘done’ 4.52 0.68 < 0.001
4
Clarity of require-
ments specified in the
Product Backlog
4.28 0.67 < 0.001
5 Sprint Review
Meetings 4.20 0.76 < 0.001
6 Good ScrumMaster 3.94 0.98 < 0.001
7
Sprint Planning
Meetings and
maintenance of Sprint
Backlog
3.92 0.75 < 0.001
8 Sprint Retrospective
Meetings 3.74 0.92 < 0.001
9 Daily Scrum Meetings 3.72 1.03 < 0.001
10 Release planning 3.72 0.86 < 0.001
11 Accurate user story
estimation 3.56 0.95 < 0.001
12 Accurate velocity
estimation 3.54 0.89 < 0.001
Clarity of requirements specified in the Product
Backlog was ranked fourth with an average grade of 4.28
indicating that students consider a well prepared and
maintained Product Backlog an important factor affecting
the success of the project. During the project students
occasionally complained that the user stories should
contain a more extensive description. However, we were
trying to convince them that the essence of the agile
approach is not in writing detailed requirements
specifications, but in acquiring missing details through
communication with the Product Owner and end users.
The high importance of Sprint review meetings can
be deduced from the high grades accorded to
communication with the Product Owner and the concept of
‘done’. All these practices together enable customers to
127
experience on-time delivery of increments and obtain
frequent feedback on how the product really works.
The role of ScrumMaster was also considered
important, but not as much as the role of Product Owner.
We think this was because the teacher spent much more
time playing the role of Product Owner than being the
ScrumMaster. As a ScrumMaster he acted merely as a
facilitator giving student teams the freedom to self-manage
and self-organize as proposed by Scrum. Although he took
care that everybody followed Scrum and obeyed its rules
this role was less exposed than the role of Product Owner,
thus giving an impression of less importance.
The importance of other Scrum meetings was rated
between 3.72 and 3.92 which means that these meeting are
also considered important, but less than other Scrum
practices. We can attribute a slightly lower grade of these
meetings to the fact that students often perceive meetings
as an unproductive waste of time.
Planning and estimation practices were rated least
important (although still statistically significantly above
average), which was somewhat of a surprise since the
study paid a lot of attention to story estimation and release
and Sprint planning. Although the purpose of agile
planning is not to produce exact plans we think that
students underestimated the importance of this area. There
may be several reasons for such opinions. A previous study
on students’ perceptions of agile methods [22] has shown
that students feel least comfortable with planning activities
and have low trust in their estimates. Many students also
consider estimating and planning unproductive
administrative work not being fully aware of the
importance of good estimates and plans.
Limitations of the study
From the standpoint of using the results in industry
the main limitation of the study is that it was conducted
with students in an academic environment. However, in
order to increase the degree of validity every effort was
made to simulate an industrial environment as closely as
possible. User stories were defined on the basis of a real
student records information system used at the University
of Ljubljana and the study design strictly followed the
checklist for integrating student empirical studies with
research and teaching goals [12]. The Product Owner
strictly enforced the concept of ‘done’ requiring students to
produce fully tested and integrated code resistant to user
errors. The study relied on senior students enrolled in their
last semester, thus blurring the line between these students
and novice professionals. A previous study [23] has shown
that these students perform similarly to industry personnel.
Another possible threat to validity is that students
(due to other courses) could not work a normal workday,
but met for a Daily Scrum twice a week. Considering the
even distribution of the total course workload over 15
weeks each student was required to perform 6-8 hours (i.e.,
approximately one day) of work between two consecutive
Daily Scrum meetings, thus simulating the real workload
of a normal workday. The rest of the time the students
could use for other academic duties. Regular execution of
the Daily Scrum meetings worked fine encouraging
students to work consistently rather than procrastinate.
However, the 3-4 days interval between the meetings
provided some room for reallocation of workload allowing
students to work more than 8 hours between the two
consecutive meetings, which could lead to an uneven
distribution of effort over Sprints and skewed the statistics
concerning velocity in extreme case. We noticed such an
abuse on the part of the team T03, which reallocated a
substantial amount of work from Sprint 3 to Sprint 2 in
order to complete the project before the end of the course,
but this did not affect significantly the study results.
On the other hand, the results of the study in a great
deal depended on the proper role of the Product Owner. A
knowledgeable and responsive Product Owner contributed
a lot to smooth running of students’ projects and
consequently to better statistics regarding velocity and
ability of planning. A non-responsive and/or not
knowledgeable enough Product Owner could cause delays
and unproductive working periods.
Conclusions
Empirical studies with students as subjects can help
industry in providing evidence-driven assessment of new
processes, methods, and tools before their introduction in
software engineering practice. While most software
companies cannot afford extensive experiments, it is not a
problem to conduct a study with several teams working on
an almost real project within the framework of a software
engineering capstone course. In this paper we described an
example of such a study that concentrated on (1) the
assessment of abilities of estimating and planning when
using Scrum for the first time, and (2) gathering students’
opinions regarding the importance of particular Scrum
practices.
Results of the study have shown that the beginners
are able to almost completely grasp Scrum’s benefits after
a couple of Sprints. Their ability of estimating and
planning improved from Sprint to Sprint and after three
Sprints almost all teams were able to define accurate
iteration plans. The velocity also constantly grew, thus
indicating the improvement in productivity.
The study has also revealed the importance of the role
of Product Owner. Since the user stories serve merely as a
remainder for conversation all user requirements details
should be clarified in communication with the Product
Owner. In order to assure smooth running of a Scrum
project it is important that the Product Owner provides
timely answers to questions regarding details of user
stories, and makes quick evaluations of work completed
strictly enforcing the concept of a user story being ‘done’.
Students were overwhelmingly positive about the
course because it enabled them to learn agile methods
using project oriented approach, which also proved to be
successful in other areas of engineering, e.g., [24, 25].
Acknowledgement
The author is grateful to teaching assistants Luka
Fürst and Tomaz Hovelja for their help in conducting the
course and analyzing data concerning student teams’
performance.
128
References
1. Schatz B., Abdelshafi I. Primavera Gets Agile: A Successful
Transition to Agile Development // IEEE Software, 2005. –
Vol. 22. – No. 3. – P. 36–42.
2. Fecarotta J. MyBoeingFleet and Agile Software
Development // Proceedings of the Agile 2008 Conference. –
Toronto, Canada, 2008. – P. 135–139.
3. Scotland K., Boutin A. Integrating Scrum with the Process
Framework at Yahoo! Europe // Proceedings of the Agile
2008 Conference. – Toronto, Canada, 2008. – P. 191–195.
4. Laanti M., Salo O., Abrahamsson P. Agile methods rapidly
replacing traditional methods at Nokia: A survey of opinions
on agile transformation // Information and Software
Technology, 2011. – Vol. 53. – No. 3. – P. 276–290.
5. Ambler S. W. Has Agile Peaked? Let’s look at the numbers
// Dr. Dobb’s Journal, 2008.
6. VersionOne. State of Agile Survey 2010. Online:
http://www.versionone.com/pdf/2010_State_of_Agile_Devel
opment_Survey_Results.pdf.
7. Danubianu M., Socaciu T., Amariei, D. Distributed Data
Mining System for Tourism Industry // Electronics and
Electrical Engineering. – Kaunas: Technologija, 2010. – No.
3(99). – P. 3134.
8. Schwaber K., Beedle M. Agile Software Development with
Scrum. – Upper Saddle River, USA: Prentice–Hall, 2002. –
158 p.
9. Schwaber K. Agile Project Management with Scrum –
Redmond, USA: Microsoft Press, 2004. – 163 p.
10. Dybå T., Dingsøyr T. Empirical studies of agile software
development: A systematic review // Information and
Software Technology, 2008. – Vol. 50. – P. 833–859.
11. Dingsøyr T., Dybå T., Abrahamsson P. A Preliminary
Roadmap for Empirical Research on Agile Software
Development // Proceedings of the Agile 2008 Conference. –
Toronto, Canada, 2008. – P. 83–94.
12. Carver J. C., Jaccheri L., Morasca S., Shull F. A checklist
for integrating student empirical studies with research and
teaching goals // Empirical Software Engineering, 2010. –
Vol. 15. – P. 35–59.
13. Hilburn T. B., Kornecki A. J. Graduate Curricula in
Software Engineering and Software Assurance: Need and
Recommendations // Electronics and Electrical Engineering.
– Kaunas: Technologija, 2010. – No. 6(102). – P. 6770.
14. Jørgensen M. A review of studies on expert estimation of
software development effort // Journal of Systems and
Software, 2004. – Vol. 70. – No.1, 2. – P. 37–60.
15. Moløkken–Ostvold K., Haugen N. C., Benestad H. C.
Using planning poker for combining expert estimates in
software projects // Journal of Systems and Software, 2008. –
Vol. 81. – No. 12. – P. 2106–2117.
16. Mahnic V. Teaching Scrum through team–project work:
students’ perceptions and teacher’s observations // Internatio-
nal Journal of Engineering Education, 2010. – Vol. 26. – No.
1. – P. 96–110.
17. Moe N. B., Dingsøyr T., Dybå T. Overcoming Barriers to
Self–Management in Software Teams. // IEEE Software,
2009. – Vol. 26. – No. 6. – P. 20–26.
18. Mahnic V., Drnovscek S. Introducing agile methods in the
development of university information systems // Proceedings
of the 12th International Conference of European University
Information Systems (EUNIS’2006). – Tartu, Estonia, 2006.
– P. 61–68.
19. Mahnic V., Rozanc I., Pozenel M. Using E–business
technology in a student records information system //
Proceedings of the 7th WSEAS International Conference on
E–Activities. – Cairo, Egypt, 2008. – P. 80–85.
20. Grenning J. Planning poker or how to avoid analysis
paralysis while release planning. – 2002. Online: http://
renaissancesoftware.net/files/articles/PlanningPoker-v1.1.pdf.
21. Cohn M. User stories applied for agile software deve-
lopment. – Boston, USA: Addison–Wesley, 2004. – 268 p.
22. Melnik G., Maurer F. A Cross–Program Investigation of
Students’ Perceptions of Agile Methods // Proceedings of the
27th International Conference on Software Engineering. – St.
Louis, USA, 2005. – P. 481–487.
23. Runeson P. Using students as experiment subjects – an
analysis on graduate and freshmen student data // Proceedings
of the 7th International Conference on Empirical Assessment
in Software Engineering. – Keele University, UK, 2003. – P.
95–102.
24. Mihhailov D., Sudnitson A., Kruus M. Project–Oriented
Approach to Low–Power Topics in Advanced Digital Design
Course // Electronics and Electrical Engineering. – Kaunas:
Technologija, 2010. – No. 6(102). – P. 151–154.
25. Valdez M. T., Agreira C. F., Ferreira C. M., Maciel
Barbosa F. P. Teaching, Learning and Exploring the Use of
Project–Based Learning // Electronics and Electrical
Engineering. – Kaunas: Technologija, 2010. – No. 9(105). –
P. 117–120.
Received 2011 02 10
V. Mahnic. A Case Study on Agile Estimating and Planning using Scrum // Electronics and Electrical Engineering. – Kaunas:
Technologija, 2011. – No. 5(111). – P. 123–128.
We describe a case study that was conducted at the University of Ljubljana with the aim of studying the behavior of development
teams using Scrum for the first time, i.e., a situation typical for software companies trying to introduce Scrum into their development
process. 13 student teams were required to develop an almost real project strictly using Scrum. The data on project management
activities were collected in order to measure the amount of work completed, compliance with the release and iteration plans, and ability
of effort estimation, thus contributing to evidence-based assessment of the typical Scrum processes. It was found that the initial plans
and effort estimates were over-optimistic, but the abilities of estimating and planning improved from Sprint to Sprint. Most teams were
able to define almost accurate Sprint plans after three Sprints. In the third Sprint the velocity stabilized and the actual achievement
almost completely matched the plan. Bibl. 25, tabl. 4 (in English; abstracts in English and Lithuanian).
V. Mahnic. „Agile“ metodų taikymas projektų valdymui įvertinti ir planuoti // Elektronika ir elektrotechnika. – Kaunas:
Technologija, 2011. – Nr. 5(111). – P. 123–128.
Aprašoma „Scrum“ projektų valdymo sistema. Ši sistema naudojama Liublianos universitete programinės įrangos kūrimo procesui
organizuoti. Beveik realiems projektams įgyvendinti buvo sudaryta trylika studentų komandų. Bandant nustatyti atitiktį „Scrum“
procesams organizuoti buvo renkami įvairūs duomenys (darbo pabaigimo lygis, atitikimas planams ir kt.). Nustatyta, kad, bandant
ketvirtą kartą, pagal „Scrum“ metodologiją procesą galima organizuoti be klaidų. Bibl. 25, lent. 4 (anglų kalba; santraukos anglų ir
lietuvių k.).
... Scrum has been a widespread used agile method, along with other agile approaches [20,21]. The achievement of teaching goals and evaluation of students' performance in estimating and planning skills in Scrum-based projects is addressed in [22]. Also, students' perception of Scrum for the first time was studied in [15]. ...
Article
Gaining insight into what students experience in a course in software engineering is essential to the continuous development of the course design. The growing use of agile approaches in professional settings has facilitated their introduction into training and undergraduate courses in software engineering. This paper reports a case study of student participation in a course project by using a previously presented training model. We aimed to assess how students felt with the training model when conducting the 5 Scrum events: Sprint Planning, Daily Meeting, Sprint, Sprint Review, and Sprint Retrospective. To achieve our goal, we applied a 22-item survey to 31 undergraduate students to gather students’ opinions. Results showed that most students had a positive opinion about team communication, the position of Scrum Master, Sprint goals definition, and guidance using meetings as a means of checkpoints.
... Another thing we mention is that tasks are to be carried out by one student at a time as they emerge throughout the Sprint. Regarding user stories planning, we provide the students with the well-established group estimation technique called Planning Poker, which is recommended when using agile software development methods for estimating the size of user stories and developing release and iteration plans (Mahnič, 2012b). ...
Preprint
Full-text available
Scrum is one of the most used frameworks for agile software development because of its potential improvements in productivity, quality, and client satisfaction. Academia has also focussed on teaching Scrum practices to prepare students to face common software engineering challenges and facilitate their insertion in professional contexts. Furthermore, advances in learning technologies currently offer many virtual learning environments to enhance learning in many ways. Their capability to consider the individual learner preferences has led a shift to more personalised training approaches, requiring that the environments adapt themselves to the learner. We propose an adaptive approach for training developers in Scrum, including an adaptive virtual learning environment based on Felder's learning style theory. Although still preliminary, our findings show that students who used the environment and received instruction matching their preferences obtained sightly higher learning gains than students who received a different instruction than the one they preferred. We also noticed less variability in the learning gains of students who received instruction matching their preferences. The relevance of this work goes beyond the impact on learning gains since it describes how adaptive virtual learning environments can be used in the domain of Software Engineering.
... Another thing we mention is that tasks are to be carried out by one student at a time as they emerge throughout the Sprint. Regarding user stories planning, we provide the students with the well-established group estimation technique called Planning Poker, which is recommended when using agile software development methods for estimating the size of user stories and developing release and iteration plans (Mahnič, 2012b). ...
Article
Scrum is one of the most used frameworks for agile software development because of its potential improvements in productivity, quality, and client satisfaction. Academia has also focussed on teaching Scrum practices to prepare students to face common software engineering challenges and facilitate their insertion in professional contexts. Furthermore, advances in learning technologies currently offer many virtual learning environments to enhance learning in many ways. Their capability to consider the individual learner preferences has led a shift to more personalised training approaches, requiring that the environments adapt themselves to the learner. We propose an adaptive approach for training developers in Scrum, including an adaptive virtual learning environment based on Felder's learning style theory. Although still preliminary, our findings show that students who used the environment and received instruction matching their preferences obtained sightly higher learning gains than students who received a different instruction than the one they preferred. We also noticed less variability in the learning gains of students who received instruction matching their preferences. The relevance of this work goes beyond the impact on learning gains since it describes how adaptive virtual learning environments can be used in the domain of Software Engineering. ARTICLE HISTORY
... • The role of the development approach Diverse development approaches can be used for the DSL/DSML development: cascade, iterative, incremental, prototype, or agile approach [51]. In view of our research, the prototype and especially agile development [52,53] one is beneficial as implies the user involvement [45,54]. Even as the actual level of actual user involvement varies a lot, recognizing implementation of agility is important. ...
Chapter
The aim of a systematic reviews (SRs) is to gain a better understanding of a certain aspect of selected research field using the principle of classification of a large number of carefully selected articles. Selection of a proper set of articles is a crucial yet delicate task, which demands a large portion of tedious manual work. This article proposes to automate the screening of a large set of articles while conducting an SR. A rigorous approach is described, which conforms with the SR guidelines, and a tool to efficiently support such an approach is presented as well. The effect of approach is presented by a demonstration experiment which compares its results with the results of a classic manual screening. Finally, the recommendations for the proper use of the approach (i.e., the size of the pilot set and decision rule structure) are presented.
... Nach einer Fallstudie von MAHNIC konnten unabhängige Studenten-Teams ihre Zuverlässigkeit der Sprintzusage über drei Sprints hinweg von durchschnittlich 42% (Sprint 1) auf 92% (Sprint 3) steigern. Grund für diese Steigerung war das Bewusstsein, welche über die Gegenüberstellung von geschätzter und tatsächlich erreichter Velocity geschaffen wurde sowie die verbesserte Kommunikation zum PO zur Klärung der Anforderungen der Backlog-Einträge [11]. Um Transparenz über die Zuverlässigkeit der Sprintzusage zu schaffen, können verschiedene Kennzahlen und Tools herangezogen werden. ...
... When dealing with big data traditional solutions are not sufficient to make sure privacy and security of big data [13]. Access permissions, encryption schemes, transport layer security and firewalls can be broken; data can be unknown, anonymizes data also can be re-identified [6]. Because of above reasons advanced technologies and techniques are used to protect big data. ...
Conference Paper
The error messages displayed after compilation of MySQL query shows the MySQL error code, SQLSTATE value and text string in command prompt. The displayed error messages will lead an inconvenience to users who are willing to assess the full details of the errors. The proposed framework presents the design of pre-processor with attractive interactive user interfaces to reduce the ambiguity of the error messages generated after the compilation of MySQL query. The output of the proposed pre-processor gives the packed error details when an error occurs during the compilation of query and it shows clear error messages to the users instead of giving existing warning message in the command prompt. This will facilitate the users who are not an expert in MySQL and they easily tackle the type error message and where they occurred. The proposed pre-processor also provides a lot of interactive interfaces for handling databases and tables stored within the MySQL server as supporting elements for creation of queries generates Interactive text editor with intellisence facilities for users to minimize their careless or typing errors. Finally, the prototype of this pre-processor supports different types of queries with an expected error details and reduces the ambiguity of the warning messages displayed after the compilation of MySQL query.
Article
In the process of modern software development, an important role is played by software effort estimation. The failure or success of the projects is mostly based on the schedule outcomes and effort estimation accuracy. The effort estimation problem still remains as a challenging issue because of the limitations of various standard measures for forecasting the efforts in the plan‐driven software development. This article emphasizes on novel software effort estimation framework using heuristically improved hybrid learning model. This article proposes heuristically improved hybrid learning (HI‐HL) with deep belief network and artificial neural network for software effort estimation. The weight optimization strategy of DBN and ANN to attain highly accurate estimation. Here, the weight optimization is performed by integrating two standard optimization algorithms such as forest optimization algorithm and moth‐flame optimization, so called as solution index‐based forest moth flame optimization with the purpose of solving the fitness function concerning the “Magnitude of Relative Error and Mean Absolute Error (MAE).” From the table results, for dataset 1, the SMAPE of SI‐FMFO‐HI‐HL is correspondingly secured 60.75%, 34.26%, 56.77%, and 61.44% improved than ELM, LSTM, DNN, and fuzzy. The simulation findings indicated that the recommended estimation model outperformed the baseline approaches on the three publically available datasets.
Chapter
Earned value management (EVM) gauges the performance of a project against the initial plan, where budget and schedule information are provided upfront. It makes it easier for the project manager to take corrective actions by pinpointing the deviations in time and cost. Agile project management welcomes changes throughout the life of a project. Therefore, it is important to incorporate EVM with Agile to forecast scope. Several attempts have been made to integrate EVM with Agile at iteration and release level to forecast scope. However, those approaches faced the following four challenges: (i) Not knowing and incorporating the changing effects of Agile builds unrealistic project goals; (ii) the use of velocity as a metric for monitoring and controlling work is challenging because of the local nature of this metric; similarly, (iii) focusing on individual team and individual release is another challenge because it is a contrast with the large-scale implication of traditional EVM; additionally, (iv) the method of calculating “percent complete” at work item level is another issue because without an objective basis for counting this progress, projections at higher levels are called into question. To tackle these challenges, in this research, a novel approach has been proposed. The approach consists of three steps. Firstly, a systematic literature review is conducted for scope change influencing factors identification. Secondly, mapping of the identified factors with different elements of the Agile Software Project Scope Rating Index (A-SPSRI) is performed. In the final step, there is quantification, EVM integration and simulation of the universe of projects. The proposed approach has been used at the release planning phase when several agreed upon features are decided to implement their respective iterations. Unlike the one release one team method, and just relying on the velocity current approach, the universe of simulations is used with multiple teams to ensure the large-scale implication of AgileEVM. Moreover, the triad technique is used to gauge the completeness of features implementation in percentile with respect to the iterations.
Article
Full-text available
Earned Value Management (EVM) measures project performance against a baseline plan. It identifies deviations in budget and schedule, aids project managers in taking earlier corrective actions against cost and schedule overruns. Although the literature highlights the significance of scope by adopting it as a leading indicator to measure project success or failure. However, EVM does not include scope when evaluating the performance of any software project. While considering the importance of scope and its ever-changing nature, it is imperative to measure the effect of changes in scope on the project plan. To analyse such effects, this study aims to enhance the traditional EVM by incorporating scope into it. The main objectives of this paper are: i) to extract the effects of project scope changes, ii) to map extracted effects of project scope changes with Software Project Scope Rating Index (SPSRI) elements, and iii) to quantify the extracted effects and integrate them with EVM. An extensive literature review is conducted to achieve the first objective, which results in the seventeen unique effects; that were used to map with SPSRI elements. To forecast the variations in scope for a given project budget, Monte Carlo simulations were run on the top eight scope elements, whereas, the results were incorporated with EVM to identify the deviations between actual and projected values of scope’s score and cost. Finally, the multivariate regression model was used to evaluate the influence of individual element on the overall estimated cost of the project. The correlation between the independent variables (SPSRI elements) and the dependent variable (overall cost) was calculated along with the valuation of each independent variable on the dependent variable. Moreover, the effects are statistically shown that independent variables have influenced the dependent variable. This technique could assist the project managers to forecast deviations in project scope earlier.
Article
Full-text available
We describe the implementation of the student records information system at the Faculty of Computer and Information Science of the University of Ljubljana that provides remote access of data to different categories of users (viz. administrative staff, students, teachers, and their assistants). The system offers extensive functionality covering the following areas: enrolment, examination records, degree records, and various statistical surveys. Additionally, a special maintenance module was developed that enables the maintenance of all data required for the proper functioning of the system. All functions are accessible through World Wide Web, thus requiring only a Web browser on the user's side. Oracle Portal has been selected as the most suitable development environment and appropriate security policy was defined in order to minimize the risk of misuse of data and assure safe communication. For monitoring the use of the system a special data webhouse has been built containing clickstream data about each user activities.
Article
Full-text available
We consider a problem of low-power synthesis of digital systems, which are described as a Finite State Machine (FSM). In this paper, we apply FSM decomposition technique to organize the network as a collection of alternatively working components, thus greatly reducing the switching activity of the circuit (dynamic power management). To make a decision of decomposition task more tractable, corresponding CAD tools were developed at Tallinn University of Technology. Software tools are implemented using Java technology making them compatible with a wide range of operating systems and allowing a possibility for the remote access. Actually, developed system presents interconnection of CAD tools with e-learning methodology. The primary output of this work is the development of laboratory environment that provides students with extensive hands-on opportunities to enhance their knowledge and understanding of advanced concepts and principles in low-power digital design using FPGA technology and FPGA design suits. This can add a certain level of realism to the learning experience and helps to boost student's motivation.
Article
Full-text available
The customer reads a story to the team. Two guys are involved in discussing the impact of the story on the system. Reluctantly, an estimate is tossed out on the table. They go back and forth for quite a while. Everyone else in the room is drifting off, definitely not engaged. The discussion oscillates from one potential solution to another, avoiding putting a number on the card. When the discussion finally ends, you discover that the estimate did not really change over all that discussion. You just wasted 20 minutes of valuable time. You have 25 more stories to estimate, you don't want to make a career of release planning. Extreme programming employs two levels of planning, iteration planning and release planning. Iteration planning is short term and very detailed. Iteration planning is a good time to get into the details of how to implement the story. Release planning is a higher-level plan with a long-range time horizon. During release planning, the team is taking a less precise and longer-term view of the project. There is usually a long backlog of stories. The release-planning objective is to get a ballpark estimate of the effort to build the product, and to split the product into interesting release. Precision of individual estimates is not the goal. Determining the project scope is. Story estimates are just what their name implies. They are estimates. Some estimates are over-estimates. Some are under-estimates. Every now and then, the estimates turn out to be just right. The team is looking out far, at many stories, including ones that will never be implemented. It is OK to be less precise. Why invest in precision before it is needed? A deck of fairly accurate estimates are better than a pair of very precise estimates (and these probably are not that precise anyway). The team should be trying to get good at using the intuition, their gut. Don't be cavalier about the estimates, but speed is important if the team wants to finish the meeting and get back to building the product.
Article
Full-text available
In order to prepare students for increasing use of agile methods in industry, teaching these methods is becoming an important part of the Computer Science and Software Engineering curricula. So far most attention has been devoted to Extreme Programming and its practices, but there is not much evidence about teaching Scrum, in spite of the fact that Scrum is one of the most widespread agile methods. In order to fill this gap a course was developed at the University of Ljubljana that not only teaches Scrum through a capstone project, but also serves as a study regarding the learnability and applicability of Scrum. We describe the course details and analyze students' perceptions and teacher's observations after teaching the course for the first time in the Spring semester of the Academic Year 2008/09. Student surveys showed that they were overwhelmingly positive about the course and confirmed the anecdotal evidence of Scrum's benefits reported in the literature.
Conference Paper
Full-text available
Education in academic institutions of higher education is not an easy task, with engineering students needing to be competent in the contents areas as well as in a generic way. This paper describes the implementation of a strategy of the PBL model applied to design a curriculum unit of Electric Power Systems Project (EPSP) of the Electrical Engineering course. This curriculum unit aims to provide students with knowledge to design, model, analyze, and project interior and exterior lighting systems. The results show that students have really benefited from the experience of actually working as members of a team rather than learning using conventional classes.
Article
Background: Many empirical software engineering studies use students as subjects and are conducted as part of university courses. Aim: We aim at reporting our experiences with using guidelines for integrating empirical studies with our research and teaching goals. Method: We document our experience from conducting three studies with graduate students in two software architecture courses. Results: Our results show some problems that we faced when following the guidelines and deviations we made from the original guidelines. Conclusions: Based on our results we propose recommendations for empirical software engineering studies that are integrated in university courses.
Book
Agile requirements: discovering what your users really want. With this book, you will learn to: Flexible, quick and practical requirements that work Save time and develop better software that meets users' needs Gathering user stories -- even when you can't talk to users How user stories work, and how they differ from use cases, scenarios, and traditional requirements Leveraging user stories as part of planning, scheduling, estimating, and testing Ideal for Extreme Programming, Scrum, or any other agile methodology ----------------------------------------------------------------------------------------------------------Thoroughly reviewed and eagerly anticipated by the agile community, User Stories Applied offers a requirements process that saves time, eliminates rework, and leads directly to better software.The best way to build software that meets users' needs is to begin with "user stories": simple, clear, brief descriptions of functionality that will be valuable to real users. In User Stories Applied, Mike Cohn provides you with a front-to-back blueprint for writing these user stories and weaving them into your development lifecycle.You'll learn what makes a great user story, and what makes a bad one. You'll discover practical ways to gather user stories, even when you can't speak with your users. Then, once you've compiled your user stories, Cohn shows how to organize them, prioritize them, and use them for planning, management, and testing. User role modeling: understanding what users have in common, and where they differ Gathering stories: user interviewing, questionnaires, observation, and workshops Working with managers, trainers, salespeople and other "proxies" Writing user stories for acceptance testing Using stories to prioritize, set schedules, and estimate release costs Includes end-of-chapter practice questions and exercisesUser Stories Applied will be invaluable to every software developer, tester, analyst, and manager working with any agile method: XP, Scrum... or even your own home-grown approach.ADDISON-WESLEY PROFESSIONALBoston, MA 02116www.awprofessional.comISBN: 0-321-20568-5