SCRUM:

A Brief Guide For Business Owners

What to expect if your coding team follows a Scrum
approach to software development
Contents:
INTRODUCTION 1

WHAT IS SCRUM 2
The Philosophy Behind: Agile and Its Values 2.1
What is Scrum: Definition & Brief Explanation 2.2
Advantages of Scrum Methodology 2.3
Types of Projects Scrum Suits For the Most 2.4
Budgeting in Scrum 2.5

HOW SCRUM WORKS 3

Scrum Team 3.1
Defining a Product Backlog 3.2
Scrum Events 3.3

SCRUM VS OTHER METHODOLOGIES 4

Kanban vs Scrum 4.1
Waterfall vs Scrum 4.2
XP vs Scrum 4.3
Lean vs Scrum 4.4

FINAL THOUGHTS 5
01 INTRODUCTION
When it comes to software development, a final result depends on numerous factors such as budget, expertise of soft-
ware engineers, time limits, effective communication between a client and a development team etc. Yet, there is also
one aspect that is as important as deciding what kind of product to build. It’s a project management methodology, or, to
put it simply, the way a coding team works to turn your idea into reality.

Scrum has already proved to be one of the most effective approaches to the product development. However, if you
didn’t hear much about this framework before, it might be quite challenging to figure out how it works. This is because
unlike Waterfall and many other conventional project management methodologies, Scrum has its own terminology and
quite strict rules which have to be followed. But, actually, it is not complicated.

We created this Guide to explain Scrum in simple words and help you understand how it can benefit your project. It is
based on the official Scrum Guide and the vast experience GBKSOFT team has in Scrum software development.

For more information go to:

scrum.org
gbksoft.com
02 WHAT IS SCRUM
02.1 The Philosophy Behind: Agile and Its Values
If you have ever googled ‘scrum software development’, you have probably found some information about Agile too. This
is because Scrum follows the Agile principles and these two terms usually go hand in hand.

In short, Agile is an umbrella philosophy that, besides Scrum, covers several other project management methodologies
such as Kanban and Extreme Programming. Its core values are outlined in so-called Manifesto for Agile Software Devel-
opment created by seventeen programmers in 2001.

AGILE VALUES

The distinctive feature of all Agile methods is that they are lightweight, meaning that they strive to reduce heavy plan-
ning and excessive regulation. That’s why, agile software development is highly adaptable to changes, aimed at rapid
delivery, constant improvements and accumulation of knowledge.

Speaking about the difference between Agile and Scrum, the former does not have specific instruction on how the work
should be done — it’s just a set of values and principles. At the same time, Scrum includes rules and prescriptions that
are based on these values and principles.

02.2 What is Scrum: Definition & Brief Explanation

The official Scrum Guide defines Scrum as ‘a framework within which people can address complex adaptive problems,
while productively and creatively delivering products of the highest possible value.’ To put it simpler, Scrum is a method-
ology that helps efficiently develop and deliver complex products.

The main idea behind Scrum is that the process of product development is broken up into relatively short and fixed-du-
ration iterations called sprints during which a team creates one piece of software (an increment) that is potentially
releasable.

A distinctive feature of this framework is that there is no heavy planning at the beginning and a Scrum development
team can start coding once it receives enough information to complete the first incremental release. After the first
increment is built, a team tests and reviews it to make this specific piece of software ready for delivery. Hence, at the end
of the sprint, a client receives a potentially shippable feature set. The same procedure (planning -> building -> testing ->
reviewing = increment) is repeated for all the next sprints until a product is complete.

The above approach allows a team to accumulate knowledge about a product so they can make each further decision
based on the information acquired from experience (i.e. previous sprints) rather than predictions and brief background
data known at the beginning. It gives a development team an opportunity to learn and improve throughout the devel-
opment process that results in faster and more productive work in each further sprint.

02.3 Advantages of Scrum Methodology

The main reason why development companies choose to follow Scrum approach when building software products is
that it allows them to deliver more value to clients benefiting them in a myriad of ways.

Quick Start.
Scrum assumes iterative software development, and knowledge about a product is accumulated
throughout the process. For these reasons, there is no need for a development team to make all decisions
at the very beginning — programmers can start coding right after they have basic information required to
create the first increment. Hence, you don’t have to wait for ages until the lengthy planning process is
completed.

Frequent Releases.
A sprint cannot be longer than a month. So, if your team uses Scrum software development framework,
you’ll be receiving a potentially releasable increment every 2-4 weeks.
completed.

Transparency.
Clients are actively involved in the Scrum software development process and have an opportunity to see
the work in progress, not just the final product. On top of this, clients’ feedback is gathered on a regular
basis, so you can always be sure that the deliverables meet your expectations.

Flexibility.
A team makes all the decisions based on experience it received from the previous iterations. As the result,
Scrum allows teams to avoid one of the most common pitfalls inherent to more conventional project man-
agement methodologies — inability to effectively manage ever-changing circumstances. The scope of a
product can be easily adapted to new requirements, for example, if unexpected challenges arise, and,
thus, it is always kept relevant.

Advanced Quality.
Increments are inspected at the end of each sprint, so if there are any errors, they are detected early on.
This allows a team to address all issues in a timely manner that results in the high-end quality of delivera-
bles.

Improved Risk Control.

Constant accumulation of knowledge by a team gradually decreases the level of uncertainty that is inevi-
table at the beginning of any project. This allows a team to manage risks more effectively since the more
information they have, the better decisions they can make, and the more risks can be mitigated.

Budget Forecasts.
As the work is done in short iterations, a client can terminate the development process at any moment at
just a short notice. Usually, contracts require one month’s notice.

The above benefits of Scrum give clients the opportunity to receive high-quality products perfectly tailored to their
needs within the shortest possible period of time.

COMPANIES USING SCRUM

02.4 Types of Projects Scrum Suits For the Most

As mentioned, Scrum works best for dealing with complex projects for which a fully predictive approach is not suitable.

Basically, one can hardly find a software development project that doesn’t meet all the criteria mentioned above. So it
won’t be an exaggeration to say that when it comes to web or app development, there is no better methodology to
apply.

02.5 Budgeting in Scrum

Budgeting in Scrum is done according to Time and Material pricing model. This means that a client is charged with a
payment that is calculated based on time spent by the development team to complete the work.

As we see from the practice, some CFOs and other top managers are reluctant to go for Scrum. They think that this
methodology is risky in terms of budgeting as it doesn’t allow for the full costs predictability. Yet, the truth is that the way
the budget is decided in Scrum is much safer and more foreseeable than the fixed-price model and, thus, it’s more ad-
vantageous for clients. Here are two reasons why it is so.

Fixed-price model rarely works for software development projects

This is because the requirements and market conditions change frequently that makes it practically impossible to cal-
culate the exact price for the work up front. If a development team still tries to do this, it usually leads to either overesti-
mation or underestimation. Both situations are undesirable for clients since when a project is overestimated, you pay
more than the work actually costs. At the same time, in the case of underestimation, the quality of a product is usually
compromised as a development team has less time than it needs to develop software.

Application of Scrum allows for better control over your budget

If you see that you’re running out of budget, you may decide to terminate the work giving only a short (usually a one
month’s) notice. Besides, you may sometimes end up having the releasable product earlier than you planned. In such
case, you may also bring your project to an end saving all the money that is left.
03 HOW SCRUM WORKS
03.1 Scrum Team
All Scrum team members have their own roles with specific responsibilities. The main difference between a Scrum and
traditional team is that the former has no team leader to make all the crucial decisions and solve all the problems.
Instead, a Scrum team as a whole decides what is the best way to accomplish the tasks and overcome the challenges.

A Scrum team consists of a Product Owner, Development Team and Scrum Master. There are also stakeholders, i.e.
people who have a specific interest in a product. Usually, these people are the clients whose need of a certain tech solu-
tion became a trigger for the commencement of a software development project. Stakeholders are not in a Scrum team
but since they influence a product development process, they may take part in separate Scrum events if needed. In all
other instances, stakeholders are represented by a Product Owner.

A Product Owner is a person who turns stakeholders’ needs into specific user stories, i.e. concrete features of a product.
Since a Product Owner has a vision of a product, his or her main responsibility is to decide what has to be developed
(so-called Product Backlog) by a Development Team and in what sequence. To perform this task, a Product Owner usu-
ally consults a Development Team, but, either way, he or she remains accountable.

As you may have already guessed, a Development Team is a team of software engineers who actually do the work. They
are the only people who decide how to turn a user story into a product increment. In Scrum, a Development Team may
not have less than three and more than nine members. As explained in Scrum Guide, this is an optimal number of team
members that allows a team to complete a significant amount of work without too much coordination.

There is also a Scrum Master. Basically, this person is a facilitator that manages a process of cooperation and informa-
tion exchange within the Scrum software development framework. In other words, he or she coaches a team by focus-
ing on how to organize the work in the most efficient way.

03.2 Defining a Product Backlog

According to Scrum Guide, a Product Backlog is ‘an ordered list of the work to be done in order to create, maintain and
sustain a product’.

In traditional methodologies (e.g. Waterfall), all or at least most of the tasks are planned at the beginning so the scope of
work is not usually subject to changes along the road. However, Scrum procedure for defining a Product Backlog is differ-
ent. As the product development in Scrum is broken into relatively short iterations, a team has an opportunity to gradu-
ally accumulate knowledge about a product, so the decisions are made one at a time based on the information ac-
quired from all previous iterations. Here’s how the process looks like.

Assessment and ordering the feature requests

Everything, of course, starts with ideas, and it’s a common situation that clients (or stakeholders) have lots of them. Natu-
rally, not all the features they envisioned can be developed at once, so the first challenge is to prioritize the feature
requests. As we have already mentioned, this is the responsibility of a Product Owner.

Having discussed the ideas with stakeholders, a Product Owner assesses them based on two criteria: value (i.e. are they
critically important or just nice to have?) and size (i.e. how much time would it take to build each of them?).

After that, he or she determines the sequence of what should be built. For example, if a user story has a greater value, a
Development Team should work on it first; if two user stories have the same value one is bigger, a Development Team
should work on the one that is smaller, and so on.

Saying “No” to some features

In some instances, a Product Owner may define that it’s not expedient to build a particular feature due to budget limita-
tions or some other reasons, so he or she may say “No” to some stakeholders’ requests.

Yet, a Product Owner is not a “bad policeman” who “kills” stakeholders’ dreams. On the contrary, he or she optimizes the
work, so that stakeholders may receive the best product, or better to say a product with the best possible set of features,
within the budget they have. For example, stakeholders would doubtedly be happy if development of an optional feature
will “eat” all their money before the essential features are even built.

The above assessment process applies not only to the initial ideas but also to all further feature requests that a Product
Owner receives during a software development process.

Collaboration with Development Team and Stakeholders

It’s important to mention that a Product Owner does not work in isolation (in fact, no one does in Scrum), he or she com-
municates with stakeholders and a Development Team all the time. Stakeholders help a Product Owner define a value of
user stories, while a Development Team consults him or her on the time needed to build each feature.

Of course, it’s not the exact science, so there might be a lot of guesses at first. Yet, with the release of each further incre-
ment, a Scrum Team accumulates more and more knowledge about a product and the assessments become more
accurate.

Hence, defining a Product Backlog in Scrum is a continuous process. And although a Product Owner is a person who is
ultimately responsible for deciding what goes in and what goes out, the whole Scrum Team along with stakeholders take
part in performing this task. This is possible due to iteration and communication — two foundations the work in Scrum is
based on. Iteration and communication are ensured by Scrum events.

03.3 Scrum Events

A distinctive feature of Scrum is that it’s flexible, meaning that there is nothing engraved in stone and everything can be
changed and adapted to new circumstances at any time. For this reason, effective and regular communication is es-
sential for making the process work as it’s supposed to. Such communication occurs during Scrum events, the main pur-
pose of which is to create a formal opportunity to inspect and adapt a product.

The key Scrum event (or how the authors of Scrum Guide call it “the heart of Scrum”) is a Sprint. It consists of other events
such as Sprint Planning, Daily Scrums, Sprint Review and Sprint Retrospective, as well as the development work.

Simply put, Sprint is an iteration with a duration of no more than a month during which a team creates one product
increment (i.e. a piece of working software) that is potentially releasable.

Every Sprint begins with a Sprint Planning, an event that has two main purposes:

Crafting a Sprint Goal — an objective that is to be met within a Sprint

Defining a Sprint Backlog — a scope of work to be done to meet a Sprint Goal

To do the planning, a Scrum Team considers the Product Backlog, the latest Increment, as well as performance of a De-
velopment Team during the previous Sprints and its capacity (i.e. an average number of tasks that can be completed by
a Development team during one Sprint). It’s also worth mentioning that while a Product Owner is responsible for picking
stories to be developed, only a Development Team can determine a number of tasks it can accomplish within a sepa-
rate Sprint.

Example:
Let’s say stakeholders provided Susan, a Product Owner, with seven feature requests (A, B, C, D, E, F and G).
Susan assessed them and, after a discussion with stakeholders, made a decision that it’s not expedient to
build C and E so only A, B, D, F and G were converted into users stories.

Susan knows that stakeholders value features B, D, F and G the most and they are critically important for the
product. In addition, a Development Team told her that the development of features A and G would take a
lot of efforts and the greatest amount of time. Based on this information, Susan decided that stories B, D and
F should be developed in the first place because they are most valuable and the smallest.

The capacity of the Development Team is 2-4 stories per Sprint. At Sprint Planning, Susan discussed the se-
lected stories with a Development Team, it assessed them and concluded that only two of them can be ac-
complished during the Sprint. Hence, it was decided that stories B and F would be the Sprint Backlog for the
current Sprint.

A Development Team also has daily 15-minutes meetings called Daily Scrums during which team members inspect the
progress (i.e. what was done yesterday), make plans for the day and determine if there are any impediments that can
prevent a Development Team from meeting a Sprint Goal.

At the end of a Sprint, a Scrum Team holds an event called Sprint Review. Its main purpose is to inspect what was done
(i.e. the Increment) and to adapt the Product Backlog accordingly (if needed). Usually, stakeholders are also invited, so
they can participate in the discussion.
There is also a Sprint Retrospective, a Scrum event at which a Scrum Team has an opportunity to analyze how the latest
Sprint went and think about any possible improvements to the process.
04 SCRUM VS OTHER
METHODOLOGIES
04.1 Kanban vs Scrum
Both Scrum and Kanban are Agile methodologies. And since they’re built on the same philosophy, there are some simi-
larities between these two approaches. For example, like in Scrum, the work in Kanban is done iteratively and the devel-
opment process is quite flexible. However, the way a team collaborates and do the tasks is different.

In Japanese, the word “kanban” means “billboard” and the methodology got its name because it utilizes so-called
kanban board. The board represents the items in a product backlog and, traditionally, it contains three key sections:
tasks to be done, tasks in progress and completed tasks. Yet, there might be some variations in software development,
for example, a team may split the “in progress” column into “coding” and “testing” if needed.

Speaking about the Scrum vs Kanban, the differences are the following:

Process.
While Scrum development process consists of fixed-duration sprints, the work in Kanban occurs as a continuous
flow.

Prioritization.
In Scrum, the tasks are pulled from product backlog in batches that form a sprint backlog. In the case of Kanban, a
team delivers feature sets on an as-needed basis and it starts the new tasks only after the previous one is complet-
ed.

Team Roles.
All members of a Scrum team have their own roles and responsibilities. In Kanban, the roles are not strictly defined
and the team members are encouraged to collaborate.

Modifications.
The changes in Kanban can be made any time during the development process. Scrum framework allows for the
modifications only after a sprint is completed and any changes that jeopardize the sprint goal are prohibited.

Summing up: Kanban and Scrum are both efficient methodologies which are frequently applied in software develop-
ment. Yet, Scrum has more strict rules in terms of roles and delivery timelines, while it still remains flexible and may be
easily adapted to new conditions. This allows a team to avoid chaos and keep the cadence. At the same time, since
Scrum is more structured and predictable, clients receive their increments on predefined regularity and can better un-
derstand what’s happening on the project.

04.2 Waterfall vs Scrum

When it comes to software development, the confrontation between Waterfall methodology and Scrum (or even Agile vs
Waterfall) is deemed to be the toughest one. This is because these two models represent diametrically opposite ap-
proaches to the way a product is created.

Waterfall is a conventional project management methodology — it’s linear and sequential. This means that the whole
process is broken into stages which go one after another. A team has to finish one phase of the development before the
next phase can begin. The classic waterfall model of a software development process includes five stages: writing soft-
ware requirements specifications, creating design, implementation (or coding), verification (or testing), and mainte-
nance.

STAGES OF WATERFALL

Waterfall and Scrum do not have much in common, so the list of differences can be really huge. But here are the most
crucial of them for you to grasp the basic concept:

Planning.
Waterfall assumes that requirements are well-documented before the coding starts. This stage of the process usu-
ally takes a lot of time, so the delivery of the first feature set is postponed until everything is planned. At the same
time, Scrum does not have a lengthy pre-development stage — the team can start coding once the backlog for the
first sprint is defined.

Flexibility.
In Waterfall, any changes to the development process are not favored since you cannot go back to the prior stages.
On the other hand, the Scrum framework is extremely flexible — clients’ feedback is gathered on a regular basis and
can be adapted to new conditions as needed after each sprint.

Deliverables.
If a development team applies Waterfall methodology, clients see only the final product since software isn’t deliv-
ered until the whole work is done. In Scrum, clients receive potentially releasable pieces of software after each sprint
(i.e. every 2-4 weeks).

Client Involvement.
Since clients in Waterfall are not actively involved in the process, software development is driven by contracts and
documentation. In the case of Scrum, clients are invited to Sprint Review — an event aimed at inspecting and dis-
cussing work done within the sprint. They have an opportunity to participate in the discussion and make comments
on how to improve the product.

Summing up: Waterfall works well only for short-term, simple and fully predictable projects. It’s not the best option to use
this methodology in software development since trying to predict everything in advance may be quite risky and ineffec-
tive. On top of this, there are good chances that clients will not be fully satisfied with results because their desires and
market conditions may change over the development process. At the same time, Scrum allows teams and clients to
eliminate these risks making the process efficient and convenient for all sides.

04.3 XP vs Scrum
XP stands for Extreme Programming and, as mentioned above, it’s another agile development methodology. Since XP
and Scrum have the same principles and values in their foundation, they have some common features. Like Scrum,
Extreme Programming aims at improving the quality of a product and adapting it to clients’ requirements. The work in XP
is also based on early delivery, constant communication, clients’ feedback and iterative process.

The word “extreme” in the name of this methodology is not accidental. XP strives to take best programming practices to
the extreme level. For example, if a team applies Extreme Programming methodology, they perform a code review con-
stantly through pair programming (when two developers, a navigator and observer, work together using one computer),
unit and integration testing.

Yet, although Scrum and XP are both agile methodologies, they are different in terms of practical implementation:

Focus.
Scrum focuses on the big picture, i.e. the way the work is organized. At the same time, Extreme Programming deals
with engineering things and prescribes how a team should build a product, i.e. the way the work should be done.

Product Backlog.
In Scrum, sprint backlog remains unchanged till the end of a sprint, while XP allows a team to swap items within one
iteration.

Roles and Processes.

XP does not contain any detailed instructions on team roles and processes. In Scrum, each team member has par-
ticular responsibilities and there are strict rules on how sprint events should be held.

Summing up: The main difference between Scrum and XP is that they focus on different things. Hence, it would be wrong
to say that these methodologies are mutually exclusive. The one may complement the other if a team decide to apply
both of them simultaneously. Yet, Scrum brings more benefits to clients since it makes the development process trans-
parent, clear and organized. For this reason, we recommend opting for Scrum as the first priority and adding XP frame-
work to it if you want to have a better control over the technical work.

04.4 Lean vs Scrum

Lean is a philosophy like Agile, not a methodology like Scrum. Its core principles include the following: eliminate waste,
amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in and see the
whole. Here’s how Lean, Agile and Scrum relate to each other:

Lean vs Agile.
While these philosophies have a lot in common, the difference between Agile and Lean is that they focus on different
things (just like Scrum and Kanban). Agile is all about how separate projects are to be completed by a development
team. At the same time, Lean takes more system view and looks at how the entire organization is delivering its value.

Scrum vs Lean.
Scrum is based on Agile philosophy. However, since Agile and Lean are not contradictory in their nature, Scrum team
can use Lean principles as well to improve the way they work.

Summing up: Scrum and Lean are concepts from different categories so there can be no “either-or” choice. A team
cannot do Lean, but it can certainly apply this philosophy to optimize software development, including processes within
the Scrum framework.
05 FINAL THOUGHTS
As we see from the practice, Scrum is one of the best frameworks to apply in any software development project.

Breaking up the process into fixed-duration sprints allows for the quick start of coding and frequent releases of poten-
tially shippable feature sets. At the same time, constant adaptations and inspections ensure the high quality of final
results.

Another huge benefit of this framework is a convenient and risk-free budgeting system that lets business owners and
development teams avoid the traps of over- and underestimation.

As professional app developers, we can assure you that Scrum is simple and indeed convenient framework that makes
a development process faster and much more efficient.
ABOUT GBKSOFT
GBKSOFT is a software development and consulting company headquartered in Kyiv, Ukraine.
It is an IT outsourcing and outstaffing provider specializing in building custom web and mobile applications. This covers
writing software requirements specifications, software engineering, UI/UX design, quality assurance, and maintenance of
a product

The company serves different industries and has expertise in creating a wide range of solutions for web and mobile such
as booking, matching, trading, gambling and sports applications. It also develops SaaS software and IoT systems.

As of today, GBKSOFT’s portfolio lists over 700 software development projects delivered to clients from 18 countries. In
2014, the company released Defend Ukraine, a mobile game dedicated to the armed conflict in the east of Ukraine, that
went viral with over 1 million downloads.

Our Team

Alexandra Rostovtseva Vlad Somik Elena Keleberdenko

Co-founder / Business Manager Chief Client Engagement Manager Chief Project Manager

Contacts: Contacts: Contacts:

alexandrarostova@gbksoft.com somik.vi@gbksoft.com keleberdenko.lv@gbksoft.com
LinkedIn LinkedIn LinkedIn

Alexandra is a business manager with
solid experience in client
communications, team management,
and product management. She’s the
driving force and soul of every project
completed by GBKSOFT!
Vlad has a secret skill to turn clients
into friends. He always knows the latest
trends and can give you a great
consultation. As a tech geek, Vlad can
advise on the most innovative
solutions for your business. Besides,
you can always count on him when it
comes to the project documentation.
Lena is an outgoing and friendly
project manager with experience in
delivering successful projects. She
oversees each step taken by software
developers and ensures that your idea
is designed and coded in the way you
envision it to be.