1.

Scrum in a Nutshell: How It Works

 by Ivanna Denys
 Updated on January 17, 2019

Scrum has already proved to be one of the most effective methodologies for managing a product
development process. It helps teams set a workflow and make the work on a project as productive
and efficient as possible.

We have a separate article explaining what Scrum is, the philosophy behind it and its main benefits
for the development process. You can read it here.

Yet, if you didn’t hear much about this approach before, it might be quite challenging to figure out
how Scrum works. This is because unlike more conventional project management methodologies
(for example, Waterfall), Scrum has its own terminology and quite strict rules which have to be
followed. But, actually, it is not complicated at all.

In this article, we’ll try to explain Scrum in simple words, so you can clearly understand all the nuts
and bolts and appreciate its advantages yourself. Let’s start with exploring who is who in Scrum.

1. Scrum Team
2. Defining a Product Backlog
3. Scrum events

2. 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 solution 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 usually 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 information exchange within the Scrum software development framework. In other
words, he or she coaches a team by focusing on how to organize the work in the most efficient way.

So, how do all of them cooperate and how does Scrum actually work? Let’s talk about this in more
details.

3. 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 different. As the product development in Scrum is
broken into relatively short iterations, a team has an opportunity to gradually accumulate knowledge
about a product, so the decisions are made one at a time based on the information acquired from all
previous iterations. Here’s how the process looks like.

4. 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. Naturally, 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.

5. 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 limitations 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.

6. 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 communicates 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 increment, 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, so let’s talk about them next.

7. 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 essential for making the process work as it’s supposed to.
Such communication occurs during Scrum events, the main purpose 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 Development 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 separate 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 selected stories with a Development Team, it assessed them and concluded that only
two of them can be accomplished 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.

8. Bottom line
As you may see, Scrum is simple and indeed convenient framework that makes a development
process faster and much more efficient. Opting for a team that works according to Scrum is always
a wise decision since this methodology allows for the constant improvements and adaptations, so, in
the end, you receive a product that perfectly fits your needs.