M A S A R Y K UNIVERSITY

FACULTY OF INFORMATICS

Gamification in the S C R U M Software

Development Framework

MASTER'S THESIS

Be. Martin Češka

Brno, autumn 2015

Declaration
Hereby I declare this thesis is my own piece of work, which I elaborated

individually. A l l sources of information and literature that I used during elaboration

of this thesis are properly cited while providing full link to the source document.

Thesis supervisor: Bruno Rossi, Ph.D.

ii
Acknowledgement
I would like to thank the supervisor of my thesis, Bruno Rossi, for helpful advices,

patience during my busy times and for providing right leads and guidance when I

was heading i n wrong direction. I would also like to thank my family for all the

support they have given me.

iii
Abstract
This thesis focuses on motivation increase of team members using S C R U M
framework during product development. Since S C R U M is a quite complex
framework and its main principles include keeping on framework rules, it is
important for this framework efficiency to keep all team members motivated
enough to behave as intended. Gamification is a tool for driving desired behaviour,
so it is an ideal candidate to be used for S C R U M users' motivation increase.

For good understanding of whole framework, there should be defined all the
framework rules and principles. This requirement w i l l be covered by the first part
of the theoretically aimed chapter. Besides framework itself, there should be also
described principles of gamification, tool which is intended to be used for
motivation increase. Therefore its description w i l l follow. Gamification is not the
newest term and it already has been implemented a lot of times, so there w i l l be also
mentioned several already made implementations.

Implementation of gamification into S C R U M environment is fully theoretical

task. To made this thesis more practical, I decided to include also creation of SW
prototype (fully functional SW would be too difficult), which w i l l demonstrate the
result. Prototype is not an ideal solution for testing of gamification success, so I have
also decided to include a questionnaire, which w i l l answer if modified framework
can do the intended result - increase team members' motivation.

Keywords
Agile, SCRUM framework, software development, motivation increase,

gamification, benefits, rewards

IV
Content
1 Introduction 4

1.1 Problem description 5

1.2 Problem statement 6

1.3 Thesis statement 6

1.4 Approach to solving stated problem 6

1.5 Thesis content 7

2 Agile development and S C R U M 8

2.1 Software development 8

2.2 Classical vs Agile development 8

2.2.1 Waterfall model 8

2.2.2 Rational Unified Process 10

2.2.3 Agile approach 12

2.3 S C R U M framework 15

2.3.1 Roles 16

2.3.2 Product Backlog 18

2.3.3 Planning 21

2.3.4 Iteration cycle 25

2.3.5 Development support 28

2.4 S C R U M modifications 31

2.4.1 Kanban board 31

2.4.2 Integration of X P principles 33

3 Gamification 36

3.1 Definition 36

3.2 Types 37

1
 3.2.1 Internal gamification 37

3.2.2 External gamification 38

3.2.3 Basic game elements 38

3.2.4 Game vs. gamification 40

3.3 Gamification in the SW development 41

3.3.1 Gamification in the Agile learning tools 41

4 Gamified S C R U M framework 47

4.1 Gamified S C R U M design 48

4.1.1 Gamification elements integration 48

4.1.2 Other modifications 54

4.2 Prototyping tool 56

4.3 Prototype implementation 57

4.3.1 United appearance 57

4.3.2 Homepage 57

4.3.3 Product backlog 60

4.3.4 Sprint board 62

4.3.5 Meetings 63

4.3.6 Sprint review 64

4.3.7 Team page 65

4.3.8 Personal page 69

4.4 Questionnaire 73

4.4.1 Respondents 73

4.4.2 Set of questions 73

4.4.3 Results 74

5 Conclusion 76

A Appendix 81

2
B Appendix 83

C Appendix 84

D Appendix 85

3
1 Introduction
The Agile approach defines several rules for software development as an
alternative to traditional project management. This approach and
corresponding methods have evolved in the last few decades. P D C A cycle
creation, in the 1930s, can be considered as the beginning of the Agile approach
[1]. Through time, many new methods appeared - Toyota production system,
Lean, S C R U M , Kanban, and many others [2]. The Agile approach has started to
spread into many kinds of industry including software development, replacing
classical approach in cases, where the Agile approach is more suitable and
effective. The final form of this approach has been established in 2001 by leading
experts [3]. It has many advantages against the original approach, which is a
documentation driven and heavyweight software development process. Lots of
software companies use agile development practices for new product creation
in these days. Still there are many cases, in which the original approach is better.

One of the well-known Agile approaches and probably the most used is
called S C R U M . S C R U M is a framework which describes practices, artefacts and
meetings which should be used in the development process (not only for
software development). This framework is based on being disciplined and
keeping order. Rules of this framework should be kept on by every member of
the development team. S C R U M even uses the special role - S C R U M Master, a
framework rule keeper and controller [4].

Gamification is defined as the use of game thinking and game mechanics in

a non-game context. Its purpose is to engage people in solving problems and to
drive desired behaviours [5]. This can be interpreted as motivation increase. In
case of people's motivation, there can be distinguished two main types: intrinsic
(task or activity is undertaken for the pleasure of doing it) and extrinsic (doing
something because we expect or require an external reward) [6]. Gamification is
basically focused on extrinsic type of motivation [7].

In the S C R U M environment, where keeping rules is very important, there is

a big need for some way to motivate the development team to keep on these

4
 rules. It is not an easy work to continuously maintain team's morale on high
level for not breaking them. Therefore there has been already made several
attempts for motivation increase in agile teams [8]. Problem of members'
motivation makes S C R U M framework the ideal candidate to be integrated with
gamification principles for the purpose driving members' behaviour - keeping
on framework rules.

1.1 Problem description

As mentioned in the previous section, the S C R U M framework is based on being
disciplined and keeping order. People are not the same. Some are hard-working,
always trying to do their best, but there are also others, who do just what they
need to keep their jobs. Nevertheless, most of people do not want to do anything
what they consider to be unnecessary, if they do not have any profit from that
[9]. It follows that main problem lies in people's motivation.

Besides that, problem of S C R U M is also in its complexity. There are a lot of

rules not only for roles in the team, but also for events, which should be held,
artefacts, which should be created and maintained up-to-date during whole
development and also practices which should be executed for reaching the goal
in form of the product created by the S C R U M team. There is also a need of
continuous collaboration with customer / future user (meetings, user stories
definition, changes, etc.). Whole framework complexity w i l l be described in
detail in the chapter no. 2.

S C R U M is created and assembled for the purpose of higher efficiency in

creating product which suits the customer requirements as much as possible.
When workers are motivated to strictly use S C R U M framework, it can have very
positive impact on their work efficiency, so it is very important to motivate the
whole S C R U M team.

5
1.2 Problem statement
Based on the content of previous sections, this thesis should contain answer to
the following question:

1. How to increase SCRUM team members' motivation to keep on the rules of the
S CR UM framework ?

1.3 Thesis statement

The main goal of this thesis is to implement the gamification principles into
S C R U M framework in the way that w i l l motivate people in every team role to
keep on the rules of this framework during product development. Motivation
increase in the software development is a topic, which has large potential in
practise. Therefore this thesis should also contain creation of prototype of
gamified S C R U M application as a draft for possible real application which
would be useful in a real development environment.

1.4 Approach to solving stated problem

M a i n goal of this thesis is solution for motivation increase of S C R U M
development team. A s stated in previous sections, to solve this issue,
gamification, as a tool for driving desired behaviour, is an ideal candidate to be
used. Gamification has already been used for many times, so it is convenient to
review several examples of such implementations. These reviewed examples
can be a good source of information for own gamification integration design.
Adaptation of gamification principles into S C R U M framework should form the
core part of this. Success of motivation increase by designed SCRUM
gamification can be then evaluated through a questionnaire.

6
1.5 Thesis content
This thesis w i l l start with a theoretical part - it w i l l contain a description of both
core terms: S C R U M framework and gamification. Thesis is about implementing
of gamification into S C R U M , so framework should be described first.

Description of S C R U M framework w i l l form the chapter no. 2. S C R U M is a

software development framework, based on Agile approach, so the beginning
of this chapter w i l l contain description software development and differences
between classical and Agile approaches including its advantages and
disadvantages. S C R U M itself can be split into several topics, which w i l l form
subsections of S C R U M framework description: individual S C R U M roles
(product owner, S C R U M master, team member, customer and project manager),
product backlog, planning, iteration and development support (tools). S C R U M
description w i l l be followed by list of its possible modifications.

Description of gamification w i l l form the chapter no. 3. This chapter w i l l

begin by gamification definition and description of main gamification types and
principles including comparison to game. Last part of this chapter w i l l be
reviewing current gamification implementations related to software
development.

The practical part w i l l form the chapter no. 4. This chapter w i l l contain three
main parts: design of framework changes by implementing gamification and
other useful principles, implementation of prototype and questionnaire
evaluating thesis success.

7
 Agile development and S C R U M
This chapter serves as main introduction of the Agile approach and S C R U M .
For the better understanding, chapter is divided to several sections, that step-
by-step describes the S C R U M framework from its base.

1 Software development
The first computer using program, which was stored in computer memory,
appeared in the 1940s [10]. The software development started those years. Both
computers and software have evolved in really impressive ways since 1940s.
Computers are in almost every house and many people use them every day for
both work and entertainment purposes in these days.

When developing a new software, it is always very hard to determine all the
user or customer requirements, which should be implemented. First software
development models, such as waterfall model (first published in 1970 [11]), have
defined that requirements are determined as a first step of the whole software
development process, while in Agile approach you do not need to know every
detail. Nevertheless many developed software products were finished in the
different form and functionality than was in real expected by the customer [12].

2 Classical vs Agile development

For better understanding of differences between classical and Agile approaches,
it is appropriate to describe one of these approaches. I have chosen two of them
- the Waterfall model and Rational Unified Process.

2.1 Waterfall model

Waterfall model has name based on the original meaning of this word - the
model has a shape of waterfall. It has several phases, which are executed one-

8
by-one, as it represents progress of water falling down from the rock - you
cannot go back to previous phase.

Typical phase list is following (Royce's model [3][13]):

1. Software requirements elicitation

In this phase, there is a need to capture all the requirements for developed
software product. These requirements are typically written down into a
document.

2. Analysis
A l l the requirements are analysed. Based on that, models and schemas are
created. There are also defined some business rules coming out of defined
requirements.

3. Design
In this phase, the software architecture is defined, as well as list of
modules, interface, data structures, design patters, etc.

4. Implementation
Based on the outputs of design phase, software is started to be
constructed. In this phase, software is coded, verified, and tested by
deployed unit and integration tests.

5. Testing
After the main implementation is done, the software product is debugged
and systematically tested to be sure, that it fulfils all the requirements and
does not cause lots of bugs or errors.

6. Operations & maintenance

This is the last phase of waterfall model and starts, when the software
product is fully functional and ready to be deployed into real
environment. This phase consists of software installation. If necessary, it
can also consists of migration, support or maintenance.

9
2.2.2 Rational Unified Process
Because of difficulty and complexity of software requirement definition, the
development models had to evolve. After some time, i n the late 1990s, the most
known classical approach to software development - The Rational Unified
Process (RUP) has been created [13]. Since R U P is a very complicated method
and does not form the core of this thesis, this subsection contains only basic
information about RUP.

The R U P process captures some of best practices i n software development [14]:

1. Developing software iteratively
2. Requirements management
3. Usage of component-based architecture
4. Modelling and UML
5. Managing configuration and changes

R U P defines 30 roles based on their activities, categorized into six main groups:
1. The Analyst Roles (Business-Process Analyst, Business Designer, System
Analyst, and Requirements Specifier).
2. The Developer Roles (Software Architect, Designer, User-Interface Designer,
Capsule Designer, Database Designer, Implementer and Integrator).
3. The Manager Roles (Project Manager, Change Control Manager, Configuration
Manager, Test Manager, Deployment Manager, Process Engineer and
Management Reviewer).
4. The Tester Roles (Test Analyst, Test Designer and Tester).
5. The Production and Support Roles (System Administrator, Technical Writer,
Graphic Artist, Tool Specialist and Course Developer).
6. The Additional Roles (Reviewer, Review Coordinator, Stakeholder and Any
Role).

The R U P life-cycle has four main phases. The whole process starts by
Inception phase, then it continues to Elaboration phase, after that starts
Construction phase and it all ends by Transition phase. M a i n difference between
these phases is i n disciplines which are performed.

10
 List of disciplines:

1. Business Modeling,
2. Requirements,
3. Analysis and Design,
4. Implementation,
5. Test,
6. Deployment,
7. Configuration and Change Management,
8. Project Management,
9. Environment.

A l l of these disciplines are performed during several phases and there is

always, with small exceptions, more than one of them performed i n any
moment. Phase boundaries are formed by milestones.

List of phases and milestones (displayed in figure 1):

1. Inception (Phase)
2. Lifecycle Objective (Milestone)
3. Elaboration (Phase)
4. Eifecycle Architecture (Milestone)
5. Construction (Phase)
6. Initial Operational Capability (Milestone)
7. Transition (Phase)
8. Product Release (Milestone)

Inception

•Ends by
f Elaboration
• E n d by
3 \ Construction

•Ends by Initial
\ Transition

•Ends by
-

lifecycle Lifecycle operational product

objective architecture capability release
s *

Figure 1 - Phases of Rational Unified Process

11
2.3 Agile approach
The main characteristics of the R U P and other similar approaches are
complexity and creation of large documentation. These methods are great for
creation of complicated and complex software (SW). However, there is no need
of such a complex approach for creation of every type of SW. The world is
changing very quickly and too complex and detailed documentation is not
always so useful and necessary approach. That was one of the reasons for Agile
approach creation.

A l l methods based on Agile approach have few common characteristics. A s

can be seen in figure 2, the major difference between classical and Agile
approach lies in the main SW development project characteristics - Agile
approach (on the right) is based on having fixed time and resources for project
while classical approach (on the left) is based on having fixed functionality for
the final product.

functionality FIXED time resources

time resources VARIABLE functionality

Figure 2 - Difference between classical and Agile approach

In 1990s there has been several approaches different from classical approach,
which had a few similar characteristics. This lead to meeting of 17
representatives of approaches like Extreme programming, S C R U M , D S D M ,
Adaptive Software Development, Crystal, Feature-Driven Development,
Pragmatic programming and other alternatives [15]. O n this meeting they had
written down some main principles, which were shared by all named
approaches. They all signed this document and so Agile Manifesto was born
[16].

12
Four main ideas of Agile approach are described in Agile Manifesto [17]:

1. Individualities and interactions over process and tools.

It is a known fact, that cooperating group is always more effective than
group of individuals. Y o u can have a greatly supported team by defined
processes and useful tools, but if they do not cooperate with each other, it
can cause a lot of troubles.

2. Working software over comprehensive documentation.

It looks good to have a large book describing whole required functionality
for SW product, but even if you spend a large amount of time by
requirement definition, you w i l l never be able to perfectly describe
everything. It is always better to spend more time by development and
communicating with customer about his real needs (not those written on
paper). That is w h y Agile approach uses user stories - stories describing
required functionality from user point of view.

3. Customer collaboration over negotiation.

The product should always be made for the customer. People are not the
same, so if customer has need of some functionality, it does not always
mean, that he is able to handover his idea to the supplier, so that supplier
understand it in the same way as customer.

That is w h y there is a need of customer collaboration during the

development. Supplier can better understand customer needs and
sometimes even propose better and more effective solution. This is a
reason for not spending too much time by requirement negotiation - to
spare it for better purpose. A n d if you use collaboration possibility in a
good way, you can have customer very satisfied. It is no secret that
satisfied customer is the best one you can ever have.

4. Responding to change over following a plan.

The world is continually changing as well as customers. Y o u can have
precisely defined all the requirements for product, but it does not mean,
that the customer requirements w i l l not change during the development,
or when the customer sees the final product.

13
 It is always better to be prepared for possible changes. It is also convenient
to describe details just for the most important parts and the rest during
the development, when it is necessary.

These ideas are based on twelve main principles of Agile SW development [18]:

1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self-organizing
teams.
12. At regular intervals, the team reflects on how to become more effective, than tunes
and adjusts its behaviour accordingly.

The Agile approach means iterative and incremental development with

short iterations. It allows to create SW in parts, so that there is a better possibility
for the customer to be kept updated about the state of development. Customer
is also able to react on any misunderstanding with his expectations or
requirement more quickly. Customer can also be pretty calm, that the final
product w i l l be as expected.

14
 Because of short iterations, the product changes really quickly. Therefore it
is necessary to continuously verify the product functionality. Tests should be
automated and prepared in advanced to the implementation part. In case of any
product change, the whole tests set should be applied.

.3 SCRUM framework
S C R U M is one the most favourite frameworks for Agile Software Development.
It has been introduced by Ken Schwaber and Jeff Sutherland in 2001 [19]. Name
of this framework is based on formation of players in rugby. The S C R U M
framework defines roles, events, artefacts and rules for the development.

S C R U M is built on three main pillars:

1. Transparency:
A l l involved persons should share same language when talking about
S C R U M aspects
Definition of "Done" and other terms should be same for S C R U M team
as well as for the customer.

2. Inspection
- S C R U M artefacts and sprint progress should be controlled regularly.
Controlling should not significantly interfere with daily work.
Those performing the inspection should be familiar with the point of
work.

3. Adaptation
- Product must be within acceptable limits.
- Requirements can change during the process.

Inspection and adaptation are performed during Sprint planning, Daily

S C R U M , Sprint review and Sprint retrospective.

15
3.1 Roles
S C R U M is a framework aimed on development i n the team environment. For
this purpose, this framework defines several roles, in which team members
performs defined activities.

Product owner

Customer is replaced by the role of product owner i n S C R U M . His main

responsibilities are definition of the product and communication between
developers, customer and company. He defines priorities and decides which
functionality is more important and which does not have to be done. His main
interest is keeping the business value of the product as high as possible.

Product owner is the owner of product backlog (see below). He does not
have to be alone for this work. There can be other people helping h i m like
representative of customer, potential user, software architect, User Experience,
etc.

The product owner is not always available for the S C R U M team. His minor
work should be communication with customer, so that he could transfer
customer needs into well defines requirements for product development. His
responsibility is to ensure, that everyone (customer, developers, management)
knows, what the developing software is about, what is the actual state of
development and what w i l l follow.

SCRUM master

Even though the S C R U M team should have been self-organized, the role of the
S C R U M master is really important. He is not a typical team leader, but he works
as a connection between the developing team and any interruption from
outside.

His main responsibilities are:

- helping the team to achieving its goals,

removing all problems,

16
 team motivation,
- protection against outer interruptions.

S C R U M master controls if all the principles of S C R U M are kept to. He should

be coaching all team members to help them i n their personal development. He
should be communicative, sensitive and he should remove all disagreements
and conflicts i n the team.

This role should never been combined with the product owner. However,
one S C R U M master can work i n multiple teams. It is common i n cases, where
teams are well established and works together for some time. In these cases,
there should not be necessary to have a S C R U M master i n every team on full-
time basis.

SCRUM team

Agile approach is based on frequent feedback and communication as well as on

team cooperation. Given the fact that customer does not know all the details of
product which he needs, the developing team should be as adaptable as possible
by itself. Team has to understand the customer, his needs, environment and
problems. They should need to know, how the customer is going to use the
product.

Team has also need to work as unit. A n y mistake is always problem of the
whole team and not of one member. They should respect and trust each other.
If the team does not cooperate well inside, it always has an impact on its
efficiency and quality of their work.

Team has the right to decide about all the main aspects of development, but
they need to know, that their decision has consequences. They need to be
accountable for their decisions. But they should still keep to S C R U M principles.

A l l members should be replaceable. If someone gets sick, there should be

way how to finish his work. You can have an expert for something i n your team,
but everyone should know at least something of his know how. In that case, the
team can better react to unexpected incidents and is much more flexible. That is

17
 also, w h y the trust is very important. Y o u should not be worried about knowing,
that others are familiar with your know-how and that you are replaceable.

Team is mostly made of testers and developers. There should not be so big
difference between these positions. Testers can work with developers as well as
developers can test work of others. In the same way, the testing of finished work
should not at the end of iteration, after almost every function is programmed.
Testers should work all the time. For example, they can create unit test from the
beginning of each iteration. This is also connected with the team meaning. If
programmers finish their work too late and testers do not have enough time to
approve the work, it is a problem of the whole team.

Customer

Based on Agile approach, customer should be involved in S C R U M more than

in rigorous methods. He should be involved in the whole development process,
including changes and prioritization. Customer should be ideally the part of the
team in the role of the product owner or he can be represented by someone from
the developing company. In that case, customer should be in contact on daily
basis with him.

Project manager

S C R U M does not include the role of the project manager, but it does not mean,
that there cannot be one. He just would not be delegating tasks and managing
the team, but he can still be preparing reports and controlling the project.

3.2 Product Backlog

You need to have a plan i n every project. In the S C R U M , there is a product
backlog for this purpose. A l l items in this list should represent some
functionality of the required product, which means anything bringing some
benefits to the customer. This list is the responsibility of product owner in
S C R U M framework, but it should be accessible to everyone.

18
 Every item i n this list should contain ID, name, user story, acceptation
criterions, review comments, test information, attachments, estimates and
priority.

User story

Items in the product backlog are called user stories. The functionality should be
in these stories described from the view of the customer and should be as simple
as is possible. User stories are created to describe the business value of the
product for customer. They should ideally contain information about which
user wants what functionality and what business value it w i l l bring him.

User story has its format written in its name - it should be written as a story.
It should contain whole sentences and not just connected words. A l l other
details should be in the head of the product owner. Every user story should meet
the INVEST criteria (see below).

Acceptation criteria

User story should contain information about what conditions it has to

satisfy in order to be accepted by customer. These criteria are defined by
the product owner based on discussion between h i m and the S C R U M
team. They should be known before the start of the sprint.

Done criteria

Except for criteria important to customer, there should be also criteria

defined by the S C R U M team for determination if the user story is finished.
These are known as done criteria. It means that all tests were created and
were also deployed without any error, functionality has been properly
documented and the user story itself has been successfully deployed.

Invest

There is a common rule for all the user stories. They should all meet the INVEST
criteria. INVEST is a word made from first letters of six relevant words:

19
1. Independent
User stories should not be dependent on each other. The product should
not be split into parts based on technology (like database, front-end, back-
end, etc.). It should be divided to parts based on the functionality, so that
the customer is able to see results on every Sprint demo (see below). It is
quite hard process to divide the product in such way, but it w i l l definitely
pay off in the development process.

2. Negotiable
A l l user stories should be explainable and describable. Product owner
should be able to describe every user story to team so that they clearly
understand it to estimate the right amount of effort. There should be
defined who want what and what is its purpose. Product owner has to be
able to tell stories and live for the product. It is the only way in which he
w i l l be able to truly understand to the customer.

3. Valuable
User stories should have some business value for customer. Every
customer needs only things which brings h i m any value. If not, there is
no reason for creating such functionality. Not only customer, but also
developers should understand the business value of every user story. It is
better for their understanding of need for that functionality and its
purpose.

4. Estimable
In S C R U M , team estimates effort needed for creation of all user stories.
That is reason why all user stories should be written clear and simple so
that every team member can easily understand them. There should not be
any doubt that something important is missing or hidden.

5. Small
Team has to be able to finish the user story in less than half of the sprint.
If not, there always exists a way how to split given story into smaller
pieces. It is always better to have lot of small parts which are finished i n

20
 few days than large function unit, which we can mark as finished after
several month. It helps to determine the development progress.

6. Testable
It is about the ability of the team to determine if given user story is
finished. It means that there are well defined acceptation criteria and user
story is understandable enough.

Super and epic stories

In the first attempt of user story definition, there are usually some of the stories,
which can and should be divided into smaller pieces. These stories are too large
and complex to be properly estimated or do not meet the Invest criteria.

In that case, story which has been defined can be called as super story or epic
story. When dividing the product functionality, division should be made
hierarchically. Top level contains epic user stories and between these and
common user stories there can also be some super stories. Epic stories are
something like software modules and super stories are something like more
complex and less specific user stories.

3.3 Planning

Prioritization

When having all user stories defined, there is a necessity of decision which user
stories should be completed first, which can wait and which are probably not
needed at all. This decision is made by the Product owner.

This decision should be made mainly on the basis of customer needs.

Product owner should ask the customer about which functionality he things is
the most important for him, what he really needs, what brings h i m the biggest
value and what is not so important.

This prioritization can be made just at the start of the development or there
can be meetings at the start of every sprint. The second option is better, because

21
customer can change his opinion during the development and he would be
more satisfied with the final product if it would meet his current requirements
instead of the obsolete ones.

Estimation

In Agile approach the estimates are made in relative units called points and by
whole S C R U M team. M a i n advantage is that more opinions means more precise
estimates. Points mentioned above mean, that the estimates are about
complexity and difficulty of the user story and not about the time which is
needed for its implementation, testing and completion.

During the estimations we need to understand the stories. If not, we should

take account of it in the estimates. In that case, estimate value can be really high
or even infinite (see below).

At the start of estimation process, we can use really simple method for
estimation of super and epic user stories, which w i l l help us to better
understand to differences in complexity between these stories. This method is
based on sizes of t-shirts in clothes shops. Values are XS, S, M , L and X L . One
story is chosen as a reference for some value and others are estimated based on
this referential one.

Planning poker

The most known and used method for estimations is Planning poker. As
mentioned above, estimations are made by the whole S C R U M team and
estimated values are in relative units (not working hours needed for
functionality creation, testing, etc.).

Planning poker is based on a poker card game. The main advantage of this
method for time estimation is that participant estimates are not affected by the
opinions of other involved people. Every participant has his own card deck.
Estimations are made in iterations (one or more iteration for every user story).

22
Typical process of estimation for one user story:

1. The Product owner presents the user story to SCRUM team.

2. All participants can ask some questions about that particular user story.
3. Participants choose a card from their deck and let them unrevealed.
4. After everyone has made his choice, all participants reveal their chosen cards.
5. Cards have typically these values: 0, V2,1, 3,5,8,13,20,40,100, infinity, coffee,
and question mark. If participant chooses a cards with number, it means that this
number is his estimate. If he chooses card with infinity, he did not understand, or
the user story is too complex. If he chooses question mark, than he has some
question which has to be answered. The card with a coffee is for too long
estimations, when some break is needed.
6. After revealing of all cards, the proper action is performed. There are 3
possibilities:
7. Somebody choose card with question mark. All questions are answered, and whole
process is repeated from step number 3.
8. Somebody choose card with coffee. Estimation is paused for a break and then it
continuous from step number 3.
9. Somebody choose card with infinity, so whole process is repeated from the start
and Product owner is trying to better explain the whole story, or he can divided
into smaller stories.
10. Everyone choose card with number, but all estimates are not the same. In that
case, participants who choose cards with the smallest and biggest number tells
the others their opinion on why they have chosen so different number then others.
After that, process is repeated from the step number three.
11. Everyone choose card with number and their estimates are the same. Process
continues.
12. Estimated number is assigned to the particular user story.
13. Process continues from the step number lfor the next user story.

23
Story sizing

Except for planning poker, there are other methods for estimations making. One
of them is called Story sizing. It is about sorting stories based on their
complexity and then assigning estimates.

Estimation process of the Story sizing:

1. Product owner read all user stories.

2. SCRUM team chooses the user story, which is in the middle from view of its
complexity
3. Product owner picks another user story and team decides it is more or less
complex than the first one
4. Product owner picks one of left-over user stories and team places it between
already placed stories. Step is repeated with another one.
5. When all stories have been placed, team assigns them values of estimations based
on their order.

Team estimation game

One of other methods for user story estimation is called Team estimation game.
It is similar to the Story sizing method. First all user stories are ordered and then
the estimates are assigned to them.

Estimation process of the Team estimation game:

1. One of the team members picks one user story, reads it and places in the middle.
2. Another team member pick any other user story, reads it and places it to the right
or left based on its complexity and difficulty.
3. Team members take one's turn and can do one of the following actions:
a) team member does noting (order of all placed stories is OK and there is no
missing user story),
b) team member places another user story (order of all placed stories is OK and
some user stories are still missing)
c) team member changes order of one placed story (order of placed stories is not
OK)

24
 4. All stories are placed and nobody wants to change order of any of them. Sorting
part ends.
5. Values of estimates are assigned to all user stories (based on their order).

2.3.4 Iteration cycle

Sprint

Division of the development process into iterations is one of the main principles
of the Agile approach. In the S C R U M , every iteration is called sprint. Sprints are
relatively short cycles of same length. A t the end of every cycle, some
functionality is presented to customer, so he is better informed about the
progress and can quickly react if the product development goes in wrong
direction.

Figure 3 - Scheme of SCRUM process

25
 I have already mentioned that sprints are relatively short. They should be
long enough for developers to finish some functionalities. Length of sprints
should also reflect the length of the project and customer character. If there is a
strong assumption of frequent changes, sprints should be shorter. O n the other
hand, if the customer has defined his requirements very properly, sprints can
be longer. The recommended length is from 1 to 4 weeks. Whole iteration cycle
is displayed below.

Sprint planning

At the start of every sprint, there has to be some actions performed before the
development start. The S C R U M team has a meeting, on which they decide
which user stories w i l l be completed during that sprint. This planning meeting
should not be longer than 8 hours [21] [20].

When planning amount of work for the sprint, S C R U M master, as a team

leader, should be able to estimate how much of work can be done. S C R U M
master can use the Velocity graph for this purpose (see below).

Whole team is deciding about the goal for particular sprint. A l l user stories
in the Product backlog have assigned priority and also estimate, so it should not
be hard to decide what stories should be completed. Chosen user stories are
moved from Product backlog to Sprint backlog. Planning ends when all team
members agree on the Sprint backlog.

Sprint backlog

Sprint backlog contains all the user stories chosen to be completed during
current sprint. Stories which have not been completed goes back to the Product
backlog after end of the sprint.

Daily SCRUM

Every day, typically from the start, there should be held a meeting of all team
members. This meeting is called Daily S C R U M . It should be quite short meeting,
so participants of this meeting be standing the whole time.

26
 Daily S C R U M is about handing over of information about current work of
every team member to others. The format of this meeting is that every person
has just about minute or two for informing others about answer to three simple
questions:

1. What was I doing yesterday?

2. What am I going to do today?
3. What problems have I been dealing with?

During this meeting, the S C R U M master is editing contain of the S C R U M board

(see below).

SCRUM board

This board should be located in the team room, and should contain information
about development progress in form of three columns filled with user stories of
the current sprint. These columns are named: Backlog, In progress and Done.

Figure 4 - SCRUM board example

At the start of every sprint, all user stories intended to be finished in that
particular sprint are written into Backlog column. When some team member
picks a story, which he w i l l be developing, the story is moved into In progress

27
 column. When the story meets Acceptation and Done criteria, it is moved into
Done column.

Backlog Grooming

Typically, it is not necessary to define everything at the start of the sprint. There
exists Backlog Grooming, which is the meetings between product owner and
S C R U M team. Team clarifies the required functionality or can evaluate
unevaluated stories on these meetings.

Sprint Demo

A t the end of every sprint, there is a meeting called Sprint demo. It is a meeting
of whole S C R U M team, Product owner and Customer. A l l the finished user
stories in the current sprint are presented to the customer. It is very important,
that only completely finished user stories are presented.

Best case scenario is that user stories are presented by team members who
finished them. There should be showed the functional product performing
required user story and not just told the confirmation of finished story. It is
important because you can gain a very useful feedback from the customer on
this meetings.

3.5 Development support

Burndown chart

As a team, you should be able to know your status in the development of the
product as well as missing functionality. Based on that you should be able to
determine if the project w i l l be finished on time. Burndown chart is a great
example of reaching this need.

It is a column chart, which displays how much of the product has been
finished in every sprint. Sprints are represented by columns. Height of the
column shows how much of the work is still needed to be done. Height is
displayed in points, which are (as previously explained) relative values of effort

28
needed for user stories development. More the work is done, lower the column
is.

O n the example, which can be seen in figure 5, you can easily estimate based
on the progress displayed by column height that the product should be finished
at the end of the fifth sprint.

There is always a possibility that something goes wrong, so there can be also
used any auxiliary line for prediction of worst case scenario. That should show
the probable date of product completion.

120

Figure 5 - Burndown chart example

Velocity graph

At the end of every sprint, the team sums estimations of every user story
finished in current sprint. The sum represents speed of the S C R U M team. A n y
unfinished user stories are not counted and moved back into Product backlog
or next Sprint backlog.

There should not be differences between several sprints in sequence. Reason for
not having similar values can be either new team or to small amount of user
stories. Stories should be divided into more pieces in the second case.

29
 The value of velocity is important for time estimation and sprint planning. If
you have a number of points representing average sprint finished work, you can
easily estimate how much work can be done in the next sprint.

25

20

15

10

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprints Sprints

Figure 6 - Velocity graph example

Retrospect

Retrospect is one of the common Agile practices. It is highly efficient tool for
gaining feedback, which can be used for team efficiency improvement. It is very
important to use retrospect frequently (at least once in every sprint).

There are several stages in retrospect:

1. Introduction
This stage includes reminding rules of retrospect, walking through
activities from last retrospect and program confirmation.

2. Data collection
Collection of data from current stage - what is going well as well as issues
which has to be dealt with.

3. Deep information understanding

Attempting to identify all the causes and understanding them.

30
 4. Brainstorming
Participants are trying to find a solution (reactions on discovered issues).
Reactions has to be confirmed by all participants.

5. Summarization of concrete data

Summarization at the end of the retrospect. There should be repeated all
the defined reactions.

.4 SCRUM modifications
S C R U M is a very sophisticated and complex framework. Still, it can be
improved by several different modifications. Some of them are described in this
following subsections.

.4.1 Kanban board

Kanban is one of Agile development methods. It is lightweight and uses some
good principles, which can improve software development process. One of
them is using a board [22], which is partly similar to S C R U M board mentioned
in chapter 2.3.4.

The Kanban board is more sophisticated. There are more columns than just
Backlog, In progress and Done, which leads to better understanding of current
state of all user stories. Kanban board specifies these ten columns (with
comparison to S C R U M framework):

1. Inbox
This state is for user stories, which are determined, but not defined in
detail.

2. Specification
When the Product owner specifies user stories, they are i n the
specification state.

31
3. Ready for development
After the user story is defined and described, it goes to this state, which is
comparable with state of being in Product backlog and waiting to be
assigned to some sprint in the S C R U M framework.

4. Development - planned
When user story is assigned to a sprint, it moves to this state, in which it
waits until it is assigned to a person to be implemented. This state is same
as a Backlog state on the S C R U M board.

5. Development - in progress
This state represents implementing functionality by the developer
(programming) before it can be tested.

6. Development - done
This state means that the user story has been implemented by assigned
developer and waits for control.

7. Code review
In this state, written code is controlled, if it is correct. This phase can also
consist of refactoring.

8. Test locally
User story is then tested in the local environment by unit tests and other
tests.

9. Test on preproduction
If the user story get through local tests, it is also tested i n the
preproduction environment, which represents real use.

10. Ready for release

This state represents same state as Done on the S C R U M backlog. This state
means that there is no obstacle to release the functionality described in the
user story.

32
4.2 Integration of XP principles
Extreme programming (XP) is one of the well-known Agile practices [23]. X P
uses some techniques, which are not the part of S C R U M framework, but can fit
in, because both these methods are based on the Agile approach.

Pair programming

More people = more knowledge. That is the main idea of pair programming.
Two people are sitting in front of the same computer. One is writing a code and
the other one is thinking, controlling and gives ideas. There is less space to do
any mistake and it can speed up development. Pair programming should be
used on user stories, which require creativity and unusual solution [24].

This method can also improve team cooperation. Team members know each
other better which makes whole team more unified. This method should be used
also as kind of an icebreaker, teambuilding activity or for team efficiency
improvement. Pairs should not stay at the same composition.

Unit tests

Unit tests are the base of XP. There are two simple rules for using unit tests in
XP:

• to write unit tests before writing code of the actual program,

• to write unit tests for all parts of the program code (all functionality must
be covered by unit tests).

It makes the implementation phase simpler, because you can easily find out,
which part of code is broken and where to look for some bug. It also improves
team member's ethics - all must keep those rules for better team efficiency.

Test-driven development

Test-driven development (TDD) is quite similar to Unit tests. This software

development process is based on the idea of creating tests, which represent how

33
the software should work, before writing the code. T D D has these several
phases [25]:

Figure 7 - Test Driven Development process

1. Write a test
In this phase, developers create test, which controls some functionality,
typically based on the user story. This test should cover all possibilities,
so if it does not fails, code is written well.

2. Check if it fails
Test is being deployed to check, if the functionality has already been
implemented. If the test succeeds, developers start to write another one.
If it fails, it means that functionality is not fully implemented, so the
process continues.

34
 3. Write production code
In this phase, developers implement required functionality, so that all
tests w i l l be successful.

4. Run all tests

When the required functionality is implemented, all tests are deployed. If
at least one of them fails, code has to be edited. If not, process continues.

5. Clean up code
In the last phase of the process, written code is controlled and refactored.
Process continues from the beginning with a new test.

This chapter described Agile approach and S C R U M development framework.

Information from this chapter should mainly serve as a knowledge base for
understanding S C R U M framework - its principles, possibilities and differences
from other methods. There is no other new information about S C R U M in the
following chapters.

35
 Gamification
This chapter contains all information about gamification important for the
purpose of this thesis - its definition, types, elements and review of already
finished relevant implementations.

The term gamification has been firstly introduced by Nick Pelling in 2002 [26].
However, gamification and its principles has started to widely spread from 2010
(can be seen on picture below) [27].

2005 2007 2009 2011 2013 2015

• Gamification • SCRUM

Figure 8 - History of frequency of word search on Google search

.1 Definition
Different sources present different definitions for the term gamification. Here
are some of them:

• "The use of game design elements in non-game contexts" [28].

• "The process of game-thinking and game mechanics to engage

users and solve problems" [29].

• "The use of game attributes to drive game-like player behaviour in

a non-game context" [30].

• "The use of game mechanics, dynamics, and frameworks to

promote desired behaviour" [31].

36
 I personally prefer my own definition: "Gamification is the use of game
mechanics, principles and elements in a non-game context, to drive desired
behaviour".

.2 Types
Gamification can be divided into two main types: internal and external [32].
These types are based on the target group of people, on which the gamification
principles are focused in the particular case.

,2.1 Internal gamification

Internal gamification is focused on motivation of internal employees in some
company, so that it targets the internal processes, into which it integrates game
elements. It mostly leads to gaining points by employees for their finished work.
Based on the amount of gained points, they can be rewarded for being among
employees with the most points. Competition can be focused either on
employees or teams. Internal gamification has several possible types of use in
the internal environment:

1. Company development
Gamification can be used for increasing employee's motivation to engage
in questions of company innovation or for making change management
more efficient (people would be motivated to adapt).

2. Human resources improvement

Gamification can be used for the hiring process. People can be more
motivated to apply for a job and company can better address people with
desired skills. Hiring process can contain some tasks and challenges,
which would reveal these facts. It can also speed up the process of new
workers integration by motivation.

3. Work efficiency
Gamification can motivate people to work harder. Its use can increase
product sales, production efficiency or product innovation motivation. It
can also improve internal communication and work environment.

37
 4. Employee education
Gamification can be very easily used for purposes of employee education.
It can help for motivating employees to participate in all kinds of training
courses or for gaining new knowledge or certificates. It can be also used
inside the course, to motivate people not only to participate, but also to
get actively involved.

2.2 External gamif ication

External gamification is customer oriented. It is mainly used in marketing and
sales strategies. External gamification focuses on building strong connection
between customers and company. External gamification has several main uses
in relation to the customer:

1. Propagation
Gamification is very often implemented into the web pages to motivate
visitors to be more interested in a brand and to spend more time on these
pages then they normally would. Visitors are being guided through
whole sites content.

2. Education
Gamification does not have to be used only for education of company
employees (see subsection 3.2.1) but also for educating external people. It
is mainly used in e-learning courses or as a part of the software user
guides.

2.3 Basic game elements

In the definition, I have mentioned that gamification uses game elements. They
are the base of the whole gamification process. Here is a list of these elements
[33]:

1. Profile
A user is a part of the system. Profile is the element which identifies every
user in the system. It typically includes personal information about user,
such as his name, photo, birthday, email address, city, etc.

38
2. Avatar
A n avatar is in comparison with profile more anonymous. It can contain
user nickname, his picture (usually not a personal photo, but some picture
which reflects user personality) and can contain also an email, or other
information.

3. Experience points
Experience points are points gained for some experience of working with
a system in some way. These points reflect user activity in a system. More
the user uses a system, the more experience points he gets.

4. Eevels
Levels are another indicator representing user maturity in the system use.
Levels typically increase with passing some experience points boundary.
Gaining levels should be more difficult than gaining points.

5. Progress bar
A progress bar is a best option of displaying the progress in effort of trying
to reach some goal. It is typically a rectangle which displays current state
of how far is the user in trying to reach higher level by filled part of this
rectangle.

6. Badges
When user reaches some goal, he is likely getting some reward. Badges
are made for this purpose. Badges are typically awarded for practising
some activity, or completing some tasks of same type, etc. They should be
of different meaning than experience points and levels.

7. Interactive money
Like experience points, users can also be rewarded with interactive
money, which they should be able to spend for some real goods, like
cinema tickets, etc.

8. Rewards
Besides interactive money, users can be rewarded with real things
directly.

39
 9. Leaderboard
For increase of users' motivation for system use, it is good to show the
users, how they stand among others. Everyone likes to be the best, so
users would try harder to get to the top.

2.4 Game vs. gamification

Gamification is a term, which comes from the word game, but gamification itself
is not the same. The main difference between gamification and games is i n
the difference of their purposes. Game is aimed on people who want to play and
have fun, while gamification is about increase of users' motivation to drive some
desired behaviour for non-game purpose.

Games are mainly focused to be enjoyed. They uses same principles like
gamified environment, but games does not have mainly any other purpose then
just to entertain its players. The exceptions are serious games. Their purpose is
not only to entertain players, but also to solve some real-world problem i n a
form of simulation. These games are quite similar to gamification, but still not
the same, because they are made i n a form of game, which gamified
environment is not.

Karl Kapp, professional i n the game industry, who devote himself to

difference between these two terms, says that serious games are subarea
gamification. He says that if you have any activity on which you apply game
mechanics it is a gamification. [34]

It is not an easy task to define borders between gamification and game,

especially in some rare cases. The border can be sometimes really tight. From
my point of view, game is a user environment, which uses gamification
elements i n a way to entertain people, so serious games are still games, even
though they have also other purposes. Gamification on the other hand can use
same elements and principles, but it mainly focuses on users' motivation and
not their entertainment. There can still be some cases in which it is not so easy
to define if it is game or gamification.

40
.3 Gamification in the SW development
Gamification is about using game mechanics in non-game context. Software
development companies produce thousands of games every week, so this part
of industry has the closest relationship with game mechanics. There has been
many different implementations of gamification into different software
products. Especially web applications are the centre of this phenomenon in
latest years (see previous section).

.3.1 Gamification in the Agile learning tools

From the definition, gamification is a great tool for people interest increase. That
is w h y the gamification has become very often used in the teaching software
products. This thesis goal is creating the platform for gamified S C R U M
development, so tools which have been created for increasing people interest in
some Agile and S C R U M principles, as a learning tool, can be a great source of
inspiration for gamification of the S C R U M . Here are some examples of such
tools:

The Daily SCRUM Game [35]

It is a quick game to practice the daily S C R U M activity. It is created to be

challenging to make S C R U M master work facilitated. There is 8 roles based on
S C R U M roles and personas types ( S C R U M Master, somebody who does not
work at all, somebody working a lot, joker, etc.).

The meeting should not last more than 10 minutes. During this meeting
everyone need to answer 3 basic questions: what he did yesterday, what he
plans on doing today and what roadblocks he has. Meeting should be also
disrupted by the message to the S C R U M Master, that one of the user stories is
urgently needed to be handled.

Meeting should be a very chaotic disaster. A t the end, participants should

write a feedback. It should be followed by analysis of what happened. There are
several questions that should be answered:

41
 H o w far through the ten minute timebox did the team get? If they did not
get through, w h y not?
Did everyone answer the three questions?
Who was providing their answers to the team versus who was talking to
the S C R U M Master only?
Was it clear to everyone who was working on what?
- Could everyone be heard?
H o w did the S C R U M Master handle interruptions to the flow?
Did the S C R U M Master find a balance on having just the right amount of
information flowing?
Was anyone working on something that was in the "Done" column or on
items in the backlog?
H o w was the noisy bystander handled?
H o w was interruption to the S C R U M Master handled?
H o w was the urgent item handled?

SCRUM Resort Brochure [36]

There has to be at least 4 participants in this game. A l l must agree on a wish list
for what they would like to see in a brochure for their ultimate resort. Using
index cards, teams must then write user stories for the brochure. The team's
elected Product Owner must then prioritize each story by sorting these stories.

Iteration is set for 3 days, where each day is represented by 4 minutes (the
total of 12 minutes) and days are separated by meetings. Before start of the
iteration process, the team selects stories which they think that they can
accomplish by the end of the first iteration. The team also defines acceptance
criteria for every chosen story and they transfer these stories into tasks. Tasks
are placed on the S C R U M board into column planned.

O n every daily meeting participants move tasks over to the 'Done' column
and volunteer for tasks by moving them over to the 'In progress' column. After
the S C R U M meeting, each member should start producing in accordance with
the acceptance criteria. Whole iteration should end with a demo of their

42
progress and a retrospective. In retrospective each team lists what they did well
and what they can improve for the next iteration.

SCRUMKnowsy [37]

This game is created to test the player knowledge about S C R U M . It is based on

questions from different parts of S C R U M framework. For every question there
are several answers and player goal is to sort them based on the preference.

SCRUMKnowsy game has one really big catch. It is not about being right in
the way that you have all the answers in the right order, because it is nearly
impossible. Game is based on comparison of your answers with answers of
people, who are the most important for S C R U M , like Jeff Sutherland, Jim
Coplien, etc. Every one of them has different answer order for one particular
question. It means that choosing the exactly same order like the person
comparing with is really not a main goal of this game. Player gets points based
on similarity of his answer order with compared person.

SCRUMKnowsy has also multiplayer mode for whole team based on the
same principles. Its purpose is to make the whole S C R U M team more educated
about S C R U M framework.

RedCritter Tracker [38]

RedCritter Tracker is probably the most similar product to the intended SW

prototype (see chapter 4). It is a real gamified Agile development environment.
This application works with user profiles. This tool is made for managing
several projects in the S C R U M framework.

Gamification is based on personal profiles of every S C R U M team member.

If anyone reaches some work success, it may gain h i m some badges. Badges can
be gained also by whole team. Except for budges, team members can also gain
points for store. They can buy for them some discounts for sport events, coffee,
etc. It helps to the team members' work motivation.

43
 This application is really easy to use and can be used as a good inspiration,
but it lacks of some necessary features. Possibilities are really limited either from
gamification point of view or from S C R U M framework required features.

SCRUM simulation with LEGO bricks [39]

S C R U M simulation with L E G O bricks is probably one of the most known games

for S C R U M framework principles explanation. This game is designed to
demonstrate the cooperation between several S C R U M teams. It is appropriate
that there is between 10 to 20 participants. They should be divided into groups
of 4 to 6 people.

Group trainer should play the role of product owner. He explains all items
in product backlog. A l l items should mean some building, which can be built
from available L E G O bricks. Teams then do the estimations and plan first sprint.

After the sprint there should be a Sprint review, in which all teams evaluate
the difference between planned and finished amount of work. There should be
mentioned that whole group performance is more important than performance
of individual teams.

You sunk my methodology [40]

This game is really simple. It focuses on big advantage of Agile approach - the
importance of reaction on change and work division into sprints. Y o u sunk my
methodology is played by two players. It is based on sinking battleships game.
One player has the list of his steps prepared i n advance while the other one does
not.

Obviously, the first one w i l l probably lose the game, because unlike the other
one, he cannot react on current situation, but must keep on the planned list of
steps. It is a great game for understanding the importance of reaction on changes
and iterative development.

44
Summary

A l l previously mentioned tools for S C R U M learning or practising, are not the

only ones. Nevertheless I have chosen those, which suits the purpose of this
thesis the best.

Not all of mentioned tools are implementation of gamification principles.

Some of them are just games serving as a learning tool for better understanding
of S C R U M and Agile principles. But still, all of them can be used as a good
inspiration for creating more complex S C R U M gamified tool.

TOOL N A M E BASIC INFORMATION

The Daily S C R U M Game
S C R U M Resort Brochure
SCRUMKnowsy
RedCritter Tracker
L E G O bricks simulation
You sunk my methodology
S C R U M Master meeting ability game
Sprint process game
Knowledge game of S C R U M
Gamified S C R U M environment
S C R U M simulation game
Learning Agile benefits game

Figure 9: Tool summary table:

This chapter described the term gamification and all related information.
There was described what gamification means, what are its types, what
elements it includes and what current implementations relevant to topic of this
thesis has already been done. Following chapter deals with creation of gamified
S C R U M framework design. It w i l l be created based on all the above mentioned
information including this subsection. S C R U M gamification w i l l be based on
elements described i n the subsection 3.2.4 with taking their current usage
described in this subsection into consideration.

Some of motivation principles described in this subsection can be useful as

an inspiration for the gamified S C R U M design. In the tool called Red Critter
Tracker, motivation by rewards and benefits is used. From my point of view, this
type of motivation (free tickets, discounts, etc.) can really increase users'
motivation. Except for the practicing part, there are also good ideas for the
learning part. Part of the gamified S C R U M development environment can
contain learning tools, like description texts, questionnaires and videos

45
describing S C R U M and its principles (similar to the logical example used in You
sunk my methodology). However, gamified S C R U M design in the following
chapter will not contain the design of framework part, which would serve as
framework learning tool.

46
4 Gamified S C R U M framework
This chapter contains core part of whole thesis - design of gamified S C R U M
framework. There is described implementation of individual game elements
and other modifications into S C R U M framework, in a way, in which they
increase motivation of framework users. Chapter also contains implementation
of application prototype which represents designed changes. Last part of this
chapter is dedicated to questionnaire for purpose of designed changes
evaluation.

The main purpose of this thesis is to integrate gamification into S C R U M

framework, in a way, that it w i l l increase motivation of all team members to use
S C R U M framework properly. S C R U M is defined in a way, that it is necessary
to motivate whole team as a unit. Therefore most of the framework
modifications are aimed on the S C R U M development team and not on
individuals. Team members should not really compete with each other, but they
can compete with other teams. Team success can always be a good motivation
element for all team members.

Besides changes described in the summary of subsection 3.3.1, there are

some other possible framework modifications and improvements (see
subsection 4.2.2). Reviewed learning tools and S C R U M team support
applications (see subsection 3.3.1) does not use all useful gamification principles
and are often aimed just on one part of S C R U M and not the whole framework.
This allows the opportunity to create a tool, which is more complex and for
purpose of this thesis more relevant, than currently existing solutions.

Several researches about gamification success in driving desired behaviour

already exist [41], [42], [43]. Gamification does not necessarily mean success [44].
It also depends on the form of gamification integration, used elements and
target domain.

A l l of reviewed applications have integrated only some of gamification

elements. It supports the idea mentioned above, that it is not a best approach to
just use some of main gamification principles and think that it w i l l solve all

47
 problems. It can have bad impact on the result of gamification implementation.
To make gamification really work and be efficient, usage of game elements has
to be thought out. Implementation of game elements into S C R U M framework
w i l l be described in detail in section 4.1.

.1 Gamified SCRUM design

S C R U M framework is based on the team effort more than on individualities.
Regarding this fact, whole modified S C R U M framework including gamification
principles has to be aimed more on the team effort than on individual S C R U M
practitioners / system users. This section w i l l describe gamification integration
as well as other modification of the S C R U M framework.

,1.1 Gamification elements integration

This subsection contains information about gamification elements integrated
into gamified framework. Elements has been chosen to increase user's
motivation as much as is possible, but efficiently (if some element would not
have a strong effect, it has not been chosen). Justification of element usage is
described below every one of them.

User profile

Every user regardless of his role should have his own profile. Profile is good for
user identification and emphasis on his uniqueness. Profile should contain all
necessary information about corresponding person. Besides main data like name
and contact information, there are other relevant information, such as person's
roles, expertise, skills and results corresponding to his activities and work i n
S C R U M environment (see below).

Team profile

Since S C R U M is basically framework for working team, there should be also a

profile for every S C R U M team i n the gamified environment. Team profile

48
should contain information about projects, it has been working on, its members,
its results and evaluation (gained experience points, team velocity, gained badges, etc.).

Both user and team profiles can sometimes have a need to express their
current feelings, mood or just to announce some success or troublesome issue.
Possibility of publishing the profile status, for both user and team, is an ideal
feature of gamified environment.

Avatar

Avatars are best way of visual team or person identification. This is w h y every
person or team profile should have among attributes of profile photo/image as its
avatar. Avatar can also be represented by real photo, but not everyone likes
having his photo everywhere someone requires. This avatar picture can be used
as chance for self-realization by using any image, which would characterize
themselves / team.

Experience points

For the purpose of users' motivation, effort spent by using S C R U M framework

has to be rewarded. Gaining experience points is a very useful way of user's
evaluation for the purpose of reward system. Experience points should be
received during whole development for users or teams' achievements and
keeping on the framework rules. A s a motivation tool, experience point should
be gained only for relevant activities. Framework gamification is designed to
contain these point-gaining possibilities:

1. Poin ts for work time

Teams and its members get experience points for every week working in
the environment using S C R U M framework. Prototype is designed to give
every person 20 points for every week spent in the team assigned to some
project, as well as 20 points for every S C R U M team with the same
condition (assigned project). This w i l l favour persons / teams who
actually practise the S C R U M and not only using the system.

49
 2. Points for finished user stories
Every user story should be evaluated and its completion rewarded. M a i n
parameter of this evaluation type is sum of really finished (state Done)
user stories compared to sum of user stories planned to be finished during
current sprint. Both team and its members get 0 to 50 points according to
ratio mentioned above for every week spent in previous sprint, after it
ends.

3. Poin ts for keeping of the framework ru les

There are some rules of S C R U M framework, which should be kept on.
M a i n rule, and the only one, which can be rewarded, is organizing Daily
S C R U M every working day. If S C R U M master connects into the system
and fill notes from the meeting every day, team gains 20 points for every
week in such sprint after it ends.

4. Points for efficient work

If sprint ends and all finished user stories from sprint backlog are
approved by product owner, team gets 10 points multiplied by average
product owner evaluation of customer satisfaction for every week of such
sprint.

Previously mentioned 4 types of gained experience points follows, that both

team and users can gain 100 points at maximum for every week. Points are
always added to the team / person sum of points after end of every sprint - same
amount for every week of such sprint. Person / team sum of points always
contain only points from last 20 week, so no one can have more than 2000 points.
This approach w i l l ensure need of continuous effort for not easing up on the
gaining of experience points.

Progress bar

People always like to see their progress in visual form and not just as a number,
so the framework should also contain a progress bars which display how much
experience points user / team currently has and how much points is left.

50
Badges

Team / user evaluation by experience points is a good approach, but there can
be done more for their motivation increase, such as system of gaining badges
for some achievements. There exist lots of opportunities, for which users and
teams can gain some badge. Badges are evaluated regularly - as mentioned at
every badge description. Gamified S C R U M framework should contain at least
these team badges:

• Hard workers:

A l l sprints of given team i n last 4 month has been completely finished

(with no undone user stories). Evaluated once in 4 months.

• Meeting professionals:

A l l daily S C R U M meetings i n last 4 month one project have been held -

every day, except for team vacation days. Evaluated once in 4 months.

• Stable workers:

Velocity of sprints in last 4 month with small deviation (less than 20%).
Evaluated once i n 4 months.

• Completion masters:

A l l user stories of one project has been finished before end of the project.
Evaluated after end of every project.

• Customer importance:

Product owner is satisfied with the team work. (Average product owner
evaluation is 90% or more). Evaluated once i n 4 months.

• Done is done:

There is no returned user story for reason of not meeting requirements

(change is an exception, does not count). Evaluated once i n 4 months.

51
 A l l mentioned badges are valid for whole team. Except for team badges,
there is possibility of gaining also user (team members) badges. Here is a list of
badges for programmers / testers:

• Done is done:

No user story implemented by given user during last finished project has
been returned by product owner for not meeting requirements. Evaluated
once in 4 months.

• Customer expert:

Average product owner evaluation of user stories implemented by given

user during last finished project was more than 90%. Evaluated once i n 4
months.

• Can do attitude:

Every user story which has been assigned to given user has been finished
(approved by product owner) before end of the sprint (during last
finished project). Evaluated once i n 4 months.

• Responsible worker:

Given user has been present at every daily scrum when not having
vacation. Evaluated once i n 4 months. Need of connection with time sheet
system.

• Quality master:

Given user implemented more than 90% of user stories i n the last finished
project without return from testers. Evaluated once i n every 4 months.

• True developer:

Given user has ratio between sum of implemented and tested user stories
from 0.8 to 1.2. Evaluated once in 4 months.

S C R U M master, as a team leader, is responsible for some of main team

badges, so as the team gains these, S C R U M master also (involves these badges:

52
Hard workers, Meeting professionals, Stable workers, Completion masters). Except for
them, S C R U M master can get these badges:

• Master labour divider:

Difference between sums of story points of individual team members is

in every sprint less than 30%. Evaluated once i n 4 months.

• Attendance holder:

S C R U M team average attendance is at least 90%. Evaluated once i n 4

months.

Since product owner is role outside of the S C R U M team, this person should
have different evaluation system. His only responsibility is correct story
definition and done stories evaluation.

Team leaderboard

S C R U M is based on the rule of team as an individual. People are typically

motivated by comparison with others, so the prototype should contain leader
board which compares results of all teams. Team position should depend on the
current sum of experience points, so it would reflect the present situation. Since
experience points number is based on the last 20 weeks (see above), even
relatively new teams have a chance of good position.

Person leaderboard

In the case of S C R U M framework, people should not be competitive inside the

team, but it would still be good to compare them across teams. It can sometimes
determine if the particular person change team for his better good and raised its
level, or on the other hand his coming made the team effort worse.

A l l persons in the team should gain same amount of experience points, so

that they would not compete inside the team and would not try to make some
team member fail. Nevertheless they can compete across the team, so they
should see the complete leader board.

53
 Rewards

It is really great to have a system, which can show differences in efficiency and
work effort between people and teams, but all of that is only in virtual world.
For better motivation of all members of S C R U M development teams, there is
also a need of some tangible thing they can get.

That is the reason, w h y there should be some physical reward, for good
results and achievements in the software. These rewards can mean these
benefits:

• vacation day,

• discount for certification or training,

• free tickets to cinema or theatre,

• discount to some shop,

• sport centre coupons,

• etc.

A l l of these rewards should be evaluated by some value of reward points.

Users would get reward points for gained badges, reaching some limit after
regular recalculation, or for being in the top 3 teams of the leader board. User
would be able to choose any reward they prefer. System of gaining reward
points is not the part of prototype.

1.2 Other modifications

For motivation increase, gamification can be joined with other modification, for
reaching better results. This subsection contains some of possible modifications,
which lead to S C R U M framework and its gamification improvement.

Unit tests

Unit tests are good for fast and efficient software development. A l l benefits of
this approach are described in detail in the section 2.4.2. In case of S C R U M
framework, unit tests, if used properly, can improve team effort to maintain
54
framework rules. Unit tests can be, based on their importance, used as a
condition for gaining benefits by team members.

Modified framework should support unit tests creation by integrating into

S C R U M board (see below) and as a condition for getting more experience
points, resulting in more reward points. S C R U M master should control if unit
test creation state of user story is not jumped over.

Test-driven development

T D D (see section 2.4.3) uses a very simple process for test creation and product
implementation. This process can be very easily adapted on creation of unit tests
and helps to maintain the order and clear workflow. Therefore, in case of the
S C R U M framework, best approach is to combine this process and unit tests
together.

Pair programming

Pair programming belongs to often used development methods in Agile

approach. It has several advantages such as increasing of the team members'
substitutability, more educated employees with wider knowledge and more
efficient development with less mistakes (more in section 2.4.2).

Since this approach is not effective for every user story, there is no clear way
of rewarding the pair programming use. Only way of possible evaluation is to
mark user stories which require pair programming in advance and then give a
penalty in form of reduced experience points if the condition is not fulfilled. Pair
programming should be possible to use for unit tests and program code
separately and pairs should change from time to time. Rules keeping should be
controlled by S C R U M master.

Kanban board

Kanban, as described in section 2.4.1, uses a board for better awareness of the
current task (user story) state. Kanban principles are very similar to the S C R U M

55
 board. These two boards should be combined. Resulting board would contain
following columns:

1. Sprint Backlog
When a user story is assigned to a Sprint.

2. Development - unit test

Developers creates a unit test/tests for a particular user story.

3. Development - implementation
Developers implement functionality described by a particular user story.

4. Development - done
Running all unit tests over the functionality representing user story ends
with no error.

5. Code review
Developer, who has not implemented functionality of a particular user
story, is assigned to review its code.

6. Test on preproduction
N e w functionality is tested in the preproduction environment.

7. Done
N e w functionality is prepared for being used in the real environment.

.2 Prototyping tool
Previous section contained design of gamified S C R U M framework. One of this
thesis outputs is a SW prototype of such environment. For this purpose, there
has been made a review of currently existing prototyping tools [45]. Description
of individual tools and process of right tool selection are appended [Appendix
A].

56
3 Prototype implementation
This section describes the functionality of SW prototype, which implements
gamified S C R U M framework designed in the previous section. Description is
divided into several parts, based on prototype screens (pages).

Prototype is made for all basic S C R U M team roles, so that whole team can
use only one tool for development. In the end product, functionality should be
limited for some users, based on their team roles. Nevertheless, this prototype
does not contain account management.

3.1 United appearance

Whole solution should have united look and similar main control elements, so
that nobody is confused. For this purpose, every page of the prototype consists
of main menu located i n the top part of the page and the rest of the page. Besides
that, look of all pages is very similar, uses same colours and sizes.

vfefcome Martin

1550 / 2000 pts 1550 2000 pts

;

Home page Product backlog I Sprint board Meetings Sprint review

Figure 11 - Top part of every page

Top menu contain direct links to 5 main pages (orange buttons), link to team
page (team name with progress bar), link to profile page (profile photo) and link
to administration (grey cogged wheel).

Besides main control elements, since top menu is a part of every page, it can
be used for purpose of gamified environment. Therefore it contain profile
picture of signed user and progress bars displaying number of experience points
needed to reach higher level as well as current level number.

3.2 Home page

Home page is the place of first user contact with the system. It should contain
all the main information which every user wants to see the most. Every

57
 developer wants to have awareness of his current work, therefore there is a list
of user stories currently assign to a signed on user.

My current user stories I See user stories 1 S e e sprint board 1

NAME ESTIMATION C U R R E N T STATE DESCRIPTION

| Edit task 1 Product backlog Editation of a previously created task.

Decline task 40 Product backlog Declining assigned task.

Figure 12 - User stories assigned to signed on user

S C R U M framework is based on iterations called sprints. Signed on user is

likely to be interested in main sprint information, such as end date of current
sprint or amount of unfinished work, which is w h y there is a current sprint info
on the homepage.

Current sprint info

Start d a t e : 01.02.2016
End date: 20. 02. 2016
Currant d a t a : 15. 02. 2016
Day& tD &printand:14
Sprint prog rats: 156/360 P T S

Figure 13 - Current sprint info

Every S C R U M sprint is based on implementation of defined amount of user

stories, based on their point estimations. Whole project can be evaluated by the
sum of all user story points. Every user should be aware of current progress in
project completion (displayed on Figure 14).

A i m of this thesis is increase of team members' motivation by integration of

gamification principles. One of the main motivation elements is leader board.
Since, S C R U M is mainly aimed on team and not individuals, this prototype
contain both personal and team leader boards. People should see their current
situation in comparison with others right after opening the system homepage
(see Figure 15).

58
 Burndown graph
2000

2 3 4
Sprint number

Figure 14 - Project burndown graph

Person leaderboard All

^ R a v e n e s Ren old Team member Heroes 3950

f Vyvaloni Michael Team member Heroes 38Q0

^ K o p e c k i Peter Scrum master Heroes 3620

* Jameson Paul Team member Rohan 3600

Team leaderboard * R i c h a r d s Steve Team member Petkop 3330

T Petroldi Robert Team member Revenge 3250

Heroes 3300
' C e s k a Martin Scrum master Petkop 3150
Petkop 3650
I Stevenson Patrick Team member Revenge 3000
Revenge 3520
J a m e s Rick Team member Petkop 2890
Cormodores 3400
Jefferson T h o m a s Team member Comodores 2500
Rohan 3200
^ Flaus Nicolas Team member Comodores 1Q00

Figure 15 - Person and team leader boards

When someone sees the leaderboard, there is usually need for better
information about person, who is in better or worse place, to be able to make
correct comparison and find out reasons for the current situation. When user
clicks on the profile photo next to the name, the detailed information about
particular person are opened.

59
 Same principle is also relevant for team leaderboard. A l l users should be able
to see some details about other teams, like: project it has assigned, team
members, state of experience points and number of gained badges. This detailed
information page is opened after clicking on team name.

User information Team information

Nickname: killer Name: PETKOP

Full name: Jan Novak Start date: 28. 3. 2014
E m a i l atlress: jan.novak@firma.cz
Telephone: +420 777 888 999 S c r u m master: IM

1550 / 2000 pts P r o d u c t owner:

Team members:
Skills and
expertises: C S M certification
T 1 1
English C1 level T T
C#
A S P .NET 1550 / 2000 pts
Risk management
Customer negotiations Badges: 2/6
T e a m status: Everything goes as
Badges: 2/6 planned :)
User status: Currently happy in the work :)
Current project:
Role F r o m date T o date Service-Desk for Ministry of Defense
Scrum master 1. 3. 2014 Ongoing 28. 8. 2015 - 21. 2. 2016
Product ovmef 1. 9. 2013 29. 2. 2014

Team member 1. 5. 2013 31. &. 2013

Past projects

Figure 16 - User and team information boards

3.3 Product backlog

M a i n target of every development project is creation of some output - typically
a product. In S C R U M framework, product is described by user stories, which
compose the product backlog. User stories can be added, edited and deleted (see
Figure 17).

Final product is developed in iterations, called sprints, which contain chosen

user stories. For the purpose of sprint planning, system allows moving user
stories from product backlog to current sprint (button "to sprint" in product
backlog, see Figure 17) and back (button "back" in sprint backlog, see Figure
18). Only current sprint can be planned.

60
 Product backlog
X H New task (TO S = = :-.-|
X H I Delete task (TC SPRINT)

X U Approve (TC SPRINT)

X [J] Add document (TO SPRINT)

X • Edit task (TO SPRINT)

X H ) New timesheet (TO SPRINT)

X H ) Delete document (TO SPRIf.IT)

X B ) Decline task (TO SPRINT)

I
X Q | Edit document (TO SPRINT)

X • Add template (TO SPRINT)

Figure 17 - Product backlog

Sprint backlog

BIW1 Administration (BACK)

User account 3ACt

Figure 18- Sprint backlog

User stories have several main attributes: Name, Estimation, Priority,

Description, Acceptance criteria, State, Assigned team member, Done criteria
and Notes from testers and developers. User story detail form is can be seen on
Figure 19.
User story details
Name Estimation Priority
0 T M . Must have

Description Acceptance criteria

State Assigned team member

Product backlog T
| not assinged *
Done criteria Notes - testers and developers

U Pair implementation l_l Pair test creation

0 Update US I Add user story

Figure 19 - User story form

61
4.3.4 Sprint board
S C R U M framework uses a tool called S C R U M board. In case of this thesis, this
board has been modified for the framework efficiency increasement. There is
now a lot more board parts i n which user stories are moved when being
developed.

Board is designed to be used as a drag & drop system, which is the most
similar to using the ordinary board. A s user stories are moved, the colour of its
name is changing based on current part of the board, i n which the story is
located. It helps better orientation.

Sprint backlog
? Delete task

? Add document

Unit test creation Implementation Implementation finished Code review Test on preproduction

Done
Y c u c a n m c . e u-;er : I c r i e ; m i n t ; D r a g & D . - c p :-.;tem |

Figure 20- Sprint board

A l l user stories can be assigned to a team member. It can be done also by

drag & drop system - by moving user picture from team member list and
dropping on the particular user story.

Team members to be assigned

T 7

Figure 21 - Team members list

62
 When having a board, on which users make changes, there is a need of some
changes evidence. Especially in situations when someone is looking for a person
who made some change, this evidence is appropriate. In case of S C R U M
framework, every day should be held a daily scrum meeting. Changes table can
help with identification of last day changes.

Last 48-hours sprint board changes

MEMBER US ID FROM COLUMN TO COLUMN TIME STAMP

Martin US 3 Sprint backlog Unit test creation 12:26 15.01 2016

Peter US 2 Implementation Implementation finished 10:12 15.01 2016

Paul US 4 Implementation finished Code review 09:29 15.01.2016

Steve US 5 Test on preproduction Done 16:43 14 01 2016

Figure 22 - Last changes in sprint board

3.5 Meetings
Inseparable parts of S C R U M framework are several types of meetings. S C R U M
defines 5 main meeting types: Estimation, Sprint planning, Daily S C R U M ,
Backlog Grooming and Sprint Review. There should be records about all these
meetings i n the system.

Daily Scrum Add meeting

X QD 18.1. 2016 - Backlog Grooming

X H]18 1 . 2 0 1 6 - D a i l y Scrum
X H 1 5 . 1 . 2 0 1 6 - D a i l y Scrum
X | 1 4 . 1 . 2 0 1 6 - D a i l y Scrum
X (B 13 1 . 2 0 1 6 - D a i l y Scrum
x • 12.1 2 0 1 6 - D a i l y Scrum
X • 11. 1. 2 0 1 6 - Daily Scrum
x • 8 1 2016-DailyScrum
X HJ 7. 1 . 2 0 1 6 - S p r i n t Planning
x [I]6.1 2016-Estimation

Figure 23 - Meeting list

63
 There are some important information that need to be stored in the evidence.
For the purpose of control and reporting, S C R U M master should be able to write
notes and fill in attendance of team members.

Meeting info } Update meeting

Notes Attendance

Person Role Attended

Martin Scrum master

•
Peter Product owner
•
Michael Member
•
Peter Member •
Paul Member
•
Steve Member
•
Rick Member u

Thomas Member
•
Figure 24 - Meeting information form

3.6 Sprint review

Every user story finished during the development stage should be controlled.
There are two levels of these controls - testing, which determines, if the user
story implementation fulfills technical requirements and product owner control,
which evaluates customer satisfaction with the result.'

Done user stones

H ] New task 25% ¥

[•] Delete task 100% ¥

•] Approve document 75% ¥

•] A d d document Unevaluated T

| j ] Edit task Unevaluated T

| j ] New timesheet Unevaluated T

|^=) Delete document Unevaluated T

=] Decline task Unevaluated ¥

•] Edit document Unevaluated ¥

[•] A d d template Unevaluated

Figure 25 - User stories evaluation

64
 For relevant evaluation, product owner needs to see all important
information about given user story. He needs to take account of story
description, acceptance and done criteria and notes from both developers and
testers. Only then can product owner evaluate given user story properly. There
has to be also space for notes from product owner himself for the evaluation
understanding.

User story info

Name Information from testers Done criteria

Product owner comment

Acceptance criteria

Figure 26 - User story information form with Product owner comment field

3.7 Team page

Since S C R U M framework is aimed on the team effort, there has to be place,
where all relevant team information can be seen. For this purpose, there is a
team page. Every team has some main information, which should be kept: date
of team establishment, list of team members and persons i n the main team roles
- S C R U M master and Product owner.

Based on gamification principles, every team should have a possibility of

expressing its state by writing team status. There should also be a button which
would open the history of team statuses. Clicking on any member photo opens
particular user information (see subsection Homepage).

65
 Team PETKOP
Start date 28. 3. 2014

S c r u m master &

P r o d u c t owner ft

Other team m e m b e r s

X X X X J T

Team status

Save status I I History

I I
Figure 27 - Team main information

Every team should work on some project. Team page should though contain
also have available information about it. Project should typically be defined by
its start and end dates, title, text description and current state of progress
(expressed in percentage by ratio of sum of done user story points to sum of all
user story points). There should be also possible to display list of projects
finished by the particular team.

Current project info

Start date 28.8.2015

End date 28.8.2015

Points tfone/total

1 2 3 8 / 2 0 0 0 (62%)

M a i n description

Figure 28 - Current project information

66
 Team project history

Title From date To date

Service-Desk for Ministry of Defense 28. 8.2015 Ongoing

Project porta! for Company s. r. o. 1. 9. 2013 29. 2. 2014

Game solitaire implementation 1. 6. 2013 31. 8. 2013

Figure 29 - History of team projects

Every project using S C R U M framework is divided into sprints. Team should

have knowledge about all sprints of the project they are participating i n and
Scrum master should have possibility of its administration.

Sprint info
Sprint number:

Start date:

List of sprints Add sprint End date:

x n NO. 1 1 12.2015-31.12.2015
• NO 2 1 1.2016-31.1.2016
Update sprint
x • NO.3 1.2.2016-29.2.2016

Figure 30 - Project sprint list with edit form

Since gamification is intended to be integrated into S C R U M framework, its

principles should be aimed on the team. Thesis target is to increase team
members' motivation. People are usually drove by reaching some goal. In case
of this prototype, motivation is tried to be increased by getting experience
points. Since experience points are gained based on different types of
achievements, team members should be able to see how much points they
gained from every point source.

1550 / 2000 pts

• Total experinence points

Work time 400 / 4 0 0
Done t a s k s BOO / 1000
Keeping rules 300 / 400
Efficient work 50 / 200

Figure 31 - Team levels and experience point overview

67
 S C R U M team members are, based on the prototype design, also motivated
by team badges. Therefore every team contain list of gained badges and also
badges that can be obtained. This list is available through the button placed next
to value of current progress in badges gaining.

Obtained badges

y
Stable workers

... try harder...

Meeting professionals

All daily meetings in last 4 months have

been held.

y
Can do attitude

... try harder...

y
Completion master

... try harder...

Team badges
y
Customer importance

... try harder...

2/6
Done is done
Obtained badges Nofinished user story w a s in last 4
months returned by product owner.

Figure 32 - Badges gaining state and list

Sprint planning is one of the essential part of S C R U M development process.

For the efficient planning, the S C R U M master needs to know, hoe many user
stories can be planned for the next sprint. For this purpose, there exists a velocity
graph, which displays average sum of user stories estimation points, which has
been finished during previous sprints.

68
 Velocity graph

m
950

BO

g »
MS

UB

50

n
1 3
Sprint number

Figure 33 - Project velocity graph

4.3.8 Personal page

Every person in the system has own profile page. It contains all the necessary
information about signed on user. M a i n information, which should be always
part of some profile page, are personal information - name, surname, contact,
etc.

Personal information
Nickname: killer
Full name: J a n Novak
Email adress: jan novak@firma cz
Telephone: +420 777 888 999

Change profile info

Figure 34 - Personal information

Key part of every profile is also a profile picture / avatar, which helps other
user to better identify others, and make brings better personalization of the user
profile.

69
 Profile picture / avatar

Change

Figure 35 - User avatar/photo

Profile is a good way of user identification, but as the particular signed on

person uses the system during his work hours, he should have an opportunity
to express his current mood. For this purpose, prototype contains user status
field, where everyone can write down his current feelings. There should be also
button for list of previous statuses.

User status Save I History

Figure 36 - Personal status

At the start of every team, or project, somebody creates a team, which w i l l

be working together. For this purpose, it is always good having knowledge
about all member skills and expertise. This can help to better compose a new
team, so that there would be members with all required skills.

Skills and expertises

• C S M certification
• E n g l i s h C1 level
• C#
• A S P .NET
• Risk management
• Customer negotiations

Figure 37 - User skills and expertise

70
 A l l users can get some experience points for their activities and
achievements during development. There is several different reasons for getting
points, so user should be able to find out how many points he currently has and
how many he got for which reason. User should also see his current state of
gotten points and possible maximum not only as values, but also in form of a
progress bar.

1550 / 2000 pts

• Total experience points

Work time 4 0 / 400
Done tasks B0/ 100
Keeping rules 30 / 40
Efficient work 5 / 2 0

Figure 38 - Team experience points

User, as well as teams, can get several different badges for some of their
actions or achievements. These badges are one of the prototype form of
motivation increase. User can see his progress i n obtaining badges at his first
sight.

Badges
2/6

Obtained badges

Figure 39 - Personal badges

A l l the previously mentioned elements of motivation increase are not very

useful without main prototype motivation instrument - rewards. Users gain
reward points for getting experience points, badges, finishing projects, etc.
Reward points can be then used for choosing the most wanted reward (see
Figure 41). Rewards can be of almost any character - mentioned in section 4.2.1.

71
 Rewards

Current reward points: 158

Pick a reward

Figure 40- User rewards

Choose your reward

Reward points state: 158

v a c a t i o n day - 200 pts

free certification related to job - 200 pts

• 4 hours v a c a t i o n - 100 pts

• 6 0 % R o c k P o i n t discount - &0 pts

U 2 0 % Ticketportal discount - 50 pts

U 10 entries f i t n e s s center - 30 pts

Confirm

Figure 41 - Choosing the reward

Knowledge about team member roles history is useful i n many situations -

when new team is composed, when someone is to be promoted or just to better
know your new teammates. Prototype should therefore contain a list, which
would reflect all the previous roles i n teams i n the past, including his current
role.

History of roles

Role From date To date

Team member 1.5.2013 31 8 2013

Product owner 1 9 2013 29 2 2014

Scrum master 1 3. 2014 Ongoing

Figure 42 - Roles history

Prototype of gamified S C R U M framework SW environment, which is described

in this section, is attached to this thesis in a zip archive file.

72
.4 Questionnaire
Previous section contained prototype of SW for gamified S C R U M environment.
This draft has presented possible working environment for S C R U M teams
reflecting design from section 4.1. This section contains questionnaire, which
w i l l be used as control mechanism if the designed S C R U M gamification meet
intended result of this thesis. A l l questions have been aimed on the purpose of
designed modification justification and success confirmation or disproval.

4.1 Respondents
Since S C R U M is a development framework mostly used in the IT field,
respondents for this questionnaire have been chosen from IT companies. This
thesis is not aimed on any human demographic characteristics, such as age,
gender or education.

4.2 Set of questions

As mentioned in the section above, all questions have been aimed on evaluation
of designed gamified S C R U M . Questions are divided into three main parts -
each of them has different objective.

First set of questions has been chosen to provide information for better
understanding of whole respondents group as well as for their classification:

1. Are you or have you been working in the team environment?

a) Yes
b) No
2. If yes, what is your role in the team? Else do not answer.
a) Leader
b) Member
3. Have you ever used SCRUM framework?
a) Yes
b) No

73
 Next set of questions has been aimed on the issue of personal motivation, with
evaluation from 1 to 5 of how important are individual aspects for their
motivation:

1. Paycheck in crease
2. Personal success
3. Team success
4. Customer satisfaction
5. Extra day off
6. Event tickets
7. Shop discounts

Last set of questions has been chosen to reflect the respondents' opinion on some
gamification elements. A s the purpose of these questions may not be clear, their
justification is appended to this thesis [B Appendix].

1. Do you think that work can be also fun ?

2. Would you like to compare yourself with others?
3. Do you think that virtual rewards can make you work harder, if they are directly
connected to real rewards?
4. Do you prefer having work related information about your colleagues and team
(skills, history, etc.)?

4.3 Results
This section provides information about questionnaire described above.
Respondents for this questionnaire have been chosen based on the field they are
working in (information technology) with no taking their gender, age or other
demographic characteristic into consideration. There has been chosen a total of
20 respondents.

Results of the questionnaire are attached below [C Appendix]. A s described in

the previous section, questionnaire has been divided into three main parts. This
result evaluation w i l l evaluate the questionnaire one part in the time.

74
 First set of questions was aimed on respondent classification. Based on the
answer, I was able to evaluate the importance of individual respondents for the
thesis aim. From the results. Most of respondents are used to work in the team
and quite big percentage even know S C R U M framework.

Second part was aimed on probably the most efficient element of

gamification for the purpose of motivation increase - success and rewards.
Respondents were choosing value on the scale representing the importance of
given phrase in their motivation. Results have shown that most efficient
motivation elements can be money, vacations, personal success and customer
satisfaction. Except for money, all the other reward types have been correctly
included in the modified scrum framework.

Last set of questions was also aimed on gamification, but the different
perspective and with different answer format - yes/no answers. Results of this
part have shown that functionality of SW prototype created as output of this
thesis has been chosen and implemented in a way, that can be appreciated in a
daily work for the most of the respondents.

75
5 Conclusion
S C R U M is a quite complicated framework for software development and it is
crucial to keep on all its rules to be able to use it with all the advantages - using
S C R U M should increase efficiency of development.

Since it is essential to keep on the rules, the motivation is necessary. This

thesis goal was to answer the simple question: H o w to increase S C R U M team
members' motivation to keep on the rules of the S C R U M framework? Since
gamification is used in last years for purpose of driving desired behaviours, it
was chosen to make motivation increase possible.

Gamification implementation form has been chosen based on S C R U M

framework principles as well as best practices used in other gamified
applications (chapter 4, section 4.1). Design has been described in the chapter 4,
section 4.2. Based on the design, section 4.3 contains description of SW
prototype, which outlines the possible look and functionality of a fully
functional application, which would be usable for product development in the
S C R U M framework environment.

M a i n reason of creation of the prototype, which was based on the gamified

S C R U M framework design, was to demonstrate possible real usage of in a real
world environment. However, this prototype was developed limited
functionality. For purpose of designed S C R U M modifications justification, this
thesis contain a questionnaire, which based on the results, proofs, that designed
modifications could possibly increase users' motivation.

Therefore, on the ground of this thesis, there is considerable opportunity for

creation of fully functional SW, which would reflect gamified S C R U M
framework design described in the chapter 4.

76
References
[1] Slideshare.net, 2015. Universal Agile Thinking - Supporting the Organization.
Available from: http://www.slideshare.net/cooperlk/universal-agile-thinking.
[12 September 2014].
[2] VersionOne, 2015. Agile Methodologies for Software Development I VersionOne.
Available from: https://www.versionone.com/agile-101/agile-methodologies/.
[17 September 2014].
[3] Royce, W.W., 1970. Managing the Development of Large Software Systems. In
proceedings of IEEE W E S C O N , vol. 26, no. 8, pp. 328-388.
[4] Sutherland, J., 2014. Scrum: The Art of Doing Twice the Work in Half the Time.
Crown Business, United States of America.
[5] Scrumalliance.org, 2015. Agile Gamification - Scrum Alliance . Available from:
https://www.scrumalliance.org/community/articles/2014/august/agile-
gamification. [12 November 2014].
[6] 7bspl018.wikispaces.com, 2016. Motivation in Agile Teams. Available from:
https://7bspl018.wikispaces.com/Motivation+in+Agile+Teams [3 January
2016].
[7] Teamsandtechnology.com, 2016. David Harvey - Teams and Technology.
Available from: http://www.teamsandtechnology. com/dh/component/option,
com mojo/Itemid,44/p,82/ [3 January 2016].
[8] Mozuku.edublogs.org, 2013. EFL Gamification 1: Intrinsic and Extrinsic Rewards
Available from: http://mozuku.edublogs.org/2013/02/08/efl-gamification-l/ [3
January 2016].
[9] Barrick, M . , Mount, M . and L i , N . , 2013. The theory of purposeful work behaviour:
the role of personality, higher-order goals, and job characteristics. Academy Of
Management Review, vol. 38, no. 1, pp. 135-153. Available from: Business
Source Complete, Ipswich, M A . [1 A p r i l 2015].
[10] Tatnall, A . , 2015. History of Computer Hardware and Software Development,
Computer Science and Engineering, Encyclopedia of life-support systems.
Available from: http://www.eolss.net/sample-chapters/cl5/e6-45-12.pdf [4
A p r i l 2015]

77
[11] Bomarius, F., and Oivo, M . , 2000. Product Focused Software Process
Improvement: Second International Conference, PROFES, Oulu, Finland.
[12] Boehm, B., 1991, Software risk management: principles and practices. IEEE
Software, vol. 8, no. 1, pp. 32-41.
[13] Kruchten, P., 2004. The rational unified process: an introduction. Addison-Wesley
Professional.
[14] Kruchten, P., 2001. Rational Unified Process Best Practices for Software
Development Teams. Canada: rational Software.
[15] Agilemanifesto.org, 2015. History: The Agile Manifesto. Available from:
http://agilemanifesto.org/history.html [1 December 2014].
[16] Gunal, V . , 2012. Agile Software Development Approaches and Their History.
Enterprise Software Engineering 2012: Agile Software Development
(Seminar). Available from:
https://sewiki.iai.uni-bonn.de/ media/teaching/labs/xp/2012b/seminar/l-
agile.pdf [5 December 2014].
[17] Agilemanifesto.org, 2015. Manifesto for Agile Software Development. Available
from: http://agilemanifesto.org/ [2 December 2014].
[18] Agilemanifesto.org, 2015. Principles behind the Agile Manifesto. Available from:
http://agilemanifesto.org/principles.html [2 December 2014].
[19] Schwaber, K. and Sutherland, J., 2011. The scrum guide. Scrum Alliance.
[20] Šochová, Z. and Kunce, E., 2014. Agilní metody řízení projektů. Computer Pres s .
[21] Kniberg, H . , 2007. Scrum and XPfrom the Trenches: How we do Scrum. Lulu. com.
Available from: http://www.infoq.com/minibook
s s/ crum-xp-from-the-
trenches-2 [5 January 2015].
[22] Boeg, J., 2011. Priming Kanban: A 10 step guide to optimizing flow in your software
delivery system. Trifork.
[23] Beck, K , 2002. Extreme Programming Explained: Embrace Change. Grada.
[24] Lui, K . M . and Chan, K.C., 2006. Pair programming productivity: Novice-novice vs.
expert-expert. International Journal of Human-computer s tudies , vol. 64, no. 9,
pp. 915-925.
Available from: http://www.c
s .utexa
s .edu/u
s s er /mckinley/305j/pair-hc
s -
2006.pdf [8 February 2015].

78
[25] Astels, D., 2003, Test driven development: A practical guide. Prentice Hall
Professional Technical Reference.
[26] Marczewski, A . , 2013. Gamification: a simple introduction, Amazon Digital
Services.
[27] Google.com, 2015. Google Trends - Web Search interest - Worldwide, 2004 - present.
Available from: https://www.google.com/trends/explore [20 February 2015].
[28] Deterding, S., Khaled, R., Nacke, L., and Dixon, D., 2011, Gamification: Toward
a Definition. C H I 2011. Gamification Workshop Proceedings, Vancouver, BC,
Canada: A C M .
[29] Zichermann, G. and Cunningham, C , 2011. Gamification by design: Implementing
game mechanics in web and mobile apps. O'Reilly Media, Inc.
[30] W u , M . , 2011. What is Gamification, Really?. Available from:
http: //community. lithium. com/t5/Science-of-Social-blo g/What-is-
Gamification-Really/ba-p/30447 [5 March 2015].
[31] Lee, J.J. and Hammer, J., 2011. Gamification in education: What, how, why
bother?. Academic Exchange Quarterly, vol. 15, no. 2.
[32] Werbach, K. and Hunter, D., 2012. For the win: How game thinking can
revolutionize your business. Wharton Digital Press.
[33] Deterding, S., Dixon, D., Khaled, R. and Nacke, L., 2011. From game design
elements to gamefulness: defining gamification. In Proceedings of the 15th
International Academic MindTrek Conference: Envisioning Future Media
Environments (pp. 9-15). A C M .
[34] Kapp, K . M . , 2012. The gamification of learning and instruction: game-based methods
and strategies for training and education. John Wiley & Sons.
[35] Tastycupcakes.org, 2015. Scrumheads: The Daily Scrum Game. Available from:
http://tastycupcakes.org/2014/07/SCRUMheads-the-daily-scrum-game/ [21
March 2015].
[36] Tastycupcakes.org, 2015. Resort Brochure. Available from: http://tastycupcakes
.org/2009/06/resort-brochure/ [22 March 2015].
[37] Playknowsy.com, 2015. Scrum Knowsy. Available from: https://playknowsy.co
m/a/scrumtide/ [25 March 2015].

79
[38] Saddington, P., 2011. [Tool Review] - RedCritterTracker - Agile Tool Gamification.
Available from: http://agilescout.com/tool-review-redcrittertracker-agile-tool-
gamification/ [28 March 2015].
[39] Tastycupcakes.org, 2015. Scrum Simulation with LEGO Bricks. Available from:
http://tastycupcakes.org/2012/04/scrum-simulation-with-lego-bricks/ [2 A p r i l
2015].
[40] Tastycupcakes.org, 2015. You sunk my methodology. Available from:
http://tastycupcakes.org/2012/02/you-sunk-my-methodology/ [2 A p r i l 2015].
[41] WePlay, 2012. Why does Gamification Work: A Look into Successful Examples •
WePlay. [online] Available at: http://weplay.co/gamification-success-stories/
[Accessed 4 Jan. 2016].
[42] Zichermann, G . , 2011. Intrinsic and Extrinsic Motivation in Gamification.
Gamification Co. Available from: http://www, gamification.co/2011II0/27/intri
nsic-and-extrinsic-motivation-in-gamification/ [4 January 2016].
[43] Dale, S., 2016. Gamification: making work fun, or making fun of work?
Collabor8now.com. Available from: http ://collabor8now. com/knowledge-
management/gamification-making-work-fun-or-making-fun-of-work/ [4
January 2016].
[44] Seaborn, K . and Fels, D.I., 2015. Gamification in theory and action: A
survey. International Journal of Human-Computer Studies, vol. 74, pp. 14-31.
Available from: http://romisatriawahono.net/lecture/rm/survey/pervasive%2
0computing/Seaborn%20%-
%20Gamification%20in%20theory%20and%20action%20-%202014.pdf [6 June
2015].
[45] SitePoint, 2009.16 Design Tools for Prototyping and Wireframing. Available from:
http://www.sitepoint.com/tools-prototyping-wireframing/ [12 September
2015].

80
A Appendix
This appendix contains options of tools for prototype creation.

iPlotz [1]

IPlotz is a very good wireframes creation tool. It has a big advantage in

possibilities of collaboration between creators. It supports H T M L generation
and previews in browser. This tools can be easily used for quick wireframe
creation.

Pencil [2]

Pencil is the only open-source, free tool in this list. It is a very good tool for fast
website wireframes prototyping. It does not support many user interactions, so
it is not a best choice for good user experience during prototype testing - it
cannot be exported into H T M L files, only as pictures.

OmniGraffle [3]

Nice and usable prototyping tool - support multiple types of element shapes,
allows really fast work, results can be exported into H T M L a PDF format and
support multiple layers. It can be also used 14 days for free. Unfortunately, this
tool has one really important disadvantage - it can be run only in Mac OS, not
in Windows. Since prototype creation for this thesis is possible only in
Windows, this tool is inapplicable.

ConceptDrawPro [4]

ConceptDrawPro is a very good tool, for rapid creation of different kind of

outputs: GUI, Wireframes, Diagrams, application (Mac OS, Android, iPhone
and Windows 8), etc. Unfortunately it is not a complex tool in case of website
prototyping (good just for wireframes creation). It can be used for free for 21
days period.

81
 Axure RP Pro 7.0 [5]

Axure RP Pro is possibly the most useful tool for the purpose of this thesis. It
allows wireframes creation and supports elements using user interaction (links,
forms, etc.). It can be run on all main operation systems and can be free used for
30 days. Axure RP Pro can export output files to both PDF and HTML format.

Tools comparison
Based on prototyping tools comparison table, tool, which is most usable for
purpose of this thesis, is Axure RP Pro, therefore this tool has been used.

Tool name Free usage Platforms User interactions Relevant

support functionality
iPlotz max. 5 pages All Yes Static pages
Pencil unlimited All No Static pages
OmniGraffle 14 days Mac OS Yes Dynamic pages
ConceptDrawPro 21 days All No Static pages
Axure RP Pro 30 +14 days All Yes Dynamic pages

Figure Al - Comparison of prototyping tools

Information sources
[1] Iplotz.com, 2015. iPlotz: wireframing, mockups and prototyping for websites and
applications. Available from: http://iplotz.com/ [14 September 2015].
[2] Pencil.evolus.vn, 2015. Home - Pencil Project. Available from:
http://pencil.evolus.vn/ [16 September 2015].
[3] Omnigroup.com, 2015. OmniGraffle - diagramming and graphic design for Mac,
iPhone, and iPad - The Omni Group. Available from:
https://www.omnigroup.com/omnigraffle [19 September 2015].
[4] Conceptdraw.com, 2015. Mind Map Software, Drawing Tools I Project
Management Software I Conceptdraw.com. Available from:
http://www.conceptdraw.com/ [19 September 2015].
[5] Axure.com, 2015. Interactive Wireframe Software & Mockup Tool I Axure.
Available from: http: //www, axure. com/ [20 September 2015].

82
 Appendix
This appendix contains justification of some questions in the questionnaire.

1. Do you think that work can be also fun?

Traditional approach to work is that its main purpose is to make some
money. Answers to this question could show how much are respondents
opened to modern thinking, thus if respondents are opened to new things,
such as gamification, modern technologies, etc.

2. Would you like to compare yourself with others?

This question should answer whether respondents would appreciate
leaderboard elements or not.

3. Do you think that virtual rewards can make you work harder, if they are directly
connected to real rewards?
This question is purpose is to evaluate the importance of connection
between experience points and reward system described i n gamified
S C R U M design in this thesis.

4. Do you prefer having work related information about your colleagues and team
(skills, history, etc.)?
This question should show how many of respondents wants to share
information about themselves and other co-workers which corresponds
to personal profiles.

83
C Appendix

Questionnaire results
No. Sorting questions op. 1 op. 2 %1
1 Are you or have you been working in the team environment?Project 16 Other 4 80%
2 If yes, what is your role in the team? Else do not answer.Leader 4 Member 12 25%
3 Have you ever used or do you know SCRUM framework? Yes 5 No 15 25%

Figure CI - Results of first questionnaire part

No. Motivation elements: 1 to 5 2 3 4 5 SUM AVG 0/

/o
1 Pay check increase 0 1 6 8 5 77 3.85 64%
2 Personal success 1 3 7 5 4 68 3.4 57%
3 Team success 2 6 6 4 2 58 2.9 48%
4 Customer satisfaction 2 3 6 6 3 65 3.25 54%
5 Extra day off 0 2 5 7 6 77 3.85 64%
6 Event tickets 3 4 7 4 2 58 2.9 48%
7 Shop discounts 5 6 5 3 1 49 2.45 41%

Figure C2 - Results of second questionnaire part

No. Gamification questions op. 1 op. 2 %1

1 Do you think that work can be also fun? yes 16 no 4 80%
Would you like to share your current mood with your
colleagues ? yes 11 no 9 55%
Z.

3 Do you like to compare yourself with others? yes 12 no 8 60%

Do you think that virtual rewards can make you work
i
harder, if they are directly connected to real rewards?
yes 15 no 5 75%
Do you prefer having work related information about your
colleagues and team (skills, history, etc.)? yes 13 no 7 65%

Figure C3 - Results of third questionnaire part

84
D Appendix
Supplementary file archive
Description:

This archive file contains H T M L files with a SW prototype. For more

information see chapter 4, section 4.3.

Filename:

Prototype.zip

85