Moritz Knueppel - The Scrum Guide Explained A Comprehensive Analysis of The Scrum Guide (2020)

The Scrum Guide Explained
A Comprehensive Analysis of the Scrum Guide
Moritz Knueppel
••
a
To those who have shaped my path in Scrum
Dr. Peter Stormer

my first boss after college,
who encouraged me to pursue the Scrum Master path
Sumeet Madan
the PST who taught me about Product Ownership and helped me
in my pursuit of PSM- III
Sofia Katsaouni
my girlfriend and fellow Scrum Master, who has helped my writing
of this books with countless discussions during walks by the lake
Self -published in September 2020

First edition
Moritz Knueppel
Hermannstal 89
22119 Hamburg, DE
scrumquide@moritz-knueppel . eu
Copyright © Moritz Knueppel 2020

Contents
Preface v
1 Purpose of the Scrum Guide 1

2 Definition of Scrum §
3 Uses of Scrum 18
4 Scrum Theory 24
4.1 Transparency 29
4.2 Inspection . 32
4.3 Adaptation . 26
5 Scrum Values 39
6 The Scrum Team 53

6.1 The Product Owner . . 62
6.2 The Development Team Z2
6.3 The Scrum Master . . 8J
7 Scrum Events 1QZ

7.1 The Sprint . . . . 112
7.2 Sprint Planning . . 123
7.3 Daily Scrum . . . 122
7.4 Sprint Review . . . m
7.5 Sprint Retrospective 158
8 Scrum Artifacts 165
8.1 Product Backlog 167
8.2 Sprint Backlog 1SZ
8.3 Increment . . . 125
9 Artifact Transparency 122
9.1 Definition of "Done” 202
10 Endnotes 207
11 Acknolwedgements 209
11.1 People .... 209
11.2 History .... 209
License of the Scrum Guide 211
Postface 212
Bibliography 213
List of Figures 214

Preface v
Preface
Scrum is simple to understand but difficult to master.
This paraphrased statement from the Scrum Guide holds a special

meaning for me. When first I came into contact with Scrum. I read
the Scrum Guide a few times and thought I had understood all
there was to understand, that I would now know all there was to
know. Glossing over the Scrum Guide, I accepted it as "one way
to do things”, not questioning any meaning behind it. My modus
operandi was hence all too often "this is how it would be done
by the books, but it doesn ' t really work for us. so we will do it
differently ".
As I moved around different companies and got to observe

Scrum in practice in many Scrum Teams, from small teams of a
handful of people to scaled environments with several dozen
developers, deviation from the principles laid out by the Scrum
Guide appeared to be the norm rather than the exception to it.
Other Scrum Masters I would work with didn' t seem to see this as
problematic either. But as I saw more and learned more, I began
to question the validity of my existing knowledge, or - as I would
come to realize - significant lack thereof . I decided for this to
change and set out to understand Scrum more appropriately.
This book represents my attempt to explore the Scrum Guide

in-depth to understand what this truly means. It is an attempt to
inspect the delicate balance between rules, roles, events, values
and artifacts the Scrum Guide describes. Most of all. it is my
attempt to understand not only WHAT the Scrum Guide says, but
WHY it says what it says.
Preface VI
To explain the Scrum Guide, I am taking apart the entire Scrum

Guide. In what grew to be over 200 pages. I am examining the
Scrum Guide sentence by sentence, sometimes even word by
word. I provide background information about the history of
Scrum and about underlying concepts. Most of all, I am trying to
explain the interconnectedness of the Scrum Guide, how the
sections refer to each other, and everything in Scrum is
dependent on each other .
Every Scrum Guide section and, for the most part, every
sentence can be read individually in this book , Critical
dependencies between them, such as an explanation of Scrum
related terminology and essential concepts , are marked in
footnotes. Therefore, the book can be used as a reference book
to look up the meaning of and ideas behind individual aspects of
Scrum.
For an in-depth study of the Scrum Guide using this book , I
recommend reading the entire Scrum Guide and then working
through this book back to back . While this book is not explicitly
intended as study material for any Scrum examinations, I believe
that it can certainly help you prepare for exams that require not
only a superficial but a more thorough understanding of Scrum.
I sincerely hope this book can be of help to anybody who is

seeking to understand Scrum more thoroughly. I hope it helps
them gain a more in-depth insight into this genuinely ingenious
framework. I wish for this book to be a valuable contribution to
the ever-growing Scrum Community.
1 Purpose of the Scrum

Guide
Scrum is a framework for developing, delivering, and

sustaining complex products.
The first sentence of the Scrum Guide is only 11 words long;

however, it contains an essence of what Scrum is and is not ,
what it is for. and even what understanding it has of product
development. This sentence can be broken down into three key
components:
1. The term " framework " outlines that Scrum does not have a
handbook for every given situation and does not claim to
have the solution to every single challenge arising in
product development . Rather, it provides a set of rules
within which the people involved are free to operate with
the tools, methods, and techniques they deem appropriate .
Scrum provides a frame to work within, hence the term
" framework”.
2. The trifold of " developing , delivering , and sustaining"

products lays out the understanding of the product
development lifecycle: Scrum acknowledges that software
is not simply shipped when it is finished and left to the
customer to use, but rather there ought to be an ongoing
process of development in collaboration with the customer,
continually adjusting the product to the needs of the
market.
1 Purpose ol the Scrum Guide 2
3. When speaking of " complex products " , the Scrum guide

makes two implicit claims:
a) There are situations in which using Scrum is

appropriate. When developing a product that is
complex , especially in environments that are
complex . Scrum is indeed capable of providing a
framework with which to address the challenge of
complexity. t
Example: The development of an intricate mobile
application with a team of six developers over the
course of a year may warrant the use of Scrum.
b) Conversely, there are situations for which Scrum is
not appropriate, namely when the product in
development is not complex . While Scrum is a
lightweight framework, it nonetheless creates
overhead by defining roles, events , roles and what it
calls artifacts. This overhead may not be justified if
the product development at hand is simple .
Example: setting up a simple website with two people
in a few days may not warrant the use of Scrum.
This Guide contains the definition of Scrum. This definition

consists of Scrum 's roles, events, artifacts, and the rules that
bind them together.
Unlike some other project management methodologies or

frameworks. Scrum has a clear definition of what it is and what it
is not. leaving no room for subjective interpretations or variations
while still operating under the title of "Scrum”.
The Scrum Guide is not descriptive in nature, meaning it does

not try to describe an already existing real- world practice by
abstracting models from it, but rather it is prescriptive, meaning
' see explanation ol complexity in the Cynefin Framework on pages 7H,

that by definition, what is written in the Scrum Guide and it alone

serves as the definitive source.
The Guide defines the roles, events, artifacts and rules which
constitute Scrum . In practice, there are often deviations on one
or more of these - often called "ScrumButs" deriving from the
expression "we do Scrum, but . . . " followed by an outline of the
deviation.
By definition, these approaches are not Scrum, as they violate
the prescriptive definitions outlined in the Scrum Guide. Only
what adheres to the definitions laid out in the Scrum Guide is
truly Scrum.
1 Purpose ol the Scrum Guide 4
Ken Schwaber and Jeff Sutherland developed Scrum; the

Scrum Guide is written and provided by them. Together, they
stand behind the Scrum Guide.
Some approaches to product development gradually emerged as

a wide set of practices. Scrum however, was explicitly defined by
,
Ken Schwaber and Jeff Sutherland. Both developed approaches

in their respective companies that would lay the foundation for the
modern Scrum. In 1995 they joined forces and integrated their
ideas into a framework that is known today as Scrum. Since then,
it has been further improved multiple times, most recently in the
2017 update to the Scrum Guide.
Figure 1.1; Jeff Sutherland ( left ) and Ken Schwaber (right )
In 2002 , Schwaber, together with others, founded the Scrum

Alliance" and launched the Certified Scrum accreditations to
spread Scrum.
;
hnps /www 5crumaHiar>ceora/
^
In 2009, he left over differences - mainly regarding the

standardization of the curriculum - and created Scrum .org3 ,
which now oversees the Professional Scrum accreditations.
Parallel to this, Sutherland set up a company called Scrum Inc. 4
offering consulting and training on Scrum, setting up the
Licensed Scrum accreditations.
These two sentences in the Scrum Guide can be seen as a

commitment to further cooperation in developing Scrum. It further
outlines that no organization owns the definition of what Scrum
is. but that instead , that definition is up to the Scrum Guide , which
is jointly maintained by Schwaber and Sutherland.
3
httos 7/www.scrumof(V
4
hnps7Awww.scruminc .com/
2 Definition of Scrum 6
2 Definition of Scrum
Scrum (n): A framework within which people can address

complex adaptive problems, while productively and
creatively delivering products of the highest possible value.
This one sentence definition contains a highly distilled essence of

Scrum and can be inspected almost word by word:
The use of " Scrum (n)f [ with " (nf indicating that Scrum is a
noun] mirrors a dictionary entry. This can be seen as having two
purposes:
.
1 It reinforces the idea that the Scrum Guide is the definitive
source, in which the one and only true Scrum is defined.
2. It clarifies the correct way of spelling Scrum, which is often

written as "SCRUM *, likely because in an early paper on the
subject by Ken Schwaber, the document title contained the
word Scrum in all capital letters. The term "Scrum" is based
on the rugby formation known as "scrummage" or "scrum”
for short. As a proper noun, it is capitalized.
" A framework within which... * once again indicates that Scrum
does not provide a definitive methodology, but a set of definitions

and rules, within which other tools, approaches and methods can
be used.
The choice of "address complex [. .. ] problems" can be explained

by looking at the Cynefin-Framework, which categorizes
problems into four primary clusters: simple, complicated ,

complex and chaoticMl
Complex Complicated
Probe Sense
Sense
Analyze
Respond Respond
Emergent Good Practice
Chaotic Simple
ACt Sense
Sense
Categorize
Respond Respond
Novel
ijBest Practice
Figure 2.1: A graphic representation of the Cynefin quadrants.
1. Simple problems are ones with "known knowns”. in which

the rules are clear and known, and the situation is
considered stable. In situations with these problems, a
defined ruleset of best practices can be followed. The
advice given by the framework is "sense, categorize,
respond", meaning that one observes the problem ,
categorizes it into existing categories and applies the
standard solution for that category.
2. Complicated problems are ones where "known unknowns"

exist, meaning there is awareness of what is not known.
These are situations where experts can be consulted, and
conducting deeper research can lead to solving the
problems. Good practices may be identified based on the
analysis conducted. The frameworks advice is thus similar
to that for simple problems but replaces "categorize" with

a more in-depth look .
"analyze", indicating a need for
3. Complex problems are ones in which the "unknown

unknowns' dominate . The nature of cause and effect
cannot be known in advance ; thus, categorization or
conventional analysis will not be useful. According to the
Cynefin-Framework , the proper approach is thus to "probe ,
sense, respond", meaning that experiments should be
undertaken, of which the results can be observed, and
actions can then be defined accordingly. It is impossible to
plan the actions far in advance as the nature of the
metaphoric playing field has yet to be discovered .
4. Chaotic problems are ones where any knowledge-based

response is not possible , and the rules of cause and effect
cannot be deducted. The advice given by the framework is
"act. sense , respond", which differs from complex problems
insofar that the first step is to take immediate action rather
than experiment first . The goal is to take effective action -
as reasonable as can possibly be estimated with good
judgment - and based on observations, determine a way to
turn the problem from a chaotic one into a complex one.
In the context of product development , those categories imply the

following respective approaches;
1. Simple: inspect the problem beforehand, choose the
appropriate methods and tools , implement the solution
2. Complicated; analyze the problem beforehand, choose the

methods and tools that appear most appropriate, implement
the solution
3. Complex: run an experiment, evaluate the result and

determine the best course of action based on the insights
gained
4. Chaotic: do anything, evaluate the result, based on that

determine the best course of action to turn the problem into
a complex one
The Scrum Guide states that Scrum is appropriate for complex
problems, which is consistent with the ideas of the Cynefin
framework: Scrum is founded on empiricism . 1 with the three
pillars of "transparency" , '’inspection" and "adaptation", which are
mirrored in the Cynefin framework's recommended response for
complex problems:
1 . "probe " , which aims at generating data, or in other words,

creating transparency
2. "sense", which describes the inspection of the generated

data
3. ’respond", which means to take appropriate action based on

the newly won insights, or in other words to adapt actions to
the situation as it is now understood
By " address [. . . ] adaptive problems" the Scrum Guide claims

that Scrum is capable of addressing problems that are not static
but can change over time . While many conventional approaches
to product development assume the general environment of the
product during its development to not change in fundamental
ways, Scrum acknowledges that the conditions of the problem
may change over time.
A problem that is complex but not adaptive may be solved by
conducting an experiment (probing) once, evaluating it (sensing)
and executing one derived set of actions ( responding). If the
problem itself changes though (adaptive problem), the derived
set of actions may be outdated This can be avoided by repeating
the process of probing, sensing and responding often enough to
adapt to the problem, while not too often to hinder actual
see the section on empirical process control on pages 24H

2 Definition ot Scrum 10
progress in developing the solution to the problem. This is the

basis lor the iterative nature of Scrum.
Example: a company develops a mobile app. At the beginning of
the development, it is estimated that building the entire app to
fulfill the current expectations will take 24 months. Considering
this as a static problem would mean to assume that in 24 months ,
the conditions around the app will still be the same, and
development could be done with an approach like the Waterfall
Model.
In contrast , considering it an adaptive problem recognizes that
the conditions surrounding the app may change significantly
within the development period. In this example, hardware
specifications could change, such as higher- resolution screens
demanding other designs or the newly widespread availability of
NFC in phones creating new opportunities for the app that were
not initially planned , Alternatively, potential customers'
expectations for the app may change, as competitors may set
standards with their applications.
Thus, it should be considered an adaptive problem and is hence
a problem for which Scrum may be a valid framework to choose
due to its iterative nature.
Using the adjective "productively " highlights Scrum's focus on

efficiency. Scrum aims to utilize the available ( human) resources
efficiently. This focus can. for example, be seen by the use of
time-boxes or the concept of the Daily Scrum , which aims to
increase productivity by facilitating a high-density exchange
aimed at synchronizing the entire team, rather than letting
information spread decentralized and risking miscommunication,
which would lower productivity.
The adjective ”creatively " outlines the necessary approach to

solving the problems , which earlier in the sentence were outlined
to be complex and adaptive. Unlike simple or complicated
problems, for which best practices may already exist , complex
problems - and complex adaptive in particular - require trying

new approaches often and thus require creativity. 2
Finishing the sentence with " delivering products of the highest

value" again underlines the focus on productivity, but also
emphasizes that the key metric in product development with
Scrum is the value delivered to the stakeholders and especially to
the final users. This is a crucial factor in the Scrum mindset ,
especially for Product Owners: a key measure of whether Scrum
is applied properly is whether every iteration aims to deliver the
highest possible value product.
To illustrate: A Sprint spent on cleaning up technical debt (often

called a "hardening Sprint”) could at first glance be considered a
good idea. However , it is not conforming with Scrum as it does not
deliver the maximum value possible to the stakeholders.
When the Scrum Guide uses the term "product", this includes
physical and non-physical products, as well as services of any
kind.
Scrum is:
• Lightweight
• Simple to understand
• Difficult to master
Listing these three attributes of Scrum illustrates the sharp
contrast between the ease with which Scrum can be grasped due
to its light setup, on the one hand, yet difficult to understand
in-depth on the other .
1. Characterizing Scrum as "lightweight refers to two aspects:
2 for
a wider definition of creativity in the Scrum context and how Scrum
optimizes for creativity, see pages 55fT
a) The number of prescriptive rules and definitions

Scrum forces on those who choose to apply it is
relatively low. This can be powerfully illustrated by
comparing the Scrum Guide, with its less than 20
pages , to the official guide for the V-Model XT, which
contains more than 400 paqes. (21
b) The amount of time the events Scrum demand

creates relatively little overhead. It does not demand
hour-long status meetings and time-intensive written
updates within the team but instead has relatively
short, time-boxed, face-to- face meetings. In terms of
staffing and role division, Scrum can also be
considered lightweight , as it recognizes merely three
roles and centers the product creation within the
Scrum Team itself, instead of demanding various new
levels of hierarchies with titles and complex chains of
command.
2. Scrum is "simple to understand" in so far as reading the
Scrum Guide a few times will get one to understand the
overall concept , especially the more practical aspects ,
mainly the events and. to a lesser extent , the roles and the
artifacts. With only a few hours of studying Scrum, it would
be possible to observe a Scrum Team in action and identify
many of the patterns described in the Scrum Guide.
3. While Scrum may be easy to understand, it is "difficult to

master” particularly because it is lightweight. Scrum is
,
based on a broad set of axioms about how people can

work together to deliver value.
It addresses these assumptions not only with explicit rules
but with a foundation of values. 3 Understanding how to use
the ideas of Scrum and apply them in situations not
explicitly covered by the Scrum Guide in the "Spirit of
Scrum” is what differentiates a novice from a master .
3
see chapter on Scrum Values on pages 39«.
Reaching this stage requires arguably much practical

experience , theoretical knowledge and introspection, and
thus mastery of Scrum can be considered truly difficult.
Scrum is a process framework that has been used to manage

work on complex products since the early 1990s.
With this, Schwaber and Sutherland define the origins of Scrum .

Based on the given time, it can be assumed that they understand
their initial, separate approaches to be the roots of what we now
call Scrum. Rather than defining their first joint paper outlining
Scrum in 1995f 3l as the birth of Scrum, they choose to include the
early emergences. From this, it can be deduced that Scrum itself
is not considered "finished' by the creators, that it was not placed
into existence at a specific time to remain static for all times, but
instead is itself a continually improved increment through updates
to the Scrum Guide.
Scrum is not a process, technique, or definitive method.

Rather, it is a framework within which you can employ
various processes and techniques.
Scrum can be thought of as a container , within which those

driving the development are relatively free to choose their
approaches. In his book "Agile Project Management with Scrum"
[ 41, Schwaber outlines in the foreword "Why Scrum Works" that a
crucial aspect for the success of product development with
Scrum is that it acknowledges that in complex projects decisions
should best be made is by the people actually conducting the
work.
This sentence once again emphasizes that Scrum is not to be

considered as anything beyond a framework , within which the
people involved are free - and in a sense obligated - to choose
other tools and paradigms according to their needs.
The only requirement for these additions is that they must comply
with the rules outlined by Scrum, including the values and
ownership regulations. Thus, it is acceptable, for example, to use
Test Driven Development, run Product Discoveries or utilize
Kanban metrics and WIP-limits as the Scrum Team sees fit. It is
on the other hand not acceptable for the management to enforce
upon a Development Team the way in which they work on their
Sprint Backlog via prescribing Gantt charts, as this would violate
the Development Team s ownership of the Sprint Backlog. 4
Scrum makes clear the relative efficacy of your product

management and work techniques so that you can
continuously improve the product, the team, and the
working environment.
The introduction of Scrum in projects is often considered painful

because it reveals problems in the existing product management
and makes issues that are hindering better performance
transparent. Scrum, with its basis on empirical control theory 5 , is
based on making things transparent in order to inspect them and
adapt to the situation of newly gained information. The goal of
Scrum, in a way, is perpetual improvement aimed towards
-
ever greater value delivery.
This is one reason why Scrum may only be adopted in its entirety,
including the roles and terminology. Scrum is meant to break with
conventional product and project management paradigms and
allow the transparent inspection and consequent questioning of
existing methods.
With this sentence, the Scrum Guide further stakes the claim, that
Scrum is not only aimed at improving the product but also
4
foe more on the Development Team’s ownership of the Sprint Backlog see the
section on the Sprint Backlog on paoes 187 ft.
5
see the section on empirical process control on pages 24ff .
• the team who develops the product, for example by fostering

attributes such as trust by emphasizing the Scrum Values6
, and
• in a second step the working environment , later in the Guide

referred to as "organization", by scaling the Scrum thinking
beyond the Scrum Team into other parts of the organization;
typical examples here are the sales department and the HR
department
This last section of the sentence was only placed into the Guide
with the latest update in 2017.
The Scrum framework consists of Scrum Teams and their

associated roles, events, artifacts, and rules, Each
component within the framework serves a specific purpose
and is essential to Scrum's success and usage.
This is often summarized by a quote from the section Endnotes7 ,

'Scrum is .. . immutable", meaning that there is a carefully
crafted balance between the components, which will be
inspected in this book. Using only parts of Scrum may be useful
- e g. , using Sprints or having standup-meetings in the fashion of
the Daily Scrum - but is not Scrum. Similarly, leaving out and
ignoring components that appear not to fit the business situation
reduces the potential positive effects that Scrum may bring.
A typical real- world example for this is adopting most ideas from
the Scrum Guide but putting one Project Manager in charge of a
Development Team, instead of providing it with a PO and Scrum
Master. This may be done because higher management does
not trust a self-organized , ’unmanaged" team to deliver relevant
results, or even merely due to office politics.
‘see chapter on Scrum Values on pages 39ft

7
.
see chapter Endnotes on page 207
The resulting construct may still be better than the previous

arrangement , but it does not allow Scrum to unfold its full
potential and hence is not Scrum. The roles, events, artifacts and
rules are not created apart from each other, but as a system ,
which can only function if all components are in place.
The rules of Scrum bind together the roles, events, and

artifacts, governing the relationships and interaction
between them. The rules of Scrum are described throughout
the body of this document .
With this paragraph , the authors emphasize again
• the interconnectedness of Scrum's parts via its rules, which

are laid out in the sections of the Guide
• the Guide’s claim as the definitive source of Scrum in

general and its rules in particular
It also outlines that while Scrum does not regulate every single
aspect , it does prescribe the kind of interactions deemed most
appropriate . An example for this is that not only are the positions
of Product Owner and Development Team described , but also it is
clarified that these two are not in a hierarchical relationship with
each other, but both - together with the Scrum Master - make up
a Scrum Team , in which all operate on eye-level.
Specific tactics for using the Scrum framework vary and are
described elsewhere.
The authors contrast the use of Scrum as a general framework

with specific tactics for using it , e g., through the application of
other techniques and methods, for example, different manners in
which to conduct a Daily Scrum.8 While these tactics may be
'see explanation of the use of the three questions in the Daily Scrum on pages
*
143 .
useful depending on the situation, they should be tailored to the

needs of the respective Scrum Team and are hence not part of
the Scrum Guide. In turn, it clarifies again that the Scrum Guide
is not a complete manual for all aspects of product development ,
but rather a basis on which teams can organize themselves and
their processes.
3 Uses of Scrum 18
3 Uses of Scrum
Scrum is very heavily associated with software development due

to its origins being in this field. Even to this day, the Wikipedia
article differentiates the framework "Scrum" from the rugby
method by giving the former the title "Scrum ( software
development) ".[51
This entire section was added in the latest edition of the Scrum
Guide in 2017. It is likely that with this section, Schwaber and
Sutherland aim to emphasize that the Scrum is applicable not
only in the area of practical software development but also in the
surroundings of software development, as well as entirely other
fields altogether.
Scrum was Initially developed for managing and developing

products. Starting in the early 1990s, Scrum has been used
extensively, worldwide, to:
1. Research and identify viable markets, technologies,

and product capabilities;
2. Develop products and enhancements;
3. Release products and enhancements, as frequently as

many times per day;
4. Develop and sustain Cloud (online, secure ,

on-demand) and other operational environments for
product use; and,
5. Sustain and renew products.

3 Uses of Scrum 19
Scrum has been used to develop software, hardware,

embedded software, networks of interacting function,
autonomous vehicles, schools, government , marketing,
managing the operation of organizations and almost
everything we use in our daily lives as individuals and
societies.
With this list and the subsequent elaboration, the authors clarify
that they believe that Scrum has been and continues to be
applicable in various fields and use cases, including, but not
.
limited to software development.
As technology, market, and environmental complexities and

their interactions have rapidly increased, Scrum s utility in
dealing with complexity is proven daily.
The first half of the sentence claims that the overall complexity in
which product development is conducted has increased. A
comparison of today s lives with that of one generation prior
reveals that while life back then may not have been easier, it was
certainly less complex .
Arguably the driver for this increase in complexity is the increase

in technology. Cheap availability of computational power ,
technological advances in fields such as mobility, radio
technology and various other fields, and the societal changes this
brings about, may make life arguably more comfortable, but
certainly also more complex . Examples of this are the
emergence of the internet and social media, the spread of
smartphones, the affordability of (intercontinental) travel and its
effects on the business world and the globalization of supply
chains.
According to the Guide, Scrum is capable of dealing with this
increase in complexity and is an appropriate tool to use as
problems needing to be solved become increasingly complex.
3 Uses of Scrum 20
Scrum proved especially effective in iterative and incremental

knowledge transfer.
When initially setting up Scrum in an environment, it causes a

.
disruption Rules, terminology and workflow have to be changed,
and those involved need to adapt to the new circumstances. This
is why Scrum is often considered a more disruptive framework
compared to, e.g. Kanban, which is seen more as an evolutionary
t
method of gradual changes.

Beyond this initial disruption, however, which is used to clarify the
relative efficacy of the existing product management and work
techniques, Scrum focuses on incremental change. Within a
Scrum environment, products are built in an iterative manner, in
which the exchange of knowledge is fostered by:
1. Inspection and adaptation during the four Scrum Events

within a Sprint
2. The requirement of -
self organization and
cross- functionality
^
3. Particularly the Scrum value of openness , in the form of

^
a) The openness to spread existing knowledge

b) The openness to gaining new knowledge
1
for an explanation on the terms sett -organization and cross- functionality, see
the respective definitions on pages S3 ft.
2
for an explanation of the value of openness see page 49
,
3 Uses of Scrum 21
Scrum is now widely used for products, services, and the

management of the parent organization.
According to this sentence. Scrum can be used not only in

product development but also in managing a company inside
which products are developed.
While arguably most applications of Scrum are in individual
teams working on one respective product, frameworks exist that
scale Scrum to work with several teams working on the same
product, such as LeSS, Nexus and Scrum@ Scale. These are
further elaborated on in the next paragraph of the Guide.
When thinking of a more conventionally managed, medium to
large product development , one potentially encounters several
layers of management , hierarchical structures, and reporting
structures.
Scrum replaces this with a relatively easy to understand the

structure , which even at scale maintains its focus on
self-organization of teams and high- value delivery. When looking
at an organization, we encounter similar situations: hierarchies ,
management layers, reporting structures, while the true purpose
of the company lies in delivering a specific value as well as it can.
Hence Scrum can be scaled beyond the product development
into other parts of an organization, including the management
itself . While this is still an arguably underutilized use of Scrum, it
is one that the authors appear to deem important enough to add
it to the Guide with the 2017 revisions.
The essence of Scrum is a small team of people. The

individual team is highly flexible and adaptive. These
strengths continue operating in single , several, many, and
networks of teams that develop, release, operate and sustain
the work and work products of thousands of people. They
collaborate and interoperate through sophisticated
development architectures and target release environments.
3 Uses ol Scrum 22
Scrum is built around small teams as its core unit. A team must
be large enough to deliver value , but small enough to allow for a
good communication level within the team. At an absolute
maximum of eleven people 3 . Ihe team maintains the possibility of
self-organization.4
This is important as it allows in for the people encountering a
problem to be the ones to work on solving it and having the
necessary skills and empowerment to do so. Opposed to this are
more conventional, hierarchical organizational structures, where
problems usually would need to be passed up a chain of
command. Hence a Scrum Team has the advantage of being, as
the Guide puts it. highly flexible and adaptive .
An initial thought when considering the development of larger
products might be to add a layer of conventional management
over individual Scrum Teams, for example, in the form of, e.g., a
VP of Engineering, or a VP of Product . However, this would move
decision-making out of the teams and. hence, violate the Scrum
Team as the core entity for problem- solving and decision- making.
The Scrum Guide argues that extrapolating the Scrum Team
concept into an environment with several, many or even networks
of teams is possible and that throughout the scaling, it is possible
to maintain the benefits of flexibility and adaptivity.
While not committing to a specific way to scale Scrum in this

Guide, this paragraph claims the general possibility of developing
products with Scrum with more than one team. As Scrum is
gaining further adoption in product management around the
world , it seems to have been important to the authors to
emphasize both that:
• Scrum involving potentially up to thousands of people is

possible, but also that
3
nine developers, one Product Owner one Scrum Master
,
4
lor an explanation on the terms self-organization, see the definition on pages
53ff
3 Uses of Scrum 23
• this can only function if what the Guide calls the "flexibility
and adaptability" - which others may call "agility" - remains
intact as the team remains at the core of decision making
as much as possible .
When the words "develop" and "development ” are used in

the Scrum Guide, they refer to complex work , such as those
types identified above.
The terms "develop" and "development" are often associated with

software development , where Scrum has its origins. However, as
the Scrum Guide points out extensively in this section , they are
not exclusively to be understood in the context of software
development , but anything in terms of delivering value to people
by incrementally solving complex problems.
An example cited in another paragraph of the Guide is marketing,

where Scrum could be used to develop a new multi-media
marketing campaign. Instead of developing top-down , possibly
dividing tasks up and passing them to individual people, a small
team of "developers" could address the task . The "developers" in
this case would be marketing professionals and designers. They
would work iteratively to add new features to the campaign often
while conducting tests with stakeholders and potential future
target audiences throughout the development process .
4 Scrum Theory 24
4 Scrum Theory
Scrum is founded on empirical process control theory, or

empiricism. Empiricism asserts that knowledge comes from
experience and making decisions based on what is known.
In epistemology, the theory of empiricism asserts that knowledge

can only or primarily be gained through experiences, rather than,
for example, solely or primarily through reason, as the theory of
rationalism argues. The German philosopher Kant argues that
these two theories can be contrasted as such161
• Some knowledge can be derived primarily logically based

on a limited number of axioms. A typical example is the
field of mathematics, where no experiment is necessary to
validate that 2 + 2 = 4 is a valid statement. If the axiom that
1 + 1 = 2 is accepted, applying logic, in this case, deductive
reasoning, will yield this result. This knowledge is
described as a priori knowledge, as it can be gained prior
.
to (i.e , before) running experiments verifying its
correctness.
• Some knowledge can be derived primarily through

experience. This is arguably the case in most natural
sciences and also everyday life. The question of whether or
not the average age of humans has increased in the last 50
years cannot be answered through pure reason, but rather
4 Scrum Theory 25
1. the hypothesis has to be formed, e.g., "the average

age of all human beings has increased between 1970
and 2020"
2. the data needs to be gathered and evaluated, i.e.,

different potential sources are identified and checked
for credibility, the data accumulated and checked for
consistency
3. the hypothesis is validated or falsified based on the

data. e.g. "based on the gathered data, the average
age of humans in 1970 was 21.4 years old and the
average age of humans in 2020 is 24.2 years old; thus
we conclude that the average age of humans has. in
fact, increased over time"
In cases like these, where knowledge is gained through
experiences and is therefore available only after
experiments, the term "a posteriori knowledge" is used.
_
The Definition section’ points out that Scrum is useful for complex
adaptive problems. Since a priori knowledge for such problems
is not possible , an approach of gaining a posteriori knowledge
has to be chosen; hence experiments have to be conducted and
evaluated and decisions should be made in a data-driven manner
,
rather than through intuition.
An important aspect to consider is that insights gained

empirically are only approximations. They may be falsified in the
future as more data become available or made obsolete as
models are developed that address a problem more
appropriately. From this, we can derive that:
• inside Scrum everything should be questioned; for every

approach , technique and method , it may turn out that one
exists that is more suited to the current situation
see chapter 'Definition of Scrum" on pages §

4 Scrum Theory 26
• Scrum itself is open to change over time - as it has in a

handful of revisions - since newly gained insights may help
us find a superior way of conducting Scrum
Scrum employs an iterative, incremental approach to

optimize predictability and control risk. Three pillars uphold
every implementation of empirical process control:
transparency, inspection, and adaptation.
As knowledge for most problems facing teams in product

development is of an a posteriori nature, there is always a chance
of failing . When approaching a problem to which an answer can
only be known after an experiment, there is an inherent risk of
failure. In product development , this may mean that development
is going in the wrong direction: for example, that the product
being developed is what is assumed to meet the demands of the
market , but once released fails miserably, as it does not .
This risk is inherent in trying to solve complex problems. While

Scrum cannot remove that risk, its approach can make that risk
more controllable and create higher predictability. These two are
interdependent, as higher predictability lowers risk, and a
controlled risk yields higher predictability in the development
process.
The approach Scrum takes to address these issues is its iterative

and incremental approach. While these terms are sometimes
wrongly used synonymously, they describe two fundamentally
different concepts:
• An incremental approach to a problem means that instead

of solving the entire problem at once, it is split into smaller
units and solved step by step, building on top of the
previous one . In Scrum, the product is not developed in
one piece with all functionality ready. Instead, a piece of
high- value functionality is added each Sprint on top of the
existing product , called together the Increment .
4 Scrum Theory 27
• An iterative approach is one where the same overall

process is repeated and only altered in a controlled
manner. In Scrum, every Sprint looks roughly the same.
While the contents of what is being developed may change,
the general layout remains the same: Sprint Plannings
takes place in the beginning, Daily Scrums are conducted.
Reviews are held, and Retrospectives are done. While
small, controlled experiments may be conducted, such as
shortening the timebox for the Retrospective by 15 minutes
or trying out a new format for the Review, the overall flow
and the underlying principles remain constant .
The iterative approach makes things more predictable. On the
one hand, doing things the way they have been done before
makes it likely that - aside from massive disruptions - things will
work at a similar level of efficiency. On the other hand, it allows
for variations in the results to be noticed. Every iteration can be
seen as conducting the same experiment with roughly the same
conditions present, allowing for comparisons, which creates the
transparency necessary for inspection and adaptation. In Scrum,
every Sprint can be seen as an experiment, testing for the best
way to deliver the most value to the stakeholders.
The incremental approach limits risks by only taking one step at a
time and inspecting the results before taking the next one . While
this creates the overhead of having to inspect regularly, it also
limits the risk to one of these steps , which may have been in the
wrong direction. In Scrum, a Sprint may fail for any number of
reasons, not least common of which is that what was developed
was simply not what the stakeholders want . A "wasted” Sprint is
nothing anybody would initially be happy about . However, it is still
significantly better to have wasted a maximum of one month:
developing something wrong than developing a product for
potentially multiple years, just to learn in the end that all of it is
not to the stakeholders liking.
2
the maximum duration of a Sprint
4 Scrum Theory 28
Furthermore, mistakes in product development quickly lead to

more mistakes being made, known as the propagation of errors.
In a software product development , an early misunderstanding
may lead to a wrong interface design, which may lead to an
incorrect structuring of data in the database, which leads to new
functions build specifically for that data model being unusable
once the structure is altered, etc.
Analogously, taking a step in the wrong direction and correcting
course may lead to a messy line, but it is better than marching
straight in a straight line in the wrong direction. By building
software incrementally and inspecting iteratively, Scrum limits the
risk of compounding errors, which may otherwise be detrimental
to the project as a whole.
4 Scrum Theory 29
4.1 Transparency
Significant aspects of the process must be visible to those

responsible for the outcome.
The underlying necessity for empirical process control to function

is transparency. The first sentence of the definition outlines how
transparency is to be understood in the Scrum context: The
phrase "Significant aspects of the process" outlines that the
requirement is not absolute transparency, but rather one limited
to those aspects that are deemed significant . Two reasons for
this can be outlined:
1. Absolute, full transparency is not desirable. A typical

example is the confidentiality level of the Retrospective .
While it is not outlined in the Scrum Guide, it is common for
a Retrospective to be conducted under the so-called
" Vegas Rule" in practice. This rule is based on the
American idiom "what happens in Vegas, stays in Vegas”,
meaning that the things discussed during the
Retrospective remain within the circle of its participants , if
not defined otherwise. In this case, absolute transparency
and the idea of trust in Scrum would collide.
2. Absolute, full transparency is not practical. In the context of

Scrum, transparency is to be understood as a rather
technical term. It refers to the possibility of others to see
and understand what is happening. This requires effort ,
which may not be justifiable. For example, it may be
possible to thoroughly document a newly created piece of
code so that a stakeholder with no prior technical
knowledge can understand it. However, the effort to create
this documentation would likely far exceed the potential
benefits of the stakeholder understanding the code.
In this sense, the word "significant" can be understood as

4 Scrum Theory 30
describing that which is relevant and whose transparency can be

believed to generate a net gain towards value creation.
When speaking of "those responsible for the outcome”, the

Scrum Guide implicitly includes the stakeholders affected as
those responsible. Although one may initially think that only the
Scrum Team is referred to, the phrase can be understood much
more broadly as referring to anyone who has a stake in the
outcome, i.e., the stakeholders.
Agile product development understands the stakeholders to not

merely be in the role of taking the ready product, but instead as
responsible for shaping the product by contributing their inputs.
Thus, a reasonable level of transparency, i.e., regarding
significant aspects of the process, must be brought towards not
only the Scrum Team but also the stakeholders. To give an
example, the Scrum Guide states in a later section regarding the
progress towards goals that "[tjhis information is made
transparent to all stakeholders ”
Transparency requires those aspects be defined by a

common standard so observers share a common
understanding of what is being seen.
For example:
•A common language referring to the process must be

shared by all participants; and,
• Those performing the work and those inspecting the

resulting Increment must share a common definition of
"Done ".
In this second part of the definition, the requirement for
transparency is outlined, namely the common understanding of
what is being observed, which requires common definitions.
.
While everybody may sense the same, i.e , take in the same
3
see section Monitoring Progress Towards Goals on page 183
4 Scrum Theory 31
stimuli through their senses, the interpretation ot what is being

sensed, will vary depending on a wide array of factors. Creating a
list of commonly shared definitions for things being commonly
observed reduces the possibility of different interpretations. Thus,
transparency requires a reasonable degree of standardization.
Picking up the second example given by the Scrum Guide, the

term "Done” may hold different meanings for different parties
involved in the development process. While for a programmer,
" Done" might mean that a piece of code is fulfilling the specific
requirements outlined in a task , a QA specialist may require that
a pace of code is tested with integration tests and comes up
without problems. A Product Owner may, in turn, understand
"Done" as something that can be delivered to the customer
following some further work on migrating existing data. In
contrast , the customer may take "Done" to be ready to be
activated at the press of a button.
In the scenario described above, the same observation , i.e.,

seeing or hearing the word "Done", raises widely varying
expectations. To avoid this. Scrum requires the necessary
transparency to be created in the form of a definition of "Done"
( DoD), to which an entire subsection of the Scrum Guide is
dedicated. 1
A common standard regarding the meaning of used terminology
allows for expectations to be synchronized and communication to
be more efficient or - in some cases - even practically functional
at all.
Furthermore, transparency requires clear definitions of

measurements prior to insF>ection. When for example, evaluating
the efficiency of a newly introduced technique, the measured
variab)e( s) of "efficiency”, for example , the number of Story Points
finished par week, must be defined and, in turn, commonly
shared across those conducting the inspection .
‘see chapter on the Definition of "Done" on pages 202

4 Scrum Theory 32
4.2 Inspection
Scrum users must frequently inspect Scrum artifacts and

progress toward a Sprint Goal to detect undesirable
variances.
The term "Scrum users" is ambiguous and could in this context be

meant to refer to two things:
1. It refers to the roles in the Scrum Team and is used instead

of the term "Scrum Team' since not the entire team
necessarily inspects all artifacts.
2. Aside from the Scrum Team , it is meant to include all those

participating in the product development under Scrum,
including the stakeholders.
The Scrum Guide requires transparency about the progress

towards the Sprint Goal towards all stakeholders. It further
requires that Reviews are conducted with key stakeholders
present and that during the Review, all artifacts are inspected:
• By looking at which Product Backlog items are "Done" and

which ones are not "Done", and what went well and what
problems occurred, the Sprint Backlog is inspected
• The combination of the previous increment and the "Done"

Product Backlog items create the new Increment , which is
being inspected during the Review
• As the Product Owner presents the Product Backlog and

the entire group ( Scrum Team plus key stakeholders)
collaborates on what to do next , the Product Backlog is
inspected during the Review
Thus, it may be assumed that the term "Scrum users" in this case
includes (key) stakeholders. Each individual inspects artifacts
and the goal according to their respective role in the process. For
example, the Product Owner frequently inspects the Product
4 Scrum Theory 33
Backlog and the progress, while the Development Team

frequently inspects the Sprint Backlog. In the inspection process ,
commonly agreed-upon measures, which are defined in the
process of creating transparency, are to be used to a) observe
possible variances from agreed-upon conventions and b)
determine whether these are undesirable and warrant further
action in the phase of adaptation.
Their inspection should not be so frequent that inspection

gets in the way of the work.
The inspection aims at detecting upcoming problems and allows

for possible solutions to be devised and implemented quickly.
Thus, in theory, there should be a virtually constant inspection of
all inspectable things. In practice, however, this would cause a
problem, as the ones who are conducting the inspections are
(primarily ) those doing the work that is being inspected, meaning
no work would be done, as everybody would be busy only
inspecting.
While with these extremes, it may seem obvious, finding the right
balance of inspection and work in practice may be difficult. For
this reason, the Scrum Guide explicitly outlines that during the
Planning, Daily, Review and Retrospective inspection and
possible adaptation must take place, effectively defining a
minimum number of opportunities for inspection and
adaptation.
As the required amount of inspection may vary depending on the

circumstances. Scrum does not prescribe anything more
concrete beyond that inspection should not get in the way of the
work . Herein it can be seen that Scrum is a framework rather
than a definitive methodology.
4 Scrum Theory 34
Inspections are most beneficial when diligently performed by

skilled inspectors at the point of work.
When speaking of inspection, it must be clarified whom the

inspectors are ideally supposed to be. In this sentence , the
Scrum Guide gives three criteria, which, when fulfilled, lead to
the most beneficial inspection . The inspectors should:
• inspect diligently, meaning carefully and with a lot of effort.

This includes the courage to inspect according to the
metrics agreed upon prior, regardless of what may be
uncovered. Diligent inspection lives on the courage to
uncover things even if their revelation may be
uncomfortable or inconvenient to individuals or groups. A
diligent inspection into the reasons for a part of a product
causing technical problems may uncover, that errors were
made by developers and not discovered in testing. This
situation may be initially uncomfortable, especially for the
developer who made the mistake and the developer who
conducted the testing, but a thorough inspection
nonetheless uncovers this, as only that way, adjustments to
the process, what the Scrum Guide calls 'adaptations', can
be made and the value delivery to the stakeholders can be
maximized.
• be skilled. This is a broad term which is once again due to

,
the wide variety of products that may be developed with

Scrum. What skills exactly are necessary is highly
contextual, though it should be ensured that those
conducting the inspection are skilled , i.e. . have the
capabilities to uncover what needs to be uncovered.
• conduct their inspections at the point of work. This is an

important notion, as it breaks with the setup of
conventional product development as is still practiced in
many organizations, namely the separation of the
development and the inspection, usually performed by
some form of a Quality Assurance (QA ) department.
4 Scrum Theory 35
While an inspection by an inspector external to the Scrum

Team has advantages , one of which is the greater degree
of objectivity, as those inspecting a product are not the
ones who have built it and are therefore less error-blind
and less biased. The Scrum Guide , however, argues that
inspection at the point of work , which in most cases means
by the Scrum Team ( or a respective subset thereof ) , is
more beneficial. This is likely because those who develop a
product are automatically those most familiar with it ,
meaning the degree of information is highest at the point of
work , which - when done diligently and skillfully - leads to
the best insights and thus the most beneficial inspection
overall.
4 Scrum Theory 36
4.3 Adaptation
If an inspector determines that one or more aspects of a

process deviate outside acceptable limits, and that the
resulting product will be unacceptable, the process or the
material being processed must be adjusted. An adjustment
must be made as soon as possible to minimize further
deviation.
If a deviation is identified, measures should be taken as soon as

possible to correct the underlying problem. It is important to note
that this adaptation will in itself just be an experiment, the
.
outcome of which needs to be empirically assessed While there
may be educated guesses as to what could constitute a proper
adjustment , the outcome of the process with the adjustment
made needs to be again inspected, and further adaptation
( attempts ) may be necessary.
Scrum prescribes four formal events for inspection and

adaptation, as described in the Scrum Events section of this
document:
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective
All events within a Sprint are to be used for inspection and
adaptation. This emphasizes the importance of empirical process
.
control within Scrum It can even be argued that Scrum itself is
primarily a setup for systematized inspection and adaptation
since all events in Scrum serve -
among other things -
the
purpose of empiricism in some form and the only way that
4 Scrum Theory 37
progress can be made and understood is through empirical

process control.
4 Scrum Theory 38
This section on empirical process control gives a very technical

outline. It is interesting to look beyond that , at the practical
implications such an approach has in environments where
product development is still dominated by a non-empirical
mindset:
Working on a complex problem occasionally, yet inevitably, leads
to failures, e.g. , a Sprint that delivers little or no value ;
conventional thinking may be quick to attribute blame, thinking
that the Scrum Team is guilty in some way for failing. This is
based on the assumption that the "right" way of working on an
issue could have been known beforehand and that it is a
shortcoming of the Scrum Team not to have put in the effort to
find it.
A key implication of understanding empirical process control,
however, is that the "correct" way of working on a problem does
not exist . There may, in theory, be a perfect way in which to
develop a specific product ; it is not possible to know this way in
advance due to the complex nature of the problem . Hence the
entire process is a series of controlled experiments and
data-driven decisions aiming towards the overarching goal of
value delivery as efficiently as possible.
Norm Kerth, author of the book Project Retrospectives: A

Handbook for Team Reviews, thus suggests framing
retrospectives with what he calls the Prime Directive:
" Regardless of what we discover, we understand and truly believe
that everyone did the best job they could, given what they knew at
the time, their skills and abilities, the resources available, and the
situation at handT71
5 Scrum Values 39
5 Scrum Values
Values are the drivers of behavior. They allow individuals and

teams to make decisions for which there is no prescribed rule.
Scrum as a framework provides relatively few rules, leaving
decisions on interactions between individuals, techniques and
methods, and specific courses of action up to the Scrum Team.
For the decisions on these, the Guide provides a set of values on
which Scrum is based
In Scrum, these values are aimed at fostering empirical process
control as a means of achieving higher productivity and better
value delivery by the Scrum Team.
The Scrum Guides chapter on values is relatively new, having

only been added in 2016.
When the values of commitment, courage , focus, openness

and respect are embodied and lived by the Scrum Team, the
Scrum pillars of transparency, inspection, and adaptation
come to life and build trust for everyone.
In this first sentence of the value section, the Guide claims a
causal relationship between embodying and living by the five
values on the one hand and the functionality of empirical process
control, as well as the emergence of trust.
The Scrum Guide distinguishes between embodying and living of
values:
• The -
Merriam Webster dictionary defines embodying as
representing something in human form, to be used as a
5 Scrum Values 40
possible synonym for personifying. In the Scrum context ,

’embodying' , the values can be understood as acting on
them, i.e. , aligning one's actions by the values.
• "Living" in this context refers to the internalization of the

values into one's regular behavior and thinking and
decision-making process.
Doing both , according to the Scrum Guide, leads to the ’ Scrum

pillars’ coming to life. This is a poetic formulation for the
functionality of empirical process control, which strongly benefits
from the presence of realized Scrum values. The relationship
between the values and empirical process control will be
elaborated in the next sections.
Another result of embodied and lived Scrum values is the

emergence of trust . Trust is defined by the Cambridge English
Dictionary as the belief "that someone is good and honest and
will not harm you. or that something is safe and reliable". It
provides the basis for collaboration within a team, particularly a
self-organizing one. The relationship between the values and the
emergence of trust will also be elaborated in the next sections.
The Scrum Team members learn and explore those values as

they work with the Scrum events, roles and artifacts.
Values cannot be taught academically. It may be possible to

understand them and their intent sufficiently to be able to embody
them , for example, by giving a proper answer to a case study
based on the internal logic of the values. In order for Scrum
Teams to be successful, however, they must not only embody the
values but live by them. This requires not only an understanding
of the values but acceptance of them and integrating them into
one’s thought and decision-making process.
The way this can occur is by what the Scrum Guide refers to as
learning and exploring the values with Scrum's events, roles and
artifacts. In Scrum, all of these rely on the Scrum values'
5 Scrum Values 41
presence in one way or another. The way the Scrum Team

becomes proficient , which the subsequent sentence defines as
essential for successful use of Scrum , is by applying the values
experimentally, observing the results and drawing conclusions.
Seeing beneficial outcomes of applying the values reinforces
their acceptance and integration.
Example: The value of courage is a crucial one for Sprint
Retrospectives. A team has a difficult problem to address: for
multiple Sprints, it has been slowed down by an issue that
nobody wants to address, fearing negative repercussions . While
everybody is aware of the negative influences , nobody has the
courage to speak up about it yet .
During the next Sprint Retrospective, one member finally
addresses the issue, having built up the courage to do so.
Initially, this causes some trouble and discomfort within the team;
however, the team now works together to find a solution for the
problem. Over the next few weeks, the problem is mitigated , and
a clear path to resolution is visible to all members of the Scrum
Team .
The Scrum Team observed an act of courage, i.e., an
embodiment of the value of courage, leading to a positive
outcome for the individuals on the team and the team as a whole.
This positive reinforcement will make acts of courage more likely
in the future and work towards the integration of the value of
courage.
Successful use of Scrum depends on people becoming more

proficient in living these five values.
Scrum is a framework built around empirical process control.

" Successful use’ can be understood as improvements in the
application of empirical process control. Scrum has set up its
roles, artifacts and events to foster empirical process control.
Each of these depends on one or multiple of the values being
.
lived out by "peoplen i.e. , not only members of the Scrum Team
5 Scrum Values 42
but also even others in the organization or even external

stakeholders.
An increase in proficiency in living the Scrum values allows for
more effective events , more useful artifacts and roles acted out
more productively. All of these factors foster empirical process
control and make the product development process more
effective, efficient and risk-controlled.
5 Scrum Values 43
People personally commit to achieving the goals of the

Scrum Team.
People, referring to everyone with an active stake in what the

Scrum Team is developing, personally commit to the
achievement of the Scrum Team's goals. Having buy-in from
those involved ensures their willingness to do what it takes to
achieve the goals.
Commitment is listed first and provides the basis for the other
values to matter :
A team, in which no one is committed to the goal , has no intrinsic
reason to act courageously , as doing so would generate
discomfort to achieve something those involved do not care
about.
Such a team would also not focus on goals which it does not care
about.
It would furthermore have no reason to ensure openness , which
potentially leads to problems while not generating results the
team cares about.
Respect may or may not be present in such a team, though this
is dependent on the personal values of those involved, not due to
respect 's positive effect on generating outcomes.
Commitment fosters empirical process control by ensuring

everybody is taking an active stake in the outcome and becoming
involved both in the development process, as well as the control
of that process by empirical process control. A group that does
not care about the outcomes has no reason to improve the
process of generating those outcomes.
An example of visible results of low commitment is a Sprint
Retrospective with low engagement . The Scrum Team members
don't care about the goals of the team. Therefore, they have no
reason to improve upon this through retrospection.
Commitment fosters trust , as everybody can be sure that those
involved work actively towards a common goal. This provides a
5 Scrum Values 44
unifying factor and. therefore, a sound basis upon which issues

can be resolved and potential synergies utilized.
5 Scrum Values 45
The Scrum Team members have courage to do the right thing

and work on tough problems.
The Cambridge Academic Content Dictionary defines courage as

"the ability to control fear and to be willing to deal with something
that is dangerous, difficult, or unpleasant". When dealing with
complex problems, situations are bound to arise that require
actions to be taken or decisions to be made that are:
• unpleasant - making those involved uncomfortable, i.e. ,

providing feedback to a colleague or stakeholder about
perceived inappropriate behavior
• difficult - having no certainty that the issue can be overcome

• dangerous - carrying the risk of severe negative
consequences
Concerning these, courage refers to the Scrum Team members'
willingness to tackle such issues despite them being tough.
Courage also empowers the other values :
Commitment requires a belief that the goals set are achievable.
When courage is missing , people will be less inclined to commit
to goals, especially tough ones.
A lack of courage may lead to the Scrum Team losing focus of the
Sprint work and the team's goals , as it is much more inclined to
work on other things that are easier to accomplish.
Being open with each other carries with it the risk of being
( emotionally ) vulnerable by others on the one hand, as well as
offending others on the other. The willingness to do either is
significantly reduced if there is no courage, i.e., willingness to do
such things and carry such risks even though they are tough .
One can accept others as capable and independent. However,
truly respecting somebody entails a willingness for honesty with
them, as one respects them enough to assume they can handle
honest statements. Being honest can be easy at times, but at
others - usually, those where it truly matters - it can be tough . To
be honest , despite this, one needs courage.
5 Scrum Values 46
Courage fosters empirical process control by allowing the team to

run difficult experiments . Empirical process control is predicated
on running experiments to determine cause and effect relations,
which are not knowable beforehand in complex problems, and
adjusting accordingly. ' Running experiments carries with it the
risk of the hypothesis being tested being falsified , which is often
understood as a failure. This notion is especially strong if the
effort to conduct the experiment was high , i. e., conducting the
experiment was tough. Conducting experiments, i.e., working
empirically, despite these challenges, is what the value of
courage is about .
An example of visible results of low courage is a Sprint
Retrospective with unambitious results The Scrum Team
,
members may care about the outcomes of their work but are
afraid of potential negative consequences of trying new
approaches, most notably the risk of their experimental approach
being unsuccessful.
Courage fosters trust, as everybody can rely on each other to

tackle even difficult problems in pursuit of a common goal.
Overcoming difficult challenges together creates a bond of trust
between people, as their relationship has been successfully
challenged in the face of adversity.
*
see explanation of complexity in the Cynefin Framework on pages 711
5 Scrum Values 47
Everyone focuses on the work of the Sprint and the goals of

the Scrum Team.
To be successful, the Scrum Team must be able to focus on the

Sprint work. Doing the work necessary to achieve the Sprint Goal
is the highest priority for the Scrum Team members throughout a
Sprint. The Scrum Guide uses the term "everybody " , implying
that the need for focus goes beyond the Scrum Team to include
(key ) stakeholders. Supporting stakeholders' understanding of
the Scrum Team's goals and why focusing on them is critical to
success are among the tasks of the Product Owner and Scrum
Master within a Scrum Team.
Concerning goals , focus can be understood synonymously to
"goal-directedness", in that those involved ensure the highest
priority guiding their actions is achieving the commonly defined

goals.
Focus relates to the other values:

Without focus, commitment is merely an empty promise.
Committing to a goal that is then not pursued in a focussed
manner is not useful.
A consistent focus on common goals drives courage. The ability
to tackle difficult problems is necessary to achieve goals. A high
focus on a goal also provides motivation to step out of one's
comfort zone to tackle tough problems, which is courage.
Focussing on a higher common goal provides a shared purpose
among those pursuing them, which provides a solid basis for the
required mutual openness. Successfully working together to
achieve common goals allows respect to grow among those
involved.
Focus fosters empirical process control by bringing larger parts of

the work under the influence of empirical process control, makes
things more predictable and more consistently comparable.
A team that spends much of its capacity outside the scope of the
Sprint and not directed towards common goals spends much
5 Scrum Values 48
time on activities outside the view of Scrum s empirical process

control. Scrum s events are set up to inspect the Sprint s work
towards the team s goals. If only a share of the capacity is spent
on those, then Scrum will only be able to support the
improvement of that share.
Furthermore, empirical process control relies on experiments that
deliver the most meaningful results when the conditions of the
experiment are relatively stable, and only one or a few
parameters are changed. Focus on the teams work , mainly
manifesting in the vast majority of ( time ) capacity being spent on
work in the Sprint, allows conditions between different days and
between different Sprints to be more comparable, reducing
complexity and improving the possibilities of empirical process
control.
An example of visible results of low focus is chaotic Daily Scrums
with overly frequent changes to the Sprint Backlog and potentially
the scope of the Sprint . Forecasts in the Sprint Planning are
based on the perceived capacity of the Development Team. If
focus is lacking, which may manifest in members of the
Development Team working on things outside the Sprint, the
forecasts become vaguer. This leads to the need for more
frequent adjustments during the Daily Scrum, especially when
the amount of work spent on Sprint work strongly fluctuates
between days.
Focus fosters trust , as everybody can rely on each other to

pursue common goals and work with the highest priority to
achieve these. Having common goals and achieving them
through dedicated common work allows for trust to grow between
individuals.
5 Scrum Values 49
The Scrum Team and its stakeholders agree to be open

about all the work and the challenges with performing the
work.
Openness, as understood by Scrum, describes the willingness to

share key aspects of their work, such as the topic, the goals, the
intentions, the methods, the speed and the challenges. This
value applies to both the Scrum Team and its stakeholders.
Stakeholders must be open about their needs and provide
feedback to the Scrum Team. The Scrum Team, in turn, must be
open towards the stakeholders and share with them aspects that
in more conventionally managed product development may be
actively hidden, such as obstacles to work or critical feedback
towards the stakeholders. Furthermore, the members of the
Scrum Team must be open towards each other.
Openness relates to and fosters the other values:
When significant parts of the work are not visible, and it is not
possible to see what others are working on , agreeing to work
hard towards a goal is difficult. If , on the other hand , everybody is
open about the work and the scope and goal of the work
becomes clear, it is easier for both Scrum Team members and
stakeholders to commit.
Being open about work and its problems allows those involved to
understand both the challenges ahead and the challenges
already overcome in the past. Being aware of the difficulties that
have been overcome to get to the current point encourages
tackling the next problems courageously .
Focus on the work of the Sprint and common goals requires
openness towards each other what the goals and the work are
and how progress is advancing.
When people can see the work that everybody else does, and
everybody sees how others overcome difficult tasks, it becomes
easier to respect each other.
Openness fosters empirical process control by providing the

basis for transparency. For inspection and adaptation to take
place, transparency must be present . This can only be the case if
5 Scrum Values 50
those involved are open about the situation as it is about the work
and its challenges. An example of a failure of openness is
repeated frustration in Sprint Reviews. The stakeholders may
have a hidden agenda , which leads to needs they are not open
about towards the Scrum Team. Subsequently, the Scrum Team
cannot develop the product to meet these needs.
Also, the Scrum Team may not be open about the problems they
face when doing the work, be it out of fear of offending
stakeholders or due to a false understanding of pride in their
abilities.
In either case, empirical process control is undermined. With
openness present, all involved could address the issues and
collaborate to improve the situation for mutual benefit .
Openness fosters trust , as those involved can observe the
activities of one another. This allows trust in their abilities to grow,
as it is visible to one another that each person actively
contributes to common goals. It also allows trust in each other as
human beings to grow, as openness allows an understanding of
each other's intentions. While one may not agree with another
person s intentions, being aware of them allows for predictability,
which is a cornerstone of trust .
5 Scrum Values 51
Scrum Team members respect each other to be capable,

independent people.
The Merriam- Webster Dictionary defines respect ( as a verb) as

"to consider worthy of high regard”. The Cambridge English
Dictionary defines it as "admiration felt or shown for someone or
something that you believe has good ideas or qualities”. In
Scrum’s context, members of the Scrum team respect each
other, meaning they consider each other worthy of high regard
and acting on the assumption that the others have good qualities
in them, especially related to their work .
Respect relates to the other four values:
Having to solve a problem alone or with others, whom one deems
incapable, is demotivating. When a Scrum Team member
respects their fellow members, however , the problems they have
to address together become more approachable. This enables a
higher level of commitment . Furthermore, believing one's fellow
members to be capable and knowing the feeling to be mutual,
provides an environment in which difficult problems can be more
easily addressed through acts of courage. When working with a
team towards a goal, focussing on that goal becomes easier
when working with people held in high regard for their abilities to
contribute to achieving that goal . In order to show openness, one
needs to regard the others as worthy of openness. People held in
low esteem may not be perceived as worthy of openness, while
respected fellow team members are.
Respect fosters empirical process control in that it is a

fundamentally necessary assumption for process improvements.
When faced with an improvable situation, one can either blame
others, especially particular individuals , which will likely not yield
positive results. If respect is present , on the other hand, the
approach changes to change the process ( through empirical
process control) rather than giving up by blaming people.
Furthermore, teams in which respect is strong will be willing to
experiment more, as an experiment proposed by an individual
member failing will not hold negative personal repercussions in
5 Scrum Values 52
the form of peer pressure. The willingness to conduct more

experiments increases the speed and intensity of empirical
process control and generally leads to better results.
An example of visible results of low respect is unengaged Sprint
Plannings. Members are afraid to contribute their ideas. An
implicit hierarchy was built due to a lack of respect from more
senior members towards the others. Rather than collaboratively
finding the best way to create the Sprint Backlog plan , only a few
Development Team members work in it. This leads to poorer
planning , in turn, lower engagement in adjusting the plan
throughout the Sprint and ultimately to worse results being
produced.
Respect fosters trust in both directions. It is difficult to trust

another person who holds one in low regard and considers one
incapable . Conversely, it is difficult to have trust in somebody
who is believed not to be capable. Awareness of mutual respect
provides the groundwork for trust to grow
6 The Scrum Team 53
6 The Scrum Team
The Scrum Team consists of a Product Owner, the

Development Team, and a Scrum Master.
A Scrum Team is made up of people, falling into one of three

distinct roles:
• One Scrum Master

• One Product Owner
• A member of the Development Team
There are no further roles within a Scrum Team.
Scrum Teams are self -organizing and cross- functional.

Self -organizing teams choose how best to accomplish their
work, rather than being directed by others outside the team.
Cross- functional teams have all competencies needed to
accomplish the work without depending on others not part
of the team.
The Scrum Guide identifies -

self organization and
-
cross functionality as key criteria for a Scrum Team. These two
are tightly interwoven with each other.
-
Self organization can be broken down into two perspectives:
• The external: A team must be empowered to choose the

best way to accomplish their work for themselves. An
environment must exist, where no interferences with the
6 The Scrum Team 54
Scrum Team's decision- making exist, e.g., through

micro- management from a higher hierarchy layer in the
organization.
• The internal: A team must be capable and willing to choose

the best way to accomplish their work for themselves. This
requires a high sense of ownership of the team towards
what they are developing, meaning that the team wants to
pursue the development further in the best way possible ,
which is not necessarily the easiest , most exciting, or most
rewarding.
These two sides are mutually dependent, as a team that wants to
determine its way, but is not allowed to. would not be
self -organizing and neither would a team that is given the
freedom to but does not want to or does not know how to.
Therefore the requirement of self-organization puts significant
,
challenges on those within the team, as well as on the parent

organization.
Cross- functionality requires the team’s competencies, i.e., skills,

abilities, and expertise required to do the work without
dependencies on external third parties. This can be split into two
complementary views:
• Internal: A team must collectively possess the skills

required to accomplish the work on its own. While not
every individual within the team must be capable of
accomplishing every work , across the team, the proper
abilities must exist to make a team function in their value
delivery, hence the term cross- functional.
• Structural: Within an organization , the work must be

structured in a way that a team can potentially be capable
of accomplishing work without depending on external
parties.
In Scrum, "accomplishing the work" always refers to activities

aiming towards delivering value.
6 The Scrum Team 55
The two concepts of self-organization and cross- functionality are

dependent on each other in practice:
• Only a cross- functional team that possesses all the abilities

necessary to accomplish the work can choose adequately,
what the best way of doing so is. If a skill were needed for
the work that the team does not have, it would depend on
outside input and thus not self-organizing.
•A self-organizing team is the one quickest to identify the

needed skills it is lacking . Thus a self -organizing team is
the most reliable basis on which to create a cross-functional
team.
The team model in Scrum is designed to optimize flexibility,

creativity, and productivity. The Scrum Team has proven
itself to be increasingly effective for all the earlier stated
uses, and any complex work.
Scrum is designed to address complex problems' . Thus,

Scrum's attributes , including the team model, need to be
designed to optimize for characteristics that help address
complex problems.
Flexibility, creativity, and productivity are considered crucial for
addressing complex problems.
Complex problems are categorized by the fact that the

relationship between cause and effect cannot be known in
advance . Therefore, the correct approach is to experiment ,
observe , gain insights, draw conclusions, and potentially adapt to
better solutions. This is the empirical approach as the Scrum
Guide understands it, and it is based on the ability to change the
parameters of the experiments.
see explanation of complexity in the Cynefm Framework on pages 7ft .

6 The Scrum Team 56
In a product, such an experiment could be to create a new user

interface for an existing program and test how the market reacts
to it. In a development process, an experiment could be to
expand the time developers spend per Sprint on refining the
Product Backlog with the Product Owner to test how this affects
the speed and quality of the development. In these examples , the
interface and the duration of the refinement respectively are the
parameters changed to inspect the outcome , draw conclusions
and potentially adapt accordingly.
One crucial factor for the effectiveness of empirical process control

is the ability to conduct such controlled experiments quickly, which
in turn depends on the ability to change parameters frequently and
quickly. This is what "flexibility" means in this context. It allows for
a quicker empirical process and, therefore, faster, more efficient
solutions to the complex problem to be solved.
Another crucial factor is to decide on parameters to adjust , which
would be easy if the relationship between cause and effect where
approximately foreseeable, which by definition is not the case in a
complex problem. Thus a skill and a mindset are needed to come
up with new ideas to try. This is what is referred to by "creativity"
in the Guide.
The goal of work in product development in Scrum is to deliver
high- value Increments , Increments can be described as
high- value if much value has been added within a Sprint . As the
key parameters of work during a Sprint - the time, the number of
people , the available resources - are relatively static , i.e. , they do
not change significantly - the only way to generate more value is
to improve the process by which value is generated. The
relationship between inputs into a Sprint and the outcomes of a
Sprint ( for the stakeholders) are what the Scrum Guide
understands by "productivity”.
The team model optimizes for these as follows:
Flexibility, which is understood as the ability to make changes
quickly, requires those making the changes to be able to do so. If
6 The Scrum Team 57
every minor change would need to go through a multi-step

approval process in various levels of hierarchy, or if for every
change a third party would need to be consulted for advice due to
a lack of knowledge , the process would be dependent on parties
outside the team and take longer than necessary.
A self -organizing team possesses the autonomy to make changes

on their own without external approval.
A cross- functional team can make changes on its own without
external dependencies, hence avoiding potentially long feedback
loops with outside parties.
The team model in Swum thus creates an environment of

empowered and capable actors and can hence be seen to foster
flexibility.
Creativity, which in this context is understood as the ability to
develop possible creative solutions, requires a significant
understanding of the problem. While somebody unfamiliar with
the problem may give an input that could be "creative", it is
arguably much more likely to be nonsensical. A team that has the
permission and the ability to conduct its work the way it chooses
to, i.e. , a self-organizing, cross- functional one. is a team that is
more knowledgeable of the work than anybody else. This
significant insight into the work provides a key pillar for
creativity.
Furthermore, as creative solutions are, by definition, not "normal",

developers may require a sense of safety to express potentially
creative ideas. The team model in Scrum is a manifestation of
the Scrum Values, the most important ones for creativity arguably
are:
• Openness: both of sharing new ideas and being open to

new ideas, rather than brushing them off
• Courage : both to express new ideas and to try them out

6 The Scrum Team 58
• Respect: brought towards other team members, in this

case, those voicing new ideas
These values, as well as the trust that results from living all
Scrum Values2 . provide individuals within the Scrum Team with
the environment in which creativity can flourish.
Lastly, a self -organizing team is one to decide on their own how to
do their work, implying that there is no other party to make those
decisions for the team. With regard to creativity, this creates the
necessity for the team to be creative itself , which creates a greater
incentive both to generate new ideas as well as to take action to
further foster creativity. The team model in Scrum thus creates
incentives as well as the proper environment for creativity and can
hence be seen to foster creativity.
Productivity in Scrum can be understood as the relationship

between what resources go into the Sprint and what value is
generated by the process within a Sprint . The team model in
Scrum with its self-organizing and cross- functional teams and
clear roles sets up a team with relatively little overhead. While
there are two non-developing positions on a team, the team s
self -organizing nature removes the necessity for an
administrative layer above the team. The team as a
cross-functional entity is capable of doing its work without
external dependencies, removing the need for outside support .
Thus the total resources required for producing an Increment are
lowered to an almost absolute minimum.
On the other hand, the efficiency of the process is continually
upkept and increased through the application of empirical
process control3 . which benefits from the self- organization and
cross- functionality, as they foster the necessary flexibility and
creativity to drive empirical process control.
The team model in Scrum thus reduces the resource inputs into
the Sprint as well as supporting the continual optimization of the
2
see chapter on Scrum Values on pages 39fl.
3 ,
see the section on empirical process £2£lL2! 0 1 P^Sjes 2411
6 The Scrum Team 59
development process and can hence be seen to foster

productivity.
Scrum Teams deliver products iteratively and Incrementally,

maximizing opportunities for feedback.
in Scrum, the iteration within which value is delivered is the

Sprint. Therefore, every Sprint , i.e., in a consistent time frame no
longer than a calendar month, an Increment is produced.4 The
Incremental approach , i.e., adding value one piece at a time
rather than building an entire product right away, is chosen, as it
allows for feedback to be gathered throughout the development
process. This, in turn, allows adjustments to be made relatively
early in the process when errors can be conected relatively
cheaply.
The first opportunity for a Scrum Team to gather feedback on a

new Increment is the Sprint Review5 . in which the new Increment
is presented to key stakeholders However, incremental
development allows the Increment to be released to the
end- users and valuable feedback to be gathered from them. This
is different from more conventional approaches, which in the
Increment may be considered an "unfinished product”, as it does
not yet contain all features desired.
It is important to note that the term "deliver” in this sentence does

not refer to delivering a product to the end- user, but merely to have
an Increment done for inspection at the Sprint Review. While it
may be beneficial to release Increments to the end-user often, this
does not need to be after every iteration , but according to business
decisions among the Product Owner and key stakeholders.6
The iterative delivery of products , as compared to deliveries that
are non-iterative like, for example, in some Kanban systems,
‘ see section "The Sprint" on oaoes I 12tt

5
see section "Sprint Review" on *2*-l* L*Js 14flff ,
“ see the final sentence of the Increment section on page
6 The Scrum Team 60
means that feedback can be given not only on the product

delivered but also on aspects of the delivery process. The key
iteration in Scrum, the Sprint, is relatively well comparable over
time, as it follows the same pattern and is of the same length
every time7 . This relative standardization allows for the results of
Sprints to be compared with each other, for example, in terms of
stakeholder satisfaction with the results, which can provide
valuable feedback to the Scrum Team.
Incremental deliveries of "Done" product ensure a potentially

useful version of working product is always available.
At the end of a Sprint, the Increment must be "Done”. This does

not mean that the product must be finished and the project is over,
but rather that an Increment could potentially be handed over to
stakeholders or the market and would be usable.
An example of this would be adding a new contact form to an
application in which users can type in their message , which,
however, does not actually send anything, as the messaging
functionality in the backend has not been developed yet . In this
case, adding the un- "Done” feature to the delivered Increment ,
thus creating an un-"Done” product , would lead to a non- useful
version.
An Increment does not necessarily have to be released to the
stakeholders or the end- users every iteration, but it is advisable
to release often to gather feedback Releases are not necessarily
restricted to the cadence of the Sprint. However, having a "Done”
Increment at the end of a Sprint ensures that there is always a
point in time when a product exists that is "Done" and could be
released.
Without this requirement, an Increment could potentially always
7
see explanation on why Sprints have consistent lengths on paoe 113
6 The Scrum Team 61
contain at least one feature not Done ", which would mean that
either
• a release would not be possible at all - which would prevent

feedback and therefore hinder empirical process control.
• priorities would need to be shifted temporarily towards

getting an Increment "Done" for release, rather than
towards further feature development; this would lower
overall value delivery and violate the value of focus .
-
• the un-"Done" features would need to be made inaccessible

either by removing them or by adding a way to hide the un-
"Done " feature • both of them would add unnecessary work
and hence hinder value delivery, the latter may even create
security risks, further lowering value.
To allow for the Product Owner and stakeholders to be able to

release a version potentially, every Increment must adhere to the
standards defined in the definition of Done" (DoD ) . ’
'’ foe an explanation of the value of focus, see page 47

9 -
see chapter on the Definition of ‘Done on pages 202
6 The Scrum Team 62
6.1 The Product Owner
The Product Owner is responsible for maximizing the value

of the product resulting from the work of the Development
Team. How this is done may vary widely across
organizations, Scrum Teams, and individuals.
The Scrum Guide s section covering the Sprint Planning 0 divides

it into two parts: one concerned with what should be developed
in the next Sprint and one with how this development should best
take place. This divide is present throughout the entire
framework and shapes both the Product Owners and the
Development Team's role and the relationship between them.
The Product Owner in Scrum is concerned fully with defining the
direction the product development, i.e., the work of the
Development Team, should take in order to deliver maximum
value. This is to be understood as a broad generalization of their
responsibility, as well as the general attitude of a Product Owner.
The concrete implementation of this depends on a variety of
factors and. as the Guide points out, may vary significantly
across
• organizations, which provide different environments within

which the product development takes place. For example,
a Product Owner of a product that is owned by their
company and released directly to the final user may spend
much time on market and customer research and have only
minimal interactions with other stakeholders. On the other
hand, the Product Owner of a product that is developed for
a B2B customer may be concerned much less with market
and customer research than with gathering and balancing
the interests of different stakeholders from within the
customers company, e.g., different departments. At this
10
see section "Sprint Planning" on pages 123ff
6 The Scrum Team 63
level, it is crucial for a Product Owner to adjust to the

organizational surroundings to maximize their
understanding ot what is needed for the maximization of
value delivery by the Development Team’s work.
• Scrum Teams, which may have different requirements of the

Product Backlog . For example, some Development Teams
may need highly detailed descriptions of their expectation
to fulfill their work properly as the Product Owner would like
it. On the other hand, there may be Scrum Teams in which
the Product Owner entrusts the Development Team with a
much greater creative freedom and only gives a handful of
acceptance criteria. Such a dynamic may shift over time. At
this level, it is crucial for a Product Owner to adjust to the
needs of their Scrum Teams, to ensure they receive what is
needed for maximum possible value delivery.
• individuals, which may have widely different processes and

methods that work best for them . For example, some
Product Owners may find it best to meet with stakeholders,
ask them powerful questions to gather data and over a few
days distill it into their understanding of the needs and
subsequently into updates of the Product Backlog. Others,
however, may meet with their stakeholders to conduct a
day-long Design Thinking session with multiple options for
possible prototypes.
At this level , it is crucial for a Product Owner to use tools

with which they as an individual are best able to do what is
necessary to allow for value maximization of the
Development Team's work.
Scrum as a framework does not prescribe methods, tools or
processes, as each situation is different , and each Product
Owner is empowered to find out for themselves how best to
maximize the value delivered by the work of the Development
Team. The only constraint that the Scrum Guide gives for this is
that the roles, events, artifacts, and the rules binding them
6 The Scrum Team 64
together may not be violated.
The Product Owner is the sole person responsible for

managing the Product Backlog.
The Product Backlog reflects what is known about the product

and its future direction. Its ordering reflects current priorities. The
responsibility for managing the Product Backlog, aspects of which
are outlined in the next sentence of the Guide, lies exclusively with
the Product Owner.
Product Backlog management includes:

Product Backlog management aims towards strengthening the
purpose of the Product Backlog , which is to serve as an Artifact ,
making transparent what is currently known about the product
and the direction its further development will likely take.
• Clearly expressing Product Backlog items;

Product Backlog items must be crafted and refined to be clearly
understood. This serves to create a common understanding of the
purpose and details of an item and hence creates transparency
regarding the expectation.
6 The Scrum Team 65
• Ordering the items in the Product Backlog to best

achieve goals and missions;
The implementation of Product Backlog items aims at delivering

value to realize a larger vision or mission and, in the more
immediate context, concrete goals. The ordering of the Product
Backlog reflects the priorities to do this as they are currently
understood.
• Optimizing the value of the work the Development Team

performs;
Scrum aims at increasing the effectiveness and efficiency of

product development . The efficiency of the development is
increased through improving the development processes via
empirical process control. The effectiveness, i.e. the value of
t
what the work delivers, is optimized by properly managing the

Product Backlog.
The Product Backlog should reflect at any time how the limited
resource of the Development Team s work can be utilized to
deliver the greatest value.
• Ensuring that the Product Backlog is visible ,

transparent and clear to all, and shows what the
Scrum Team will work on next ; and,
Four attributes describe the Product Backlog in this sentence:
• visible, meaning those who have a reasoned interest in

inspecting it must be able to do so easily. A Product
Backlog that is hidden away in a file on the Product
6 The Scrum Team 66
Owner's computer makes it impossible for others to inspect

and provide feedback on the current Product Backlog .
• transparent, in this case going beyond just the aspect of

visibility. It must be possible for those inspecting it to have
the same understanding of the terminology used.
• clear to all, in this case going beyond the requirement of

transparency for a common language, and including
expressing Product Backlog items in a way that they can
be reasonably understood by those responsible for the
outcome of the product development
• showing what the Scrum Team will work on next, meaning

the order must reflect the current priorities and , therefore,
approximately what the next things will be that the Scrum
Team will work on.
Ensuring that these criteria are sufficiently fulfilled is one
responsibility of Product Backlog management.
• Ensuring the Development Team understands items in

the Product Backlog to the level needed.
In order to provide estimates and later implement the Product

Backlog items, the Development Team must understand the
items in the Product Backlog with which it is dealing. Therefore,
Product Backlog management must aim, among other things , to
ensure the Development Team 's understanding of the items.
6 The Scrum Team 67
The Product Owner may do the above work , or have the

Development Team do it. However, the Product Owner
remains accountable.
The accountability for the state of the Product Backlog lies with
the Product Owner. This does, however, not mean that the
Product Owner must be actively involved in every aspect of
Product Backlog management. There may be scenarios in which
delegating some or almost all aspects of Product Backlog
management to the Development Team makes sense and/or is
necessary.
Such delegation is especially necessary in cases of scaled
Scrum approaches, in which multiple Scrum Teams work on one
product. As the Product Owner’s time is limited, two approaches
are thinkable, only one of which is Scrum compliant though:
• Adding a separate (Proxy-)Product Owner for each Scrum

Team. This approach, in which the individual Product
Owners would likely be subordinate to the (Head/Chief )
Product Owner, violates Scrums idea of having a single
Product Owner as the ultimate source of truth regarding
the product and the direction in which the development is
heading. While this approach is common in practice, it is
not in accordance with the Scrum Guide.
• Delegating some aspects of the Product Backlog

management to the Development Teams. This may require
adding product management capabilities to the team to
-
ensure it remains cross functional.
A common approach is to delegate to the Development
Teams to break down large Product Backlog items into
smaller ones and refining those without the Product Owner
as much as possible
While the immediate responsibility for management may be

delegated to the Development Team, the accountability remains
with the Product Owner, which includes the requirement to
6 The Scrum Team 68
ensure those doing the management work are capable and

inspecting the work they do reasonably frequently.
The Product Owner is one person, not a committee. The

Product Owner may represent the desires of a committee in
the Product Backlog, but those wanting to change a Product
Backlog item's priority must address the Product Owner.
Scrum creates the Product Owner as the single source of truth

regarding the Product Backlog. When developers or stakeholders
wish to gain information, speaking to different Product Owners
may yield them different results, which would lead to
miscommunication. One product is owned by one Product
Owner, where ownership does not refer to the possession, but to
the Scrum understanding of ownership, i.e., to initiative,
responsibility, and being in the care of somebody.
This rule remains in place even when multiple Scrum Teams work
on the same product. In this case, the Development Team may
need to play a more active role in Product Backlog refinement
to support the Product Owner. The previous sentence explicitly
allows for this.
The Product Owner may consider inputs from stakeholders and

possibly even an internal advisory committee when sorting the
Product Backlog, however, the decision of what constitutes the
maximum possible value delivery by the Development Team’s
work and therefore the order of the Product Backlog remains one
that only the Product Owner is allowed to decide over.
6 The Scrum Team 69
For the Product Owner to succeed, the entire organization

must respect his or her decisions. The Product Owner ’s
decisions are visible in the content and ordering of the
Product Backlog. No one can force the Development Team
to work from a different set of requirements.
The role of the Product Owner was crafted based on the idea that
one person, who knows most about the current state of the
product and how to deliver value from it, would make the
decisions regarding the direction of further product
development.
The Scrum Team as a whole and the Development Team within it
- *
are described as self organizing. Similarly, the Product Owner is
self -organizing, in that they are given autonomy to do their work as
they believe best. To ensure this autonomy, the entire organization
must respect the decisions of the Product Owner. However, this
does not mean others are not free to provide inputs to the Product
Owner aiming at changing their decision .
The Product Owner's decisions are reflected in the Artifact of the
Product Backlog. Its purpose is to
• create transparency regarding what is currently understood

about further product development and
• what - according to the Product Owner - will deliver the

greatest value for the work of the Development Team.
To allow the Product Owner to maximize the value of the

Development Team s work, they must have full control over the
source of what the Development Team works on. Others forcing
the Development Team to work on other things will undermine
the value maximization by the Product Owner and thus impede
their success.
11
for an explanation on the terms self -organization, see the definition on pages
53ff
6 The Scrum Team 70
6.2 The Development Team
The Development Team consists of professionals who do

the work of delivering a potentially releasable Increment of
"Done " product at the end of each Sprint. A "Done”
Increment is required at the Sprint Review.
In these two sentences, the Scrum Guide characterizes the

Development Team in the following ways:
• It is made up of professionals. The term "professional" is not

explicitly defined in this context, but likely meant to refer to
an individual who is capable of doing the development work ,
such as preparations, organization and communication.
• Its members' primary job within the Scrum framework is to

develop an Increment. The other tasks that may occur,
such as assisting the Product Owner in Product Backlog
refinement, are secondary to this.
Further, the Scrum Guide characterizes the Increment as having
to be "Done", meaning being in accordance with the definition of
"Done" 1 " . as well as potentially releasable at the Sprint Review ' 3
. This means that:
• It must be possible to release an Increment at least at the

end of each Sprint. Reaching potentially releasable
Increments more frequently is acceptable and even
potentially beneficial if the Increments provide value and
feedback can be gathered . However, the minimum required
by the Scrum Guide is a potentially releasable Increment at
the Sprint Review. This ensures two things:
12
see chapter on the Definition ot Done' on pages 202
"
,3 see section "Sprint Review" on paoes 148tl.
6 The Scrum Team 71
- There is an Increment to inspect during the Sprint

Review to gather feedback on.
- A recent, potentially useful version of a working
product is always available.
• The Increment resulting from the Sprint does not

automatically have to be released , but instead, the decision
to release a product into the market or to stakeholders is a
decision of the Product Owner, considering a variety of
factors.
Only members of the Development Team create the

Increment.
This can be seen as excluding three categories of people, who

may otherwise potentially be involved in the process of creating
the Increment:
• People who are on the Scrum Team, but not the

Development Team , i.e. , the Product Owner and the Scrum
Master
• Developers who are not part of the Scrum Team

• Other people who are neither on the Scrum Team
, , nor
other developers, e g., parent organization 's management ,
stakeholders.
The exclusion of other developers can be understood as being for

the following reasons:
• It creates a hard metric for cross-functionality

. A team that
is not allowed to delegate tasks away will inevitably notice

whether or not it is capable of delivering Increments
without external help. In this sense, the exclusion creates
the necessary transparency for empirical process control
aimed towards cross- functionality.
6 The Scrum Team 72
• Delegating tasks necessary for the Increment to outside

developers creates an external dependency, which creates
risks outside the Scrum Team s scope.
• The development process is subject to empirical process

control. A developer from outside the Development Team
and hence outside the Scrum Team , would introduce new
parameters into this process that would be very hard to
control for and make empirical process control less
effective. The goal is to continually optimize the
Development Team s process, which is easiest if general
parameters remain as consistent as possible.
The exclusion of the Product Owner, Scrum Master and other non-
developer entities can be understood as being for the following
reasons:
• During the Sprint Planning, the Development Team commits

to the Sprint Goal. This commitment requires a high degree
of control over the outcome, namely the ability to decide on
how to do its work of delivering the Increment. That ability
is what the Scrum Guide refers to as self -organization". ' *
"
• It creates a hard metric for self-organization. A team that is

not able to deliver an Increment without intervention from
non-Development- Team entities is easily identified as not
properly self-organizing . In this sense , the exclusion
creates the necessary transparency for empirical process
control aimed towards self -organization .
• The Scrum Guide assumes the members of the

Development Team to be professionals. In its definition of
empiricism, it outlines that decisions should be taken
based on what is known. Therefore, the decisions on how
to turn a Sprint Backlog into an Increment should be taken
14
foe an explanation on the terms self - organization, see the definition on pages
53 ff
6 The Scrum Team 73
only by the Development Team (collectively), as it is the

entity with the best understanding of how to do that.
Development Teams are structured and empowered by the

organization to organize and manage their own work. The
resulting synergy optimizes the Development Team 's overall
efficiency and effectiveness.
The first of these sentences outlines the key requirements for

- -
cross functionality and self organization.
For a team to be cross-functional, it needs to be able to organize,
manage and conduct their work without external dependencies.
This requires the team to be structured with that particular need
in mind. What this means concretely can vary widely from case
to case. Under the idea of self -organization, determining what
structure would be appropriate is up to the team itself.
For a team to be self -organizing, it needs to have positive and

negative freedoms given to them by their organization. Negative
freedoms, i.e., freedom from something, in this case, means
being free from intervention from the outside, for example, from
micro-management from the organization’s governance or a
Product Owner or Scrum Master ordering the Development Team
around and telling them how to do their work.
Positive freedom, i.e., being given the ability to do something, in
this case, means having a structure in place that fosters
self -organization. Examples of this could be the availability of a
sufficient budget to freely decide on development tools or the
organization providing workspaces that allow easy
communication between the team members .
The Scrum Guide claims in the second sentence that with these
conditions fulfilled, teams can work together highly effectively,
generate synergy and thereby lead to an optimization of how well
time and resources are used (what is called "efficiency") and of
the value it ultimately delivers ( what is called "effectiveness").
6 The Scrum Team 74
Development Teams have the following characteristics:
• They are self-organizing. No one (not even the Scrum

Master) tells the Development Team how to turn
Product Backlog into Increments of potentially
releasable functionality ;
-
Just as the Scrum Team is a self organizing unit, the
Development Team within a Scrum Team is self organizing with-
regard to how they conduct their development work. As the
introduction of a Scrum Master, in the role of a servant leader ^ . -
is arguably one of the more drastic changes when comparing
Scrum with more conventional approaches of product
development and management. To clarify the hierarchical
relationship, or rather lack thereof, between the Development
Team and their Scrum Master, the Guide emphasizes explicitly,
that the principle of self -organization protects them from orders
from anybody, explicitly including the Scrum Master.
• Development Teams are cross- functional, with all the

skills as a team necessary to create a product
Increment ;
Just as the Scrum Team as a whole has to be cross functional - 6

.
the Development Team within it has to be as well.
15
see the definition of a servant leader on pages 84f
16
for an explanation on the terms cross- functionaiitv. see the definition on
pages 53ff
6 The Scrum Team 75
• Scrum recognizes no titles for Development Team

members, regardless of the work being performed by
the person
• Scrum recognizes no sub- teams in the Development

Team, regardless of domains that need to be
addressed like testing, architecture, operations, or
business analysis; and,
• Individual Development Team members may have

specialized skills and areas of focus, but
accountability belongs to the Development Team as a
whole.
These three points together outline key assumptions of the
Scrum Guide on how the work within a Development Team is
best organized .
The last point outlines the understanding of accountability within
a Development Team, which the team shares as a whole, not
held by any individual. Not every member has to be equally
capable of everything that is required for a particular piece of
work, as that is neither realistically possible nor desirable.
Nonetheless, the accountability for all of the tasks of the

Development Team belongs to all of the members collectively, not
to any individual or group within the Scrum Team Neither the
.
specialization of a Development Team member’s skills nor even

their focus area leads to accountability to rest only in that person.
Scrum understands the process of development to be owned
collectively by the Development Team , which is therefore
collectively accountable for the process and the results.
A result of this collective accountability is that members of the

Development Team are obligated to create transparency on their
current work towards each other. Furthermore, they need to
6 The Scrum Team 76
assist each other in their tasks as necessary. The Scrum Guide

underlines this need for transparency with the event of the Daily
Scrum and the need for mutual assistance with the following
sentence: "Every day, the Development Team should understand
how it intends to work together as a self-organizing team to
accomplish the Sprint Goal and create the anticipated Increment
by the end of the Sprint."' 7
If members of the Development Team were to hold different titles ,

that would work against the idea of collective accountability. If a
Development Team has a member with the title "tester", problems
related to insufficient testing would be understood as a failure of
that person. Instead. Scrum suggests this to be seen as a
process issue that needs to be inspected and for which solutions
need to be developed. This same concept applies not only to
individual titles but also to sub-teams. A failure of testing might
otherwise be attributed to shortcomings of the testing- team ,
instead of a need for a process improvement .
,rsee the corresponding quote on oaoe 139

6 The Scrum Team 77
6.2.1 Development Team Size
Optimal Development Team size is small enough to remain

nimble and large enough to complete significant work within
a Sprint.
The ultimate goal of a Scrum Team and, therefore, of a
Development Team is delivering value. Thus the lower limit of the
team size is determined by how many developers are needed to
deliver value that is significant. The definition of "significant" is
subjective; however, the evaluation of it must take into
consideration the overhead that the Scrum framework. The
specialization into the roles of Product Owner and Scrum Master
as well as the time cost associated with the Scrum events, need
to be justified by the value delivered.
As a framework, Scrum does not prescribe a definitive answer but

instead gives a lower and an upper limit, combined with arguments
that serve both as justifications for the limits. These arguments
further serve as criteria for a Scrum Team to evaluate its own ideal
size.
Fewer than three Development Team members decrease

interaction and results in smaller productivity gains.
Scrums benefit lies in maximizing value by fostering, among

other things, communication and synchronization. When only two
developers work in the development, this factor loses its potency,
and the lack of productivity gain does not justify the overhead of
Scrum.
6 The Scrum Team 78
Smaller Development Teams may encounter skill constraints

during the Sprint, causing the Development Team to be
unable to deliver a potentially releasable Increment.
-
A Development Team is defined as being cross functional 13 and
delivering an Increment. ' If a Development Team is small, the
-
necessary skills may be absent all together or not available
sufficiently to deliver an Increment.
-
Example: A three person Development Team works on a piece of
software, which requires expertise in frontend development,
backend development and databases. Each developer is an
expert in one of these categories, making the team
-
cross functional. To deliver an Increment, however, more
capacity in the frontend development is required. This may be
solved by adding another developer who is savvy in frontend
development, bringing the total number of developers to four.
This sentence is not intended to argue that smaller teams will

inevitably encounter this issue; instead, it outlines that:
• when evaluating the proper team size, the possibility of the

team being too small relative to the required skills should be
considered, and on the other hand that
• when a team runs into problems with not being able to

deliver Increments due to skill constraints, the reason may
lie, among other things, in the team size being too small.
18
foe an explanation on the terms cross - functionality see the definition on
,
pages 53ff.
19
see definition of a Development Team on page 70
6 The Scrum Team 79
Having more than nine members requires too much

coordination.
A number of nine developers is given as the absolute upper limit.

This limit is not determined by any calculations, but rather has
established itself from practical experience using empirical
process control.
Large Development Teams generate too much complexity for

an empirical process to be useful.
The method that Scrum uses for continuous improvement is

empirical process control - transparency, inspection and
adaptation20 . In practice, the empirical approach is to alter
individual parameters of a process and inspect the results. This
is especially useful when the other parameters that are not
altered and remain relatively constant , allowing for comparison
and. therefore, inspection. Larger Development Teams consist of
many people and conduct many activities. With this, a large
number of factors are introduced into the system of the team.
Applying empirical process control would mean either to change
only a small set of the many parameters or to change a larger
number of the many parameters.
Changing only a small set of parameters at the same time and
keeping most other parameters constant allows for the generated
results to be more meaningful. This approach however, comes at
the cost of relatively few changes every iteration and, therefore,
only relatively slow improvements. The benefit that Scrum is
supposed to bring is quick adaptability and rapid self-organizing
improvements. Changing only a small set of parameters is,
therefore, in its result contrary to the idea of a Scrum Team .
Therefore, the consequence would be a loss of flexibility, for
which Scrum aims to maximize.
“see the section on empirical process control on pages 24H

6 The Scrum Team 80
Changing a larger set of parameters at the same time makes it

challenging to infer which change may have been beneficial and
which may even be counter-productive. The results of such a
process are much less meaningful and undermine the
effectiveness of empirical process control.
This sentence is not intended to argue that these problems can
only occur when a team has more than nine developers, nor that
any team of nine developers will inevitably face these problems.
Instead, it gives a guideline to consider:
• when evaluating the proper team size, the possibility of the

team being too large relative to the complexity of the
development process should be considered, and on the
other hand that
• when the process of developing a product becomes too

complex for empiricism to be practical, the reason may lie ,
among other things, in the team size being too large.
The Product Owner and Scrum Master roles are not included
in this count unless they are also executing the work of the
Sprint Backlog.
The Development Team does not include the Product Owner or

the Scrum Master unless they are working on the Sprint Backlog .
This sentence indirectly clarifies that the Scrum Guide allows for
two combinations of a Scrum Team member fulfilling two roles:
Product Owner and Development Team member on the one
hand , and Scrum Master and Development Team member on the
other.
The Scrum Guide does not give explicit guidance of whether either
of these combinations is useful and leaves that determination up
to the individual teams using Scrum.
6 The Scrum Team 81
6.3 The Scrum Master
The Scrum Master is responsible for promoting and

supporting Scrum as defined in the Scrum Guide.
All of the responsibilities of the Scrum Master within an

organization fall under one of two categories described in this
sentence, which need to be continually done in parallel to each
other:
• They are supposed to promote Scrum. This means they

are responsible for strengthening the understanding of the
ideas behind the framework , as well as spreading the ideas
of Scrum beyond the scope of their own Scrum Team. This
summarizes work such as educating and coaching team
members, the organization and stakeholders and working
with management to spread Scrum.
• They are supposed to support Scrum. This means they are

responsible for maintaining Scrum within their teams and
organizations by fulfilling such tasks as facilitating events
and removing impediments.
Scrum in this context is again to be understood as what is defined
in the Scrum Guide. The responsibility of the Scrum Master is,
therefore, to conduct their activities in accordance with the Scrum
Guide as well as promote and support the ideas in the Scrum
Guide as the "true Scrum".
In this sentence, the Scrum Guide does not explicitly limit the
scope of these responsibilities to the organization. This can be
understood as an obligation of Scrum Masters to spread the
ideas of Scrum even beyond the scope of their respective
organizations. A practical example of this could be helping
people new to Scrum gain greater insight by attending and
actively participating in local Scrum working groups.
6 The Scrum Team 82
Furthermore, this lack of limitation and the insistence on

understanding Scrum as what is defined in the Scrum Guide can
be understood as implying another meaning behind this
sentence. The strict and repeated insistence of the Scrum Guide
to be the definittve source of Scrum is partly due to these two
reasons:
•A large set of sometimes contradicting practices is

informally referred to as being a part of Scrum. For
example , the use of the user story format for Product
Backlog items is common practice in many Scrum Teams
and is a valid approach within the Scrum framework but is,
strictly speaking not part of Scrum.
,
• In practice. Scrum adoption often ends at a certain point .

Some organizations may choose to adopt the events, but
not the terminology. Others may choose to work iteratively
and Incrementally, but still have a team managed by a
project manager.
In light of these, the sentence in the Scrum Guide can be

interpreted as placing on Scrum Masters the responsibility to
hold each other accountable to understanding Scrum only as it is
defined in the Scrum Guide. The intent may be to create a social
pressure within the Scrum Master community, to inspect each
other and support each other in understanding Scrum as what is
defined by the Guide.
Scrum Masters do this by helping everyone understand

Scrum theory, practices, rules, and values.
The creators of Scrum believe that the Scrum Guide outlines a
logical, consistent response to the issue of addressing complex
problems in product development . Therefore , a Scrum Master
does not need to be equipped with hierarchical authority to force
Scrum onto teams and organizations. Instead, spreading and
supporting Scrum can be done by helping others understand:
6 The Scrum Team 83
• Scrum theory, namely the empirical process control of

transparency, inspection and adaptation
• Practices, such as the events and artifacts of Scrum

• Rules, which bind the framework together and define the
relationship between events , artifacts and roles
• Values, which together with empiricism set the foundation

for Scrum, by providing guiding principles for those things ,
tor which the Scrum framework does not prescribe specific
methods or tools
The implicit idea behind this sentence is that once somebody

understands the ideas of Scrum, they will be willing to try it at
least . Therefore , no hierarchical authority is required.
The use of the word "everyone" does explicitly not limit the scope
of whom Scrum Masters are supposed to help understand
Scrum. This can be understood as meaning, that a Scrum
Master is not only responsible for helping those within their teams
or organizations, but everyone who is willing to listen.
The creators of Scrum , Jeff Sutherland and Ken Schwaber.
describe Scrum as a better approach to product development .
They state that this is not only because Scrum helps deliver value
more efficiently, but also because it creates better conditions for
those working within the Scrum framework. [81
Therefore, this sentence can be seen as a call to spread Scrum
also outside of one's own immediate surroundings, to create a
better working culture not only in one s own organization but also
on a larger, societal scale.
6 The Scrum Team 84
The Scrum Master is a servant-leader for the Scrum Team.
The idea ot a servant-leader goes back to Robert K. Greenleaf , a

long-term manager at the American telecommunications
company AT& T, who outlined the idea in a 1970 essay titled 'The
Servant as Leader”, followed by a book on the matter, describing
it as follows:
"The servant-leader is servant first. It begins with the natural
feeling that one wants to serve. Then conscious choice brings
one to aspire to lead . The best test is: do those served grow as
persons : do they, while being served , become healthier , wiser,
freer, more autonomous , more likely themselves to become
servants ? And. what is the effect on the least privileged in
society: will they benefit , or, at least , not be further
deprived ?' \ 91
The Scrum Guide defines that a Scrum Master must act as a

servant-leader for their team. They are not the master of their
team , i.e„ they do not hold any hierarchical authority over them,
but rather of the ideas and values of Scrum and of transmitting
those.
As a servant-leader the Scrum Master takes care of the needs of
,
others in order to allow them to grow. They are someone who

defines their own success through the success of others they
helped enable The Scrum Master drives the team towards better
processes and interactions and, consequentially, a higher value
delivery, making them a leader on the team .
The manner in which this is done, however , is not through

hierarchical authority, but by assisting the team from a servant
position. This is manifested by the kind of tasks in the Scrum
Master’s responsibilities, such as impediment removal for the
team, facilitating the meetings of the team and educating the
team as well as its surroundings to allow the team to improve
their own interactions and processes.
6 The Scrum Team 85
The approach of a Scrum Master under the servant-leadership

paradigm is one that aims to strengthen the self -organization of
the team, guiding it towards the ability to solve as many problems
of their own as possible. In this spirit , the position of the Scrum
Master was created without any formal authority over anything, as
opposed to the Product Owner, who owns the Product Backlog
and the Development Team who own their Sprint Backlog. The
Scrum Master leads by enabling others through their services.
The Scrum Master helps those outside the Scrum Team

understand which of their interactions with the Scrum Team
are helpful and which aren't. The Scrum Master helps
everyone change these interactions to maximize the value
created by the Scrum Team.
A Scrum Team usually exists within the scope of a larger

organization, leading to interactions between the Scrum Team
and other parties. Scrum outlines general guidelines for the
interactions of Scrum Teams and other parties, such as a need to
respect the self -organization of a Development Team or the
decisions of a Product Owner. Interactions going against these
outlines would impede value delivery in the long term and thus
would not be helpful.
On the other hand , Scrum relies heavily on feedback from
stakeholders, which they may be hesitant to give as they may be
uncomfortable, especially if they are not familiar with Scrum or
other agile approaches to product development These
,
interactions however would be very helpful

, , .
It is the Scrum Master 's obligation to maximize the efficiency of

the work of the team by improving helpful interactions and
preventing unhelpful ones as much as possible. The approach
they are supposed to take here is in line with the idea of a
servant-leader2 1 , as the Scrum Master does not force these
21
see the definition of a servant -leader on pages 841.
6 The Scrum Team 86
changes, which in the case of preventing behavior might be

possible through sufficient hierarchical authority.
Instead, they support the outside parties' understanding of the

impacts of their interactions:
• of the negative consequences of unhelpful behaviors, which

sometimes only occur in the long run and thus need to be
placed in a context by the Scrum Master , as well as
• of the positive possitxlities of helpful interactions on the

long- term value delivery
6 The Scrum Team 87
6.3.1 Scrum Master Service to the Product

Owner
The Scrum Master serves the Product Owner in several ways ,

including:
-
The Scrum Master is the servant leader for their Scrum Team
and. as such, provides support for those on the team, namely the
Product Owner and the (members of the) Development Team. In
-
the following, the Scrum Guide provides a non exhaustive list of
how the Scrum Master can be of service to the Product Owner.
For all items on this list, the Guide does not specify concrete
implementation methods, but as a framework merely defines the
basic requirements.
• Ensuring that goals, scope, and product domain are

understood by everyone on the Scrum Team as well as
possible;
-
Scrum is predicated on the idea of a self organizing team.1" In
order for the Scrum Team to make the best possible decisions, all
members need to understand the ideas behind what is being buitt,
including the goals, scope and general product domain.
This is primarily a service to the Product Owner, as it improves

their work of maximizing the value of the Development Team s
work . A team with a proper understanding of the product and its
development is better able to contribute to the decision making.
Example: a Development Team that understands the (business)

goal of the upcoming Sprint will be able to offer more suiting
22 foean explanation on the terms self -organization, see the definition on pages
53 ff .
6 The Scrum Team 88
solution proposals and more accurate estimates, allowing the

Product Owner to maximize the value of the Development Team s
available capacity.
• Finding techniques for effective Product Backlog

management;
A core responsibility of the Product Owner role is the

management of the Product Backlog.23 The Scrum Guide does
not prescribe specific methods or techniques to be used for
Product Backlog management. There are, however, qualitative
differences between different approaches, measured by their
effectiveness at creating transparency about the current plan for
the future of the product.
The Scrum Master is tasked with supporting the Product Owner
in their role by finding techniques for effective Product Backlog
management and explaining the benefits of them. This allows the
Product Owner to manage their Product Backlog better and,
therefore, more effectively maximize the value of the work of the
Development Team.
Example: Maintaining a list of Product Backlog items in a shared
text document may suffice to give the stakeholders and
Development Team a rough idea of the current priorities. While in
the early phases of product development , this may be enough .
As the product matures and the Product Backlog becomes larger,
the text document may not be able to create enough
transparency, e g. , about the relationship between individual
items. It is the Scrum Master's responsibility to explain this
emerging need to the Product Owner and work with them to
introduce a new technique for Product Backlog management ,
e .g,, a system in which items are categorized by how far they
23
see the section on Product Backlog management on page M
6 The Scrum Team 89
have been broken down in refinement, in which dependencies

between items are easily visible and in which a proper search
and filter functionality exists.
• Helping the Scrum Team understand the need for clear

and concise Product Backlog items;
The quality of Product Backlog items has effects on the

Development Team's ability to provide estimates and implement
the items as part of their Sprint Backlog.
Items that are clearly expressed allow the Development Team

team to understand the requirements they represent and make
development decisions accordingly.
Product Backlog items should be understandable by the
Development Team as much as possible, ideally to the degree
where the Development Team can implement them without
frequently consulting the Product Owner. On the other hand,
Product Backlog items should be concise, i.e., limited to
transmitting the requirements they represent, without giving a
prescription on how the item is to be implemented. A balance
must be found between too little detail and too much.
Scenarios exist in which either the Product Owner, the

Development Team or both want for Product Backlog items to be
much more or much less detailed than is most beneficial. The
Scrum Master 's responsibility in all of them is to teach both
parties about the purpose of Product Backlog items and the
subsequent need for a proper balance. This allows the Product
Owner to provide the Development Team with enough detail to
allow them to develop the product properly while limiting the time
the Product Owner needs to spend on writing Product Backlog
items.
Example; A Development Team expects a high degree of detail in
the Product Backlog items. The Product Owner complies and is
6 The Scrum Team 90
not only writing requirements but goes as far as to include

pseudo-code, which the Development Team takes and turns into
proper syntax . This creates a heavy workload on the Product
Owner, while at the same time limiting the self-organization of the
Development Team. The job of a Scrum Master in such a
scenario would be to make both the Development Team and the
Product Owner understand what the purpose of a Product
Backlog item is and. subsequently, why it should be concise. The
Scrum Team would then transition to more concise items , freeing
the Product Owner to spend their time working with stakeholders
to understand their needs better .
• Understanding product planning in an empirical

environment;
The supposed benefit of conventional product planning is

predictability. A plan is crafted with a clear timeline when things
will be ready. Stakeholders still used to this way of thinking will
expect clear timelines from the Product Owner, who themselves
may be inclined to desire a high degree of predictability.
The responsibility of the Scrum Master in this regard is to support

the Product Owner 's understanding of how product planning
works within Scrum. The basis for Scrum is empirical process
control, which applies to individual components within the
product development as well as the overall product development
itself. As new things are learned about the product and its
development , plans may need to change . Therefore, extensive
predictions about steps far in the future cannot be made with any
certainty. Instead , the development is oriented towards
maximizing value based on what is currently understood.
The Scrum Master supports this understanding in the Product

Owner and, if necessary, in the (key ) stakeholders. When both
the Product Owner and the (key) stakeholders understand the
6 The Scrum Team 91
approach to planning in empirical environments, transparency is

created, since both parties have the same understanding .
Example: The Product Owner of a product has a high
understanding of how planning in empirical environments works.
However, the key stakeholders of the product do not. When the
Product Owner forecasts future releases during a Sprint Review,
the Product Owner understands this as a forecast, which may
change as things evolve. The stakeholders, however, understand
this as a certainty. When things eventually do change, and the
Product Owner subsequently changes the release plans, the
stakeholders are upset about this. Here the Scrum Master needs
to work with the stakeholders, help them understand why exact
plans are not possible and/or not beneficial and that forecasts
contain no certainty. The Product Owner and the stakeholders
now have the same understanding of what a "plan" is. This
transparency of the terminology allows for improving the working
relationship and therefore improves the capabilities of the
Product Owner to maximize the value of the work of the
Development Team.
• Ensuring the Product Owner knows how to arrange the

Product Backlog to maximize value;
The goal of a Product Owner is to maximize the value of the

product. For this, they need an understanding of what constitutes
value and how that value is best achieved. The responsibility of
the Scrum Master is to ensure that the Product Owner has a
definition of value and an understanding of how to use the
Product Backlog to reflect the next steps in order to realize that
value.
Example: A product has two different types of users, one group

uses the product very rarely and does not generate a lot of
income, while the other group uses the product extensively and
hence generate a lot of income and profit per customer. The
6 The Scrum Team 92
Product Owner of this product uses the metric of profit to

determine value. The Scrum Master needs to ensure that the
Product Owner knows how to arrange the Product Backlog to
maximize this value. This knowledge would likely manifest in a
high priority given to items that serve the high-use group over
those serving the low-use group. Furthermore, an indicator could
be that the Product Owner uses different tags for items that serve
the two groups, allowing them to more easily visualize the items
generating high value.
• Understanding and practicing agility; and,

Sutherland and Schwaber, the co-creators of Scrum, are original
signatories to the Agile Manifesto (source footnote ). The ideas
laid out in its values and principles are reflected in various
aspects of Scrum. For example , the fourth comparison in the
Agile Manifesto reads ~[ Responding to change over following a
plan", which manifests itself in Scrum's use of a Product Backlog
as a living artifact and in the continuous adjustment of the Sprint
Backlog during the Daily Scrums.
An understanding of agility is beneficial for the Development Team

and the organization to have. However, the Guide outlines it as a
service by the Scrum Master only for the Product Owner. This is
due to the fact that most aspects of agility - as it is understood in
the Agile Manifesto - deal with the interaction between the (key )
stakeholders on one side and those responsible for the product
development , represented mainly by the Product Owner, on the
other.
The Scrum Master 's responsibility is to support the Product
Owner's understanding of agility, referring especially to the
mindset and subsequent practices regarding collaboration with
stakeholders, flexibility towards requirement changes and
frequent releases to gather feedback .
6 The Scrum Team 93
Example: A Product Owner , who previously held the title of

project manager and remained in the mindset of conventional
product management , gathers inputs for the next release of their
product . Once all the requirements appear to be gathered, the
Product Owner sets up a plan for the next 6 Sprints of what the
Development Team will work on.
After two Sprints, a key stakeholder provides an urgent input , that
would lead to a change in the Product Backlog and subsequently
in the Product Owner's planned timeline. The Product Owner
plans to reject the input and inform the stakeholder that the
changes would be included in the next release, as was agreed in
the original contract .
The Scrum Master must work to help the Product Owner
understand agility and support their practice of it. In this case,
that means explaining to the Product Owner that changes late in
the production process should be welcomed (principle 2), that
they should work with the customer to integrate the new
requirements rather than insist on what the contract says ( value
3) and perhaps even encouraging the Product Owner to increase
release frequency from every six Sprint to a faster pace (principle
D-
• Facilitating Scrum events as requested or needed.

This is a service the Scrum Master may provide for both the
Product Owner and the Development Team. The Product Owner
is actively involved in three of the four Scrum Events within a
Sprint:
• During the Sprint Planning, the Product Owner presents

their (business ) objective for the upcoming Sprint ,
collaborates to craft a Sprint Goal and provides inputs for
the Development Team to make decisions when creating
an initial plan for the Sprint Backlog.
6 The Scrum Team 94
• During the Sprint Review, the Product Owner presents an

overview of what was achieved throughout the Sprint ,
presents the planned next steps for the product
development and collaborates with the Development Team
and present stakeholders on what the likely next steps will
be.
• During the Sprint Retrospective, the Product Owner

participates as a member of the Scrum Team, aiming to
improve the overall process.
The Scrum Master may support these events through facilitation

if they are requested to do so by a member of the Scrum Team .
Furthermore, the use of "or needed " implies that the Scrum
Master may choose to proactively take the facilitator role if they
deem it necessary.
The facilitation is a service to the Product Owner because it
allows the Product Owner to more effectively live out their role if
the Scrum events function more properly due to the Scrum
Master 's facilitation than without it.
Example: The Product Owner usually facilitates the Sprint
Review. Recently, the Scrum Master started noticing personal
conflicts between the Product Owner and a key stakeholder. This
conflict eventually leads to the Product Owner actively ignoring
the stakeholder during the Sprint Reviews, undercutting their
possibility to contribute their feedback .
Upon providing the Product Owner with feedback on that
observation , the Product Owner may request that the Scrum
Master facilitates the Sprint Review for the next few times, while
the Product Owner works out their differences with the
stakeholder.
The neutral facilitation by the Scrum Master allows the previously
stifled stakeholder to provide their inputs , allowing the Product
Owner to take them into consideration, let the Product Backlog
more accurately reflect the current priorities and subsequently
deliver a higher- value product.
6 The Scrum Team 95
6.3.2 Scrum Master Service to the Development

Team
The Scrum Master serves the Development Team in several

ways, including:
The Scrum Master is the servant-leader for their Scrum Team
and. as such, provides support for those on the team , namely the
Product Owner and the ( members of the) Development Team. In
the following , the Scrum Guide provides a non-exhaustive list of
how the Scrum Master can be of service to the Development
Team .
For all items on this list, the Guide does not specify concrete
implementation methods, but as a framework merely defines the
basic requirements.
• Coaching the Development Team in self-organization

and cross- functionality;
Scrum Teams as a whole need to be self-organizing and

cross- functional.^' On the level of the Scrum Team, this means
that the team must have a Product Owner capable of product
management , a Scrum Master capable of fulfilling their
obligations to the team and organization and a Development
Team that is capable of doing the work of developing the product.
In order to do this efficiently, the Development Team needs to be
self -organizing and cross- functional.
The Scrum Master's responsibility is to coach the Development
Team in these aspects The concrete methods are not
,
prescribed; however the use of the term "coaching" indicates that

,
24
see section 6 on page §2
6 The Scrum Team 96
the Scrum Master is supposed to take a guiding approach and

provide feedback . The idea is to enable the team and help them
help themselves.
Example: A Development Team working on a product repeatedly
fails to reach their Sprint Goal due to external dependencies.
Upon inspection, it is realized that the external dependency is not
unavoidable, but due to a lack of a particular skill within the team.
The Scrum Master now needs to work with the Development
Team to help them understand the need for cross-functionality to
reliably deliver high- value product Increments.
The Scrum Master must then support the team in finding an
appropriate solution, which could be that the team decides on
one of its members to spend one day per week acquiring the skill
that the team is lacking. This allows the team to gradually
transition (back ) into a state of cross- functionality.
• Helping the Development Team to create high- value

products;
The Development Team is responsible for delivering Increments

of the product. The value of the Increment is determined by
which additional features and capabilities it possesses, as well as
the quality of these. The choice of features is determined by the
Product Owner, while the quality is largely up to the Development
Team .
The Scrum Master 's responsibility towards the Development Team
is to support them in delivering high- value products, which may be
done in a variety of ways among others:
,
• Ensuring the Development Team understands the items

selected for a Sprint , including the motivation for choosing
them. Understanding of the business side of the
requirements guides the Development Team in their
decisions during implementation.
6 The Scrum Team 97
• Ensuring the Development Team understands the concept

of a Definition of "Done" and the need to tighten it over
time. This increases the quality of the product delivered
and. therefore, its value.
• Supporting the Development Team in automating redundant

tasks to free more time for product development.
Example: A Development Team has repeatedly been delivering
Increments that initially satisfy the stakeholders: however, after a
while, each time technical errors are revealed. The stakeholders
become dissatisfied with the overall state of the product . In their
eyes, the value of the product has dropped due to quality
concerns.
The Scrum Master is then responsible for working with the
Development Team to help them understand quality as a key
metric for value and work with them to tighten their definition of
"Done". One key aspect of this is testing , which has been
conducted insufficiently, as no member of the Development Team
has been willing to do repeated manual testing. The Scrum
Master works with the team to develop a concept for automated
testing, which increases the quality of the delivered Increment
while limiting the amount of time spent on testing by the
Development Team , allowing them to deliver more features and
capabilities instead and therefore more valuable Increments.
• Removing impediments to the Development Team ’s

progress:
Impediments are anything that stands in the way of the

Development Team delivering value. This includes , but is not
limited to:
• improper working conditions, such as a non- working

airconditioning system
6 The Scrum Team 98
• external requests, potentially taking away capacity from the

Development Team
• technical problems, such as broken hardware

• communication problems between members of the
Development Team or with the Product Owner
The Scrum Master s service to the Development Team is working

towards the removal of these impediments. This does , however,
not require the Scrum Master to remove all impediments
themselves. A valid approach, in line with bullet one of the list of
services to the Development Team, is to support the
Development Team by helping them remove their own
impediments wherever possible. Should impediments arise that
are beyond the reach of the Development Team, however, the
Scrum Master is responsible for taking action.
Example: During the Daily Scrum , an impediment is identified:
for proper software testing, the members of the Development
Team require one more monitor each. The Scrum Master will
help the Development Team determine how to solve this
impediment. One member is determined to request additional
hardware from the tech support.
The tech support replies that the request is not possible to be
fulfilled due to budgetary constraints. In this case, the Scrum
Master takes ownership of the issue and reaches out to the
person in charge of the budget , explains the Development Team s
needs and works towards finding a solution on behalf of the
team .
• Facilitating Scrum events as requested or needed; and,

This is a service the Scrum Master may provide for both the
Product Owner and the Development Team. The Development
Team is actively involved in all of the four Scrum Events within a
Sprint:
6 The Scrum Team 99
During the Sprint Planning, the Development Team provides

its forecast , collaborates to craft a Sprint Goal and defines
an initial plan to reach the Sprint Goal.
During the Daily Scrum , the Development Team inspects
the progress towards the Sprint Goal and makes
adjustments if necessary.
During the Sprint Review, the Development Team presents

what they worked on, demonstrates the new Increment ,
collaborates with the Product Owner and stakeholders on
what the likely next steps will be.
During the Sprint Retrospective, the members of the

Development Team participate as a member of the Scrum
Team , aiming to improve the overall process.
The Scrum Master may support these events through facilitation

if they are requested to do so by a member of the Scrum Team.
Furthermore, the use of "of needed" implies that the Scrum
Master may choose to proactively take the facilitator role if they
deem it necessary.
The facilitation is a service to the Development Team , because

it allows the Development Team to more effectively live out their
role if the Scrum events function more properly due to the Scrum
Master 's facilitation than without it .
Example: The Development Team provides a forecast during
Sprint Planning. They feel pressured by the Product Owner to
increase that forecast in order for the Scrum Team to meet
predefined deadlines. This pressure persists: throughout the
meeting, the Product Owner pressures the Development Team to
take on more work than they feel achievable. In this case, the
Scrum Master should intervene and facilitate the meeting. In a
second step, the Scrum Master should work with the Product
Owner on their understanding of the roles and their respective
responsibilities.
The intervention of the Scrum Master, taking over the facilitation
6 The Scrum Team 100
of the event, allows the event to progress and ensures that the
Development Team is allowed to choose as many items as they
believe are achievable.
• Coaching the Development Team in organizational

environments in which Scrum is not yet fully adopted
and understood.
Environments with low understanding and adoption maturity of

Scrum place a significant burden on the way the Development
Team works. Scrum defines the Development Team as
self -organizing, meaning they have the skills to organize their
own work on one side, but on the other side also have the
organizational empowerment to make those decisions for
themselves. In environments that lack understanding of the
intrinsic logic of Scrum, it is likely that outside influences will
attempt to influence the decision making .
The responsibility of the Scrum Master is to help the
Development Team understand the need for and benefits of a
-
self organizing team
^
but beyond that also help them address
the specific challenges that the organizational environment
places on the Development Team.
Example: A Development Team in an organization that has very

recently introduced Scrum is struggling with a manager
repeatedly trying to intervene in their work or trying to force some
of them to do work outside the Sprint. Some members of the
Development Team are complying with the requests, wanting to
avoid troubles.
The Scrum Master now needs to work with the Development
Team to help them understand the reasons for avoiding such
behavior. Furthermore, they need to work with the team to find a
25
see bullet one
solution to the problem, e.g., by preparing the Development Team

and planning and facilitating a meeting between the manager and
the Development Team on this topic, aimed at gaining a
commitment from the manager to stop their behavior.
6.3.3 Scrum Master Service to the Organization
• Leading and coaching the organization in its Scrum

adoption;
In this sentence , the Scrum Guide argues that the Scrum Master
should work towards an improvement of the organization s
adoption of Scrum. It uses the verbs "leading" and "coaching" to
describe the activities related to this.
By using leading", the Scrum Guide ascribes to the Scrum Master

the responsibility to actively push forth the adoption of Scrum . This
is particularly relevant in the early stages when Scrum is being
introduced or is still very newly adopted. By using "coaching", the
Guide refers to the long-term service to the organization, helping
it consistently improve in its adoption of the Scrum framework in
its context.
The expression "Scrum adoption” has to be differentiated from
"Scrum implementation", as mentioned in the following bullet. By
"Scrum adoption”, it refers to the broader organizational attitude
towards Scrum and its use within the organization.

The methodology to be chosen is left up to the Scrum Master. It
does, however, usually involve working with existing management
structures as well as potentially with (key ) stakeholders from
internal and external stakeholders.
Example: A company has decided to introduce Scrum. The
Scrum Master must lead the adoption of Scrum by proactively
working with the management to help them understand the ideas
behind the Scrum framework and the subsequent necessities for
changes on the organizational level. Once the first Scrum
implementations have been conducted and Scrum Teams take up
their work , the Scrum Master remains in regular contact with key
players relevant to the adoption of Scrum and helps them better
understand Scrum, its theory, its uses and its requirements.
• Planning Scrum implementations within the

organization;
The Scrum Master supports the organization by taking on the

responsibility of planning Scrum implementations. By "Scrum
implementations", the Guide refers to the use of Scrum for the
development of a specific product and the subsequent creation of
one or more Scrum Teams for that purpose.
Scrum Teams are self-organizing once they have been
established and use empirical process control to improve their
process as well as potentially their own composition. The Scrum
Master , however, takes the lead in planning this initial set-up. As
the Guide does not specify further what is involved in this
planning, this could be understood as anything between
• defining the staffing , initial Sprint length and other key

parameters of the Scrum Team( s)
• merely initiating the process and creating the surroundings,

such as a time, a location and the proper atmosphere, for
people to self-organize into Scrum Teams.
Ken Schwaber , one of the co-creators of Scrum, makes a point in
support of the latter understanding in one of his blog posts. In it ,
he poses the question of how best to divide 100 developers into
Scrum Teams. His answer is to create proper conditions, such as
ensuring a common understanding of the product and its
technical requirements, and then allow them to self -organize into
teams.1101
• Helping employees and stakeholders understand and

enact Scrum and empirical product development;
In the second sentence of the Scrum Master section, the Guide

defines a Scrum Master as someone responsible for "helping
everyone understand Scrum theory, practices , rules, and
values ." 6 In the services to the organization, this manifests in the
Scrum Masters responsibility to increase the understanding of
employees and stakeholders about Scrum and the subsequent
implications of using an empirical approach to product
development.
The Scrum Master is further responsible for helping these parties

enact Scrum, which mirrors a prior description of the Scrum
Master as helping "those outside the Scrum Team understand
which of their interactions with the Scrum Team are helpful and
which aren't".27 This is highly contextual and depends on the
relation between the individual in question and the Scrum
adoption or implementation.
Example: A Scrum Master enters an environment where Scrum

has only recently been introduced. The product development is
working well; however, the stakeholders are hesitant to provide
feedback and engage in the Sprint Reviews. The Scrum Masters
responsibility is to help the stakeholders understand Scrum and
their role in it and work with them to find a way how they can
better serve their function. The stakeholders and Scrum Master
collaborate to come up with a working agreement regarding their
feedback on product releases and together develop a proposal on
how to change the format of the Sprint Review to allow for more
feedback from the stakeholders.
26
see page fi2
2
see pace 85
• Causing change that increases the productivity of the

Scrum Team; and,
This sentence describes the responsibility of the Scrum Master to
initiate changes aimed at increasing the Scrum Team's
productivity. Placing this sentence in the list of services to the
organization reflects the understanding of the Scrum Team's
place in the organization: the creation of some value in the
organization takes place within the Scrum Team(s).
The goal of the organization is to deliver a value, which in cases

of a for-profit organization is delivering something that will
generate profit . At least part of this value is created by the Scrum
Teams, which means that increasing the productivity of the
Scrum Teams directly serves the organization in achieving its
goals. Making changes towards increasing productivity is,
therefore, a service to the Scrum Team, as well as to the
organization.
The change mentioned may be of any kind, including changes to

internal policy, hiring guidelines, working agreements and even
the company structure.
Example: A company is developing one product with a total of 7
Scrum Teams. There are also a sales department , an HR
department , a marketing department and a management layer.
The Scrum Master determines that the different departments do
not collaborate well with each other and with the teams. The
marketing department and the sales department do not work well
with the Product Owner, the HR department hires new
developers without consultation of the Scrum Teams , and the
management insists on having to sign off on many non-crucial
decisions.
The responsibility of the Scrum Master is now to find and
implement a way to better integrate the marketing and sales
department into product development.
Furthermore, they need to work with HR to ensure that the
Scrum Teams, and especially the Development Teams, are

involved in the recruitment process by making their needs
transparent , defining their requirements and collaborating with
the HR department on candidate selection.
Lastly, the Scrum Master needs to work with the management to
gradually transition more decision-making ability into the Scrum
Teams, allowing them more self-organization.
• Working with other Scrum Masters to increase the

effectiveness of the application of Scrum in the
organization.
The work of Scrum Masters can be broadly categorized into two

spheres: the work within their Scrum Teams and the work outside
their Scrum Teams. Many topics are exclusively located within a
Scrum Team, such as the quality of the Daily Scrum or the
effectiveness of Sprint Retrospectives Beyond that , however,
there are topics affecting multiple teams. To address these
issues , the Guide requires the Scrum Masters to work together to
increase the effectiveness of Scrum's application. This serves to
increase the value created by the Scrum Teams and therefore
serves the goals of the organization .
Example: An organization has two Scrum Teams working on its
product , supported by one Scrum Master. Due to the success
and growing demands from the market , it has to scale its
production and, subsequently, its number of developers. Within a
short time, the organization has five Scrum Teams working on its
product, supported by a total of three Scrum Masters.
These new conditions pose new challenges to the application of
Scrum within the organization. Whereas before, coordinating the
work of two Scrum Teams was done easily, coordinating five
teams creates problems. The Scrum Masters need to work
together to devise a concept for addressing these problems, such
as the implementation of a scaled Scrum framework.
7 Scrum Events 107
7 Scrum Events
Prescribed events are used in Scrum to create regularity and

to minimize the need for meetings not defined in Scrum.
Scrum is an iterative framework. The iteration is the Scrum event

-
called "Sprint , which acts as a container for the other four
events. Every iteration has the same order of events, which
creates a regularity.
The term "prescribed events" indicates that these meetings are

not optional, but mandatory .
Every Sprint begins with a Planning, usually contains multiple
Daily Scrums . always contains a Review and always ends with
a Retrospective. This regularity is intended to reduce complexity
and support the creation of flow. Scrum s goal of value delivery is
best achieved when teams get into a flow of work, without being
interrupted regularly by other meetings. The events are created
to cover all the basic needs a Scrum Team may have regarding
meetings. Depending on the context, other meetings may still be
useful and take place. However, the need for other meetings is
strongly reduced, and hence the number of overall meetings and
the time spent on meetings is reduced.
Theoretically, a Spnnt could be two days long and thus only have one Daily
Scrum, or even just one day long and therefore have no Daily Scrum. The
Scrum Guide prescribes though that a Sprint must be long enough to deliver
significant value, which in practice is not the case with Sprints that short.
7 Scrum Events 108
All events are time-boxed events, such that every event has a
maximum duration.
All five events defined by the Scrum Guide contain time-boxes,

meaning a maximum duration defined in the Scrum Guide. The
meetings may not exceed this duration. The time- box can be seen
in three different (not mutually excluding) ways :
• Knowing the maximum duration of a meeting creates

predictability and allows for planning appointments without
leaving buffer time in between them.
• The time-box serves is an instrument for transparency. If a

meeting exceeds the defined time, an intuitive response
may be to extend the meeting if possible or to set up a
follow- up meeting. While this may solve the immediate
problem addressed by the meeting, it does not work
towards addressing the underlying issues that lead to the
meeting taking longer than planned.
An enforced time-box may lead to meetings being
unfinished when the time-box expires, which indicates that
the meeting's efficiency is not at an appropriate level . It
thus provides transparency about the need to improve the
meetings, i.e.. for inspection and adaptation.
• In 1955 British historian Cyril Northcote Parkinson

published an article in The Economist , coining what is
today known as "Parkinson's Law", arguing that "work
expands so as to fill the time available for its completion
".[ 111 In a subsequent book , he elaborates with examples
his observations that work tends to grow in (often

unnecessary ) complexity until it fills the time available, even
though the original problem could have been addressed
with much less complexity and thus much less time.f 121
Placing a time-box on the Scrum Events can thus be seen
as forcing a limit on the growth of ( unnecessary )
complexity, therefore establishing a focus on the crucial
aspects and, in turn, saving time.
7 Scrum Events 109
Once a Sprint begins, its duration is fixed and cannot be

shortened or lengthened.
The iterative nature of Scrum allows for Sprints to be compared

with each other, which provides the basis for empirical process
control. Having similar conditions, among other things, a
consistent length of Sprints, allows Sprints to be compared and
hence allows for possibilities to inspect and adapt.
The duration of Sprints can be adjusted before the beginning of a

Sprint, though this should not be done frequently.
The remaining events may end whenever the purpose of the

event is achieved, ensuring an appropriate amount of time is
spent without allowing waste in the process.
Unlike the Sprint itself , the other four events may end before the
defined time-box has expired. Thus, there are two reasons for an
event to end: the time-box has expired , or the goal of the event
was achieved.
The Scrum Guide gives maximum durations to limit the time spent
on things that do not work towards concrete value delivery. Thus,
an upper limit exists to ensure empirical process control regarding
the efficiency of the events. If , however, an event ends prior to its
time-box expiration, more time can and should be spent on work
towards value delivery.
Other than the Sprint itself , which is a container for all other
events, each event in Scrum is a formal opportunity to
inspect and adapt something. These events are specifically
designed to enable critical transparency and inspection.
The Sprint Planning, the Daily Scrum, the Sprint Review, and the
Sprint Retrospective all provide opportunities to inspect and
adapt parts of the product development process. They are set up
7 Scrum Events 110
to cover, collectively, all necessary inspection. Using the term

"formal opportunity” emphasizes that the events should not be
understood as something where inspection and adaptation could
theoretically take place , but that instead they are. as the second
sentence outlines, specifically designed in order to serve as
opportunities for empirical process control.
Scrum is addressing complex problems: , therefore very little is

certain in the development process, and constant adjustments
need to be made to improve the process towards value
delivery.
The areas inspected by each event are addressed in the
respective sections of the Guide and their explanations.
Failure to include any of these events results in reduced

transparency and is a lost opportunity to inspect and adapt .
The Scrum Guide repeatedly emphasizes the idea that "Scrum is
^
... immutable meaning that adopting only parts of the practices
and ideas outlined by the Scrum Guide is not Scrum and will not
lead to the same results as adopting Scrum properly would. With
regard to the events, this holds true, as the events are crafted
to complement each other and to collectively cover all necessary
inspections to maintain the development process.
In practice, the most commonly adopted practice described in the
Scrum Guide is the Daily Scrum, sometimes under the title of
"Daily" or " Stand- Up”, the most commonly left out is a
Retrospective at the end of each Sprint. Not including a
Retrospective in each Sprint may save time in the short run,
though it means that the process of the team might not be
inspected, and consequently, no adaptations may be made. This
2
see explanation of complexity In the Cynefm Framework on pages 7ft.
3
see chapter Endnotes on page 207
7 Scrum Events 111
is what the Guide describes when speaking of a lost opportunity

to inspect and adapt .
7 Scrum Events 112
7.1 The Sprint
The heart of Scrum is a Sprint, a time-box of one month or

less during which a "Done", useable, and potentially
releasable product Increment is created.
Scrum is an iterative framework, with the iteration being called a

" Sprint " . It acts as a container for all Scrum events as well as the
development work.
The title "Sprint” can be interpreted by understanding the
characteristics of a sprint in racing, for where the term is
borrowed . Unlike, for example a marathon, a sprint is relatively
,
short in duration. A project managed in a waterfall approach will

potentially run for years before delivering value to the customer ,
whereas a Sprint delivers a piece of value - an Increment - in a
relatively short amount of time.
Jeff Sutherland describes the origin of the term as follows:
"And so my team embarked on what we called "sprints”. We called
them that because the name evoked a quality of intensity. We
were going to work all out for a short period of time and stop to
see where we were." Q 3J
The Sprint is limited to one month or less. The exact timeframe

chosen must be long enough to allow the Scrum Team to create
an Increment that is "Done” according to the definition of "Done”
and which could be released into the market. This evaluation is
made by the Scrum Team. On the other side, a Sprint should
ideally be short , as this allows for faster feedback and therefore a
development closer to the stakeholders' needs, as well as limiting
the risk of waste, in case the result of a Sprint is not according to
the needs of the stakeholders at all.
7 Scrum Events 113
Sprints have consistent durations throughout a development

effort.
The duration of Sprints should be consistent over time, as this both

provides practical benefits in everyday work , as well as support
empirical process control. Alterations to the duration can be made
but should be done rarely and carefully. Having a consistent length
of Sprints creates a habit within the team and allows for better
progress evaluation within the Development Team.
A consistent duration also allows for Sprints to be compared to

each other, as the potentially crucial parameter of duration
remains consistent. This ability to compare provides a necessary
basis of transparency to inspect and adapt upon. For example , a
Retrospective at the end of a one-month Sprint may yields ideas
on how to improve the performance of the upcoming Sprint ,
which is also one month in duration. The ideas are implemented,
and at the end of the next Sprint , the results of both Sprints are
compared. While other parameters, e.g., factors in the
organization , may also have changed, the two Sprints share a
crucial characteristic their duration which makes the
comparison and the subsequent learnings more valid .
In a counterexample, the ideas may be implemented and also the

duration of the next Sprint is shortened from a month to two
weeks. The results determined in the next Retrospective cannot
easily be compared to those of the previous Sprint , an increase
in performance may be due to the implemented ideas, but also
due to the consequences of a shorter time-box . To even compare
the performances, for example, in Story Points delivered, the
result of the second Sprint must be extrapolated; whether this is
appropriate or not cannot be definitively said.
When attempting improvements, which in an environment of

complex problems means experiments that need to be evaluated,
the goal must be to limit the number of altered parameters as
much as possible. This includes the duration of the Sprint , which
should thus remain constant if possible.
7 Scrum Events 114
A new Sprint starts immediately after the conclusion of the

previous Sprint.
The Scrum Guide does not recognize a time between Sprints.

The entire development process is set up as a (potentially
endless) series of iterations with nothing else in-between. This
forces the Scrum Team to organize their entire work into
iterations and thereby under empirical process control, In
practice, some teams may use a Time in-between Sprints" for
clean-up work, code-refactoring, additional testing, etc., while all
this work should instead be part of the Sprint so that it can be
properly inspected and improved.
Sprints contain and consist of the Sprint Planning, Daily

Scrums, the development work, the Sprint Review, and the
Sprint Retrospective.
In this sentence, the Guide emphasizes the role of the Sprint as a
container for the other four events and the development work
again. Unlike the four other events, which are meetings at a
specific time, a Sprint describes a timeframe in which other
things take place.
During the Sprint:
• No changes are made that would endanger the Sprint

Goal ;
The goal of a Sprint is to deliver an Increment , meaning to deliver a
product that has a higher value than it had prior to the Sprint. The
direction for this added value is given by the Sprint Goal, which is
crafted during the Sprint Planning. This can be thought of as the
justification for the Sprint; once it becomes irrelevant or impossible
to reach, the Sprint becomes obsolete . Therefore, any changes
1
4
see section on canceling a Sprint on page ijj)
7 Scrum Events 115
that are made during a Sprint are not allowed to endanger the
Sprint Goal.
• Quality goals do not decrease; and.

The quality goals, most prominently outlined in the definition of
"Done", may be adjusted e.g., as a result of a Retrospective but
may not be lowered during a Sprint . As more is learned throughout
the Sprint , they may increase, however, if necessary.
For example, when working in areas relevant to IT security,
additional quality requirements may emerge without which an
Increment would fulfill the definition of "Done”, but not be
potentially shippable. Quality goals may not be lowered during a
Sprint for two reasons:
• Based upon an agreed-upon Definition of "Done", the

stakeholders may have expectations that would not be
fulfilled with an Increment with lower quality goals.
• Quality goals are critical parameters in empirical process

control. In order to compare the functionality of the product
development process, parameters should remain constant ,
and if they are changed, the changes should be made in a
controlled manner, allowing for the inspection and possible
adaptation of the changes.
• Scope may be clarified and re-negotiated between the

Product Owner and Development Team as more is
learned.
This rule explicitly permits changes to the scope of a Sprint

during the Sprint. When dealing with complex problems,
estimations on Product Backlog items can be off , sometimes by
7 Scrum Events 116
significant amounts, in both directions ,Even when having

conducted proper Sprint Backlog refinements, it is possible that
the full scope of work units is only understood during the Sprint ,
while work is being done. Alternatively, conditions may also
change in non-preventable ways, for example, through the
sickness of members of the Development Team.
Scrum is sometimes - wrongly - understood as having a static

Sprint Backlog , i.e. , that Product Backlog items agreed upon in
the Sprint Planning cannot be changed. Rather , the Sprint Goal is
static and. as the first rule outlines, may not be endangered. How
the Sprint Goal is achieved, however, can be changed through
an agreement between the Product Owner and the Development
Team .
For example: During a Sprint Planning, a Swum Team , working
on a mobile app, crafts a Sprint Goal that says: 'At the end of this
Sprint , the user can visit their profile section". Under that goal, the
Sprint Backlog contains items including:
• The user can see their own profile picture

• The user can change their own profile picture
• The user can see their personal data
• The user can edit their personal data
The Development Team believes they can get all these items
" Done" , but throughout the Sprint, one of the four developers
becomes sick and cannot work, and the remaining developers

realize that the technical process underlying the change of profile
pictures is more complex than initially thought .
The rule now permits that the Development Team and the Product
Owner discuss and come to the agreement . The scope must be
adjusted : while the user still received the added value of being
able to see their profile section, this section does not ( yet ) include
the possibility to change their profile picture. This feature may be
added in another Sprint.
7 Scrum Events 117
Each Sprint may be considered a project with no more than

a one-month horizon. Like projects, Sprints are used to
accomplish something. Each Sprint has a goal of what is to
be built, a design and flexible plan that will guide building it,
the work, and the resultant product increment.
The iterative , incremental approach of Scrum breaks down

product development , which in conventional project management
approaches would be one large project , into a series of smaller
projects. Each of these projects is worked on during a Sprint and
has
• a goal, which is determined during the Sprint Planning. The

Product Owner and the Development Team collaborate to
craft a Sprint Goal from the ( business) objectives and the
forecast of what can be accomplished . This Sprint Goal can
be seen as the goal of the project that is worked on during
Sprint .
• a design providing guidance on how to achieve the Sprint

Goal in the form of the Sprint Backlog, which consists of the
selected Product Backlog items as well as a plan on how to
deliver them in an Increment. This is a flexible plan, as it is
not static, but is revisited at least during every Daily Scrum
and can be changed as long as the Sprint Goal . The goal
of the project remains intact.
• work done towards the goal of the project , which is the

development work of the Development Team.
• a resultant product in the form of the increment , which in

Scrum is not a final product relative to the iterative,
incremental process , but final relative to the project worked
on during the Sprint.
The duraton of each of these projects is limited to a month; the

reasons for this are explained in the following sentences of the
Guide.
7 Scrum Events 118
Sprints are limited to one calendar month. When a Sprint ’s

horizon is too long, the definition of what is being built may
change, complexity may rise, and risk may increase. Sprints
enable predictability by ensuring inspection and adaptation
of progress toward a Sprint Goal at least every calendar
month. Sprints also limit risk to one calendar month of cost .
With this paragraph, the Guide provides two guidelines: On the

one hand, it establishes a fixed upper limit for the duration of the
Sprint, which is defined as one calendar month. On the other
hand, it provides Scrum Teams with a guideline on how to choose
the appropriate length for their Sprints.
One of the goals of Scrum Events is to create regularity and

thereby reduce complexity. For Sprints, this is usually achieved
by aligning their length to existing regularities, namely the
. -
calendar week or the calendar month Having 10 day Sprints is
theoretically possible, the resulting shift of the Scrum events
relative to the days of the week would create (potentially )
unnecessary complexity.
Therefore, most Sprint durations in practice are defined in

multiples of weeks, namely one week, two weeks, three weeks or
four weeks. Sprints can, however, also be aligned to calendar
months. It is important to note that in prior sentences, the Guide
-
stated the time box for the Sprint to be a month, here it especially
refers to a "calendar month", specifying the duration as beginning
at the start of a specific month and ending on the last day of the
same month .
The calendar month limit is not determined by any calculations,
but rather has established itself from practical experience using
empirical process control, like the maximum number of members
of the Development Team. -
5 seethe explanation on the maximum number of members of the

Development Team on page 79
7 Scrum Events 119
7.1.1 Cancelling a Sprint
A Sprint can be cancelled before the Sprint time- box is over.

Only the Product Owner has the authority to cancel the
Sprint , although he or she may do so under influence from
the stakeholders, the Development Team, or the Scrum
Master.
A Sprint in Scrum is of a fixed and consistent length. There may

be circumstances, however, which lead to the assessment that the
value generated by continuing the Sprint does not justify the cost
of doing so anymore.
The evaluation of whether this is the case is taken by the Product

Owner, as they are tasked by the Scrum Guide to maximize the
value delivered by the work of the Development Team. Others
involved with product development , such as stakeholders and
other members of the Scrum Team , may provide their opinions
on the matter ; however, the final decision must be made by the
Product Owner and be respected .
A Sprint would be cancelled if the Sprint Goal becomes

obsolete. This might occur if the company changes
direction or if market or technology conditions change. In
general, a Sprint should be cancelled if it no longer makes
sense given the circumstances. But , due to the short
duration of Sprints, cancellation rarely makes sense.
The Sprint Goal may become obsolete due to a variety of factors,

including the mentioned direction changes of the parent
organization or changing conditions surrounding the product. As
the Sprint Goal provides the purpose for the Sprint, an obsolete
Sprint Goal renders the Sprint obsolete, what the Guide
expresses as "it no longer makes sense".
7 Scrum Events 120
In the final sentence, the Scrum Guide points out that Sprint
cancellations a rare occurrence. Sprints are kept as short as
possible6 , in order to minimize the risk of developing in a wrong
direction. Therefore obsolescence being realized within a Sprint
is rare.
When a Sprint is cancelled, any completed and "Done”

Product Backlog items are reviewed. If part of the work is
potentially releasable, the Product Owner typically accepts
it. All incomplete Product Backlog Items are re-estimated
and put back on the Product Backlog. The work done on
them depreciates quickly and must be frequently
re-estimated.
The Scrum Guide defines a clear process for Sprints succeeding
each other. In this sentence, however, it outlines what happens
with this direct succession is interrupted due to a Sprint
cancellation.
The ’ Done” Product Backlog items are reviewed While not ,
explicitly state, it can be assumed that this review takes place

without the formal setting of a Sprint Review, but rather within the
small circle of the Scrum Team. In order to not waste the work
that was already done, the Product Owner may choose to accept
them .
The Guide uses a descriptive terminology rather than a
prescriptive by saying the Product Owner "typically accepts it".
This indicated that this is not a rule the Product Owner must
follow, but that it can be considered good practice to do so.
The incomplete Product Backlog items are moved from the Sprint
Backlog back into the Product Backlog. As there may be work
done on them aJready or as new insights throughout the canceled
Sprint may have arisen, the items are re-estimated. In this
fcsee sentence on the duration of a Spnnt on page 1JJ3

7 Scrum Events 121
sentence, the Guide uses prescriptive terminology, indicating that

moving the items back into the Product Backlog and
re-estimating them is mandatory, as the Product Backlog as an
Artifact must reflect what is currently known about the product
and its future direction.
If work was done on the items moving back into the Sprint
Backlog, this work might become unuseful quickly. As the Sprint
Goal became obsolete, it is unlikely that the next regular Sprint
will contain all Product Backlog items for which (unfinished) work
exists. Therefore, the product itself will change along with the
general surroundings of the product. The usability of the
unfinished work will, therefore, depreciate over time, which must
be reflected in the estimations.
Sprint cancellations consume resources, since everyone

regroups in another Sprint Planning to start another Sprint.
Sprint cancellations are often traumatic to the Scrum Team,
and are very uncommon.
Canceling a Sprint is described as having two negative

repercussions.
• On the one hand , the immediate need for another Sprint
Planning consumes time that would otherwise be usable for

further work on the product.
• On the other hand, Sprint cancellations are described as

often traumatic *. Scrum aims to reduce complexity by
" ’
working with predictable cadences, i.e., regularly

reoccurring events, for example conducting a Daily Scrum
every day and having Sprint of consistent length. A Sprint
cancellation breaks with this order and creates a
-
short term chaotic situation. Furthermore, a Sprint
cancellation implies that the work done throughout the
Sprint until its cancellations was not the best use of the
work of the Development Team and may, in the worst case,
even have produced waste.
7 Scrum Events 122
The Scrum Guide finishes this section by pointing out that

cancellations of Sprint are very uncommon, which gives another
indicator to the Product Owner to only make the decision to
cancel a Sprint very cautiously.
7 Scrum Events 123
7.2 Sprint Planning
The work to be performed in the Sprint is planned at the

Sprint Planning.
During the Sprint Planning, the Scrum Team plans the work that
should be performed in the Sprint. The term "planned" herein
covers the process of selecting the Product Backlog items to be
worked on, the creation of an overarching Sprint Goal, as well as
deciding a flexible plan of how to work towards the Sprint Goal by
delivering the Product Backlog items.
This plan is created by the collaborative work of the entire

Scrum Team.
.
The planning involves all roles on the Scrum Team The Product
Owner presents a business objective and an ordered Product
Backlog, from which the Sprint Backlog will be created. The
Development Team forecasts the amount of functionality they can
deliver and plans on how to do so. Both sides engage in a
dialogue on what can be delivered in the Sprint. This dialogue is
supervised and, if necessary or requested, facilitated by the
Scrum Master.
Sprint Planning is time- boxed to a maximum of eight hours

for a one-month Sprint. For shorter Sprints, the event is
usually shorter.
-
The Scrum Guide defines an absolute time box for the Sprint
Planning as being eight hours for a Sprint lasting one month. The
subsequent sentence outlines that the event is usually shorter for
Sprints lasting longer than one month.
The second sentence is often wrongly seen as advocating
-
scaling the time box linearly with the duration of the Sprint :
7 Scrum Events 124
approximating one month as being four weeks and claiming the

-
time box to be 2 hours for every week in the Sprint. The time box , -
however, remains eight hours for a Sprint of any ( permissible)
-
length, though this time box is usually not fully used in Sprints
shorter than one month.
The Scrum Master ensures that the event takes place and
that attendants understand Its purpose. The Scrum Master
teaches the Scrum Team to keep it within the time- box.
The Scrum Master, as defined by the Scrum Guide, is sometimes

described as the "manager of the process". This is not to say that
they have any hierarchical authority over either the Product
Owner or the Development Team members, but that they are
tasked with ensuring the process defined by the Scrum Guide
takes place. With regard to the Sprint Planning, this can be seen,
as the Scrum Master is given the responsibility for the event to
take place. Another role of the Scrum Master, which is explicitly
outlined in the definition of the Scrum Master role, is to help
those on the Scrum Team understand the Scrum theory and
practices. With regard to the planning, this means:
• ensuring that those attending understand the purpose of the

Sprint Planning within Scrum, and
• teaching the Scrum Team to keep the event within the

time-box to ensure focus and to allow for empirical process
control
The use of the term "attendants", rather than "Scrum Team" or
"Product Owner and Development Team members" emphasizes
that other individuals who are not part of the Scrum Team may
attend the event. In a later section, this is defined as being upon
invitation of the Development Team.7
see the explanation on the Development Team inviting others to the Sprint
Planning on page 134
7 Scrum Events 125
Sprint Planning answers the following:
• What can be delivered in the increment resulting from

the upcoming Sprint?
• How will the work needed to deliver the increment be

achieved ?
The purpose of the Sprint Planning is to plan the work for the
upcoming Sprint. In order to serve this purpose, the Scrum Team
needs to first define the scope and aim of what can be delivered.
This is done by crafting a Sprint Goal and determining what
Product Backlog items will be worked on. In a second step, the
Scrum Team collaborates to determine a plan on how to work
towards delivering the increment fulfilling the Sprint Goal.
While these two questions may be understood as outlining two
phases of the Sprint Planning, determinations made while
working towards answering the second question may affect the
assessment of the scope, and may lead to renegotiations on
what can be delivered. Both questions should, therefore, be
answered in a Sprint Review where the entire Scrum Team is
present throughout.
7 Scrum Events 126
7.2.1 Topic One: What can be done this Sprint ?
The Development Team works to forecast the functionality

that will be developed during the Sprint.
As those doing the work of delivering Product Backlog items, the

Development Team provides a forecast of how much functionality
they can deliver in the upcoming Sprint. The term "functionality"
in this sentence does not refer to specific features in the Product
Backlog, but to an abstract measure of how much general
functionality can be developed .
It can be argued that the Scrum Guide uses the term
"functionality "rather than speaking of "capacity" because the
forecast method chosen must refer to the capacity to deliver
features, rather than merely the time availability. Scrum does not
explicitly prescribe any metric or factors to be considered and
leaves those determinations up to the individual Scrum Teams.
However, it can be assumed that simply stating time availabilities
and later comparing these to time-based estimated of Product
Backlog Items is not approved by the Scrum Guide.
A common approach instead is the use of a Velocity based on
Story Points , calculated e.g. on the performance of the most
recent Sprints and the availability of the Development Team
members.
The Product Owner discusses the objective that the Sprint

should achieve and the Product Backlog items that, if
completed in the Sprint, would achieve the Sprint Goal. The
entire Scrum Team collaborates on understanding the work
of the Sprint.
The Product Owner is responsible for maximizing the value

delivered by the work and thus determines what is the best use
of the capacity of the Development Team. They discuss the
7 Scrum Events 127
objective of the Sprint , i.e. what the Sprint should achieve if

successful, and the Product Backlog items that would need to be
delivered in order to achieve the objective.
The Scrum Guide uses the term "discuss", instead of e g .
"present", purposefully, since the scope of what features can be
delivered can vary with the combination of Product Backlog

items. The Product Owner and the Development Team may
engage in a discussion on how different combinations of Product
Backlog items may best serve the objective defined by the
Product Owner, considering the finite capacity of the
Development Team. Throughout this process, both parties, as
well as the Scrum Master, collaborate to define, re-define and
refine a Sprint Goal, which gives guidance on what Product
Backlog items should initially be selected to be placed in the
Sprint Backlog.
The input to this meeting is the Product Backlog, the latest

product Increment, projected capacity of the Development
Team during the Sprint, and past performance of the
Development Team.
In order to determine what will be worked on in the upcoming

Sprint , the following things must be known or determined and are
thus inputs for the Sprint Planning:
• The latest Increment is, by definition, the product existing

at the time of the Sprint Planning. As product development
in Scrum works incrementally by adding on top of the
existing product version ("Increment"), the work of the
upcoming Sprint will integrate with the increment to create
a new Increment . All work in the upcoming Sprint must
take the overall situation of the increment , with its features
and technical debt , into consideration . Therefore, the
increment at the time of the Sprint Planning provides the
definition of a starting point.
7 Scrum Events 128
• The projected capacity and the past performance give an

indication of the scope of what can be delivered in the
upcoming Sprint. They are crucial to understanding how far
the development can go forward from the starting point.
• The Product Backlog, as a list of deliverables sorted by

value, provides the items which will be drawn into the
Sprint Backlog and worked on by the Development Team
throughout the Sprint. Therefore, the Product Backlog
provides a sense of the direction into which the work of the
Development Team will go.
The awareness of all of these facts allows the Scrum Team as a
whole to craft an appropriate Sprint goal and the Development
Team to decide on how many items it believes it can work on
during the Sprint.
The number of items selected from the Product Backlog for

the Sprint is solely up to the Development Team. Only the
Development Team can assess what it can accomplish over
the upcoming Sprint .
-
The Development Team is self organizing with regard to their
work, which includes the right to decide the scope of what they
believe they can accomplish. The Product Owner may try to
motivate them to add more items, though the final decision is up
to the Development Team. This again is a manifestation of the
principle that decisions should be reached as close to the point of
work as possible. ®
" see explanation on wtiy Scrum is not a process on paoe 13

7 Scrum Events 129
During Sprint Planning the Scrum Team also crafts a Sprint

Goal. The Sprint Goal is an objective that will be met within
the Sprint through the implementation of the Product
Backlog, and it provides guidance to the Development Team
on why it is building the increment.
The Sprint Planning produces two immediate outcomes:
•A first version of the Sprint Backlog, which contains the

Product Backlog items the Development Team has
assessed it will be able to deliver within the Sprint, as well
as a initial plan of how to achieve this
• The Sprint Goal

The Sprint Goal defines the purpose of the Sprint , it outlines what
objective will be met through the work of the Development Team.
The Scrum Guide refers to this work as the Implementation of
the Product Backlog’ rather than the "implementation of the
Sprint Backlog" since the Sprint Goal supersedes the Sprint
,
Backlog and may lead to it being changed. The Sprint Backlog is

a list of Product Backlog items and a plan on how to deliver them
to realize the Sprint Goal through the delivery of an Increment .
This plan falls under empirical process control, is inspected at
least during each Daily Scrum and may be adjusted.
Furthermore, if it is determined through inspection that the list of
Product Backlog items is not the best available way to deliver an
Increment which realizes the Sprint Goal, this list may be
changed. The Sprint Goal provides guidance to the Development
Team by outlining the purpose of their development work. Thus, it
provides the necessary transparency for frequent inspection of
the validity of the current Sprint Backlog and subsequently for the
possibility to
• adapt plan of how to turn the selected Product Backlog

items on their own. and
• change the selected Product Backlog items through

negotiations with the Product Owner
7 Scrum Events 130
7.2.2 Topic Two: how will the chosen work get

done?
Having set the Sprint Goal and selected the Product Backlog
items for the Sprint , the Development Team decides how it
will build this functionality into a Done" product Increment
during the Sprint. The Product Backlog items selected for
this Sprint plus the plan for delivering them is called the
Sprint Backlog.
Following the definition of a Sprint Goal and the subsequent
decision on which Product Backlog items the team will work to
deliver during the Sprint, an (initial) plan needs to be devised how
to do this . As this defines an outline for the work of the
Development Team, the self -organizing Development Team is
responsible for creating this plan, albeit with the possible support
of the
• Product Owner, who may assist through clarifications of

-
items, making their own priorities which by definition are
-
the priorities of the product development transparent and
possibly renegotiating the selected items with the
Development Team
• Scrum Master , who may facilitate the event
The sum of this plan and the items selected together form the
Sprint Backlog. The Development Team chose the scope of how
many items would be selected and created the plan of how their
work will be conducted to implement them. Therefore, the Sprint
Backlog is owned by the Development Team.
7 Scrum Events 131
The Development Team usually starts by designing the

system and the work needed to convert the Product Backlog
into a working product Increment. Work may be of varying
size, or estimated effort. However, enough work is planned
during Sprint Planning for the Development Team to forecast
what it believes it can do in the upcoming Sprint.
By using "usually", the Guide gives a common practice rather than

a prescriptive rule. This common practice is for the Development
Team to "design the system", by which the Guide means drafting
a pathway to the desired solution of producing an Increment. This
-
design needs to be broad enough to not over plan, yet specific
enough to derive from it the work necessary for implementation.
At this point, there is no requirement as to how small the units of

work need to be. The only requirement the Guide gives in these
sentences is that the work should be planned thoroughly enough
for the Development Team to provide an estimation of what it
believes to be able to implement in the upcoming Sprint.
Work planned for the first days of the Sprint by the

Development Team is decomposed by the end of this
meeting, often to units of one day or less.
The Sprint Planning must result in a plan that allows the

Development Team to start working towards the Sprint Goal. The
Scrum Guide uses the term "decompose" to describe the
systematic breaking down of work from abstract concepts and
ideas into chunks of work that are implementable. The Guide
gives the convention of "units of one day or less". This is not a
mandatory prescription, but instead a guideline, as the size of
units of work is dependent on the context of the product
development. A balance must be found between
• making units of work too large which leads to a longer time

,
until it is done; this is undesirable, as the Development

Team inspects the Sprint Backlog regularly to possibly
7 Scrum Events 132
make adaptations; this process would be slowed down by

large , long-lasting units of work
• making units of work too small, which creates unnecessary

planning and coordination overhead that is not justified by
the value the unit of work delivers
With regard to the upper limit , the Scrum Guide recommends a

day or less, as this allows a unit of work to be done between two
Daily Scrums and therefore allows the regular inspection and
adaptation mechanism of the Daily Scrum to work optimally.
The Scrum Guide mandates that the ftrst days' worth of work is
decomposed in this manner . In practice the entire work for the
,
Sprint is often decomposed during the Planning , This is

permitted by the Guide: however , it is not mandatory, and may
not be necessary.
The Sprint Backlog contains an initial plan of how the work will be
conducted; this plan is, however, subject to inspection and
possible adaptations during the Daily Scrum . Therefore , on any
day. the work for the upcoming day may change as more is
learned. Thus it may make sense to only decompose work for a
few days in advance but do so repeatedly throughout the
Sprint.
The Development Team self-organizes to undertake the work

in the Sprint Backlog, both during Sprint Planning and as
needed throughout the Sprint.
The Sprint Backlog is owned by the Development Team, which is

a self-organizing unit with the Scrum Team. As such, it is
responsible and empowered to make the decisions for how to
conduct the development work on their own. This is true during
the Sprint Planning, where is refers mainly to the decomposition
of the work into small units, as well as throughout the Sprint ,
where it includes the further decomposition and adjustments to
the plan on how to deliver the Product Backlog items.
7 Scrum Events 133
The Product Owner can help to clarify the selected Product

Backlog items and make trade-offs.
Throughout the process of planning how the selected work will

get done , the Product Owner may be consulted to clarify the
Product Backlog items, should questions come up which were
not previously discussed , for example, ones that emerged during
decomposition. Regarding the trade-offs, the sentence can be
understood in two way. both of which can be considered valid:
• The Product Owner can ... make trade-offs: In this

reading, the Product Owner may make trade-offs on the
Product Backlog items, for example, with regard to the
scope of items, which may occur when planning and
decomposition reveal more about the time and resources
the implementation of an item will likely take. A result could
be to lower the scope of expectations of the item.
• The Product Owner can help to • •• make trade-offs: In this

reading, the Product Owner may assist the Development
Team to decide between different implementation options.
The Product Owner is responsible for the maximization of
the value delivered by the work of the Development Team .
As such, they may give inputs when, for example, two
paths for implementation are possible, one of which would
cost more time but lead to greater functionality, while the
other solution delivery lower functionality but at a lower
( time ) cost.
If the Development Team determines it has too much or too

little work, it may renegotiate the selected Product Backlog
items with the Product Owner.
The Planning is not strictly divided into two phases, as it was in

the Scrum Guide prior to 2013. Instead , the two questions that
need to be answered by the end of the planning may require some
back-and- forth between them. As more is learned throughout the
process of the Development Team planning and decomposing the
7 Scrum Events 134
work, the initial forecast of what can be delivered may change.

Should this be the case, the team revisits the first question of the
Planning and renegotiations what items should be worked on in
the Sprint with the Product Owner.
This renegotiation may keep the Sprint Goal intact, especially
when a few more items of work are added to the Sprint. The new
assessment of what can be delivered may, however, also lead to
the Sprint Goal becoming obsolete, in which case a new Sprint
Goal needs to be crafted by the Scrum Team. While this may
lead to a longer time spent in the Sprint Planning, it would likely
avoid having more complex renegotiation at a later point during
the Sprint.
The Development Team may also invite other people to attend

to provide technical or domain advice.
Unlike, for example, the Daily Scrum, which is an internal

meeting for the Development Team, the Sprint Planning may
benefit from external input. The Product Owner is the only source
.
of the priorities of the Product Backlog and therefore, of what the
-
Development Team will work on. The second question how the
-
chosen work will get done may. however, benefit from inputs
from others on technical and domain issues.
The Development Team owns the process of planning the
selected work, and as such, is both responsible for and
empowered to invite the people they deem appropriate to help
them. It is important to understand that these other people take
part to advise, the Development Team is still responsible for
crafting the plan on how they will get their work done.
7 Scrum Events 135
By the end of the Sprint Planning, the Development Team

should be able to explain to the Product Owner and Scrum
Master how it intends to work as a self-organizing team to
accomplish the Sprint Goal and create the anticipated
increment.
One outcome of the Sprint Planning is the Sprint Backlog , which

is the list o( selected Product Backlog items and an initial plan on
how to turn them into an Increment . The Guide uses the
expression 'should be able" to indicate that the Development
Team is not obligated to explain it to either the Product Owner or
Scrum Master, nor to anybody else The ability to explain the
plan is, however, a useful benchmark of whether the plan is
thoroughly thought through, The Guide emphasizes the
self-organization of the Development Team again, emphasizing
that the plan crafted must be owned and, if necessary, adapted
by the Development Team autonomously. The last part of the
sentence emphasizes again the importance of
• the Sprint Goal as a guiding principle for the work of the

Sprint, and
• the increment as the ultimate outcome of the Sprint.

7 Scrum Events 136
7.2.3 Sprint Goal
The Sprint Goal is an objective set for the Sprint that can be
met through the implementation of Product Backlog. It
provides guidance to the Development Team on why it is
building the increment. It is created during the Sprint
Planning meeting. The Sprint Goal gives the Development
Team some flexibility regarding the functionality
implemented within the Sprint.
In order to answer the first question of the Sprint Planning, "what

can be done this Sprint’, the Scrum Team crafts the Sprint Goal
during the Sprint Planning. The Scrum Guide understands the
Sprint Goal as an overarching objective that guides the
Development Team towards creating an Increment through the
implementation of Product Backlog items.
The Sprint Goal defines the purpose of the Sprint , which acts as
a motivator, as it allows the Scrum Team to commit to something
concrete. It further allows for decisions within the Sprint to be
made. These include specific implementational issues, as well
as inspecting the validity ol the composition of the Sprint Backlog
aiming at achieving the Sprint Goal .
The purpose of a Sprint is not , as is often seen in practice, the

realization of the Sprint Backlog items. These merely serve as an
artifact to inspect and adapt the plans and progress towards the
realization of the Sprint Goal, which is the, in fact , the purpose of
a Sprint.
7 Scrum Events 137
The selected Product Backlog items deliver one coherent

function, which can be the Sprint Goal. The Sprint Goal can
be any other coherence that causes the Development Team
to work together rather than on separate initiatives.
When crafting the Sprint Goal, the Product Owner discusses the
(business) objective they would like to see realized. If this
objective and its correspondingly selected Product Backlog items
for a coherent function, this function may be chosen as the Sprint
Backlog. An example of such a Sprint Goal could be
Implementing the functionality to allow the user to register and
log in\
If such a Sprint Goal cannot be directly derived, or if it is

determined to not be useful for the Scrum Team, it may choose to
craft a Sprint Goal on its own. The Scrum Guide requires only
that pursuing the Sprint Goal leads to the Development Team to
work together. This fosters collaboration and hence knowledge
exchange, as well as motivation and the level of commitment and
collective ownership. The Sprint Goal, in this sense, acts as a
unifying vision for the Sprint.
As the Development Team works, it keeps the Sprint Goal in

mind. In order to satisfy the Sprint Goal, it implements
functionality and technology. If the work turns out to be
different than the Development Team expected, they
collaborate with the Product Owner to negotiate the scope of
Sprint Backlog within the Sprint .
The Sprint Goal is present throughout the Sprint and is, among
other things, consulted every day during the Daily Scrum. The
work of the Development Team, which includes the
implementation of functionality and technology, aims towards
realizing the Sprint Goal. The Development Team s work is the
means to achieve the end of delivering an Increment realizing the
Sprint Goal.
7 Scrum Events 138
Having the Sprint Goal as a focal point allows for evaluation of

the Sprint Backlog and the determination of whether or not the
current plan is still suited to achieve this goal. If new work
emerges or the work previously agreed upon is determined to not
best serve the realization of the Sprint Goal, the Development
Team collaborates with the Product Owner to change the Sprint
Backlog. This change is done in a way that allows the Scrum
Team to deliver an Increment realizing the Sprint Goal, albeit
perhaps in a smaller or different way than initially planned.
q
7 Scrum Events 139
7.3 Daily Scrum
Choosing "Daily Scrum’ as a title for this event may have been
influenced by two factors:
• Schwaber and Sutherland borrowed the term "Scrum" from

rugby's term "scrummage", which is often abbreviated to
"scrum”. A scrum describes a position in which the players
pack closely together to gain possession of the ball. This
can be seen as the basis for choosing the term "Daily
Scrum”, as it is an event where the Developers
metaphorically "stick their heads together".
• The idea of "Scrum" as described by the Scrum Guide is a

framework based on the empirical process control of
transparency, inspection and adaptation, manifesting in
iterative, incremental work. The Daily Scrum provides an
opportunity for inspection and adaptation . It happens daily,
leading to the time between two Daily Scrums being
constant and. therefore, the work between them to be
iterative. Furthermore, during the Daily Scrum, the
participants analyze the work done until the Daily Scrum
and how additional work can be done on top it to reach the
goal, which describes an iterative approach . Therefore ,
every development day can be thought of as a micro- Sprint
of one day, with the Daily serving as a micro-Review and
micro- Retro for the past day and micro-Planning for the
upcoming one.
The Daily Scrum is a 15-minute time-boxed event for the

Development Team. The Daily Scrum is held every day of the
Sprint.
The Scrum Guide prescribes a time- box of 15 minutes for the

Daily Scrum. This maximum duration is independent of the
number of members of the Development Team; the time-box is 15
7 Scrum Events 140
minutes regardless of whether the Development Team consists of

3 members or 9. 15 minutes was chosen as it is long enough to
allow an efficient synchronization between the Development
Team members but short enough to not impede the development
work unnecessarily long. Such a limited time-box also enforces a
strict focus and limitation technical details to a reasonable level.
As implied in the title "Daily Scrum", this event is supposed to
take place every day of the Sprint. This is done in order to:
• have at least one daily opportunity for inspection and

adaptation
• limit the planning of work to a timeframe of only the next 24

hours, which limits risk while not being too frequent to get in
the way of work
• create regularity in order to reduce complexity

The event is defined as being for the Development Team, which,
as a self -organized entity, conducts its own meetings for its own
work. Later sentences in this section of the Guide specify the
extent to which the Scrum Master, Product Owner and other
individuals may be involved.
At it, the Development Team plans work for the next 24

hours. This optimizes team collaboration and performance
by inspecting the work since the last Daily Scrum and
forecasting upcoming Sprint work.
During a Sprint Planning, the work of previous Sprints is

considered, and a forecast of what can be delivered is made.
Analogously, during the Daily Scrum, the team inspects the work
that has been done since the last Daily Scrum and takes this into
consideration when forecasting what work can be done until the
next Daily Scrum. Based on this forecast, the Development Team
plans its work. The Scrum Guide does not prescribe any
methods for how this is done and leaves this detail to the
Development Team.
7 Scrum Events 141
The Daily Scrum is held at the same time and place each day
to reduce complexity.
The Daily Scrum is consistent in time and place each day. This
rule has both theoretical as well as very practical reasons:
• Holding the event at the same time every day allows for the
individual workdays to be likely of the same length. This
makes it easier to compare workdays with each other and
therefore creates a higher degree of transparency on the
basis of which inspection and potential adaptation may be
conducted.
• Consistency of time and place makes remembering these

parameters easier for the Development Team members.
Changing rooms frequently may lead to some members
going to the wrong room. Changing times may lead to
members confusing the time and showing up in the room at
a time when no Daily Scrum takes place, or not show up
for a Daily Scrum as they forgot about it. Both changes
increase the likelihood of problems, which are more
substantial for the Daily Scrum, considering the short
-
time box of only 15 minutes.
It also establishes a clear time when the Developers are
unavailable, making planning other appointments easier,
especially for people who are not part of the Development
Team .
The Development Team uses the Daily Scrum to inspect

progress toward the Sprint Goal and to inspect how
progress is trending toward completing the work in the
Sprint Backlog.
Every event in Scrum is set up to create an opportunity for

inspection and adaptation. The Daily Scrum is to be used by the
Development Team to inspect the progress. The result is then
used to extrapolate the scope of what can be achieved with
7 Scrum Events 142
regard to the Sprint Goal. This provides the basis on which

potential alterations to the Sprint Backlog might be made , such
as
• adding items to the Sprint Backlog

• re-negotiating the scope of the Sprint while keeping the
Sprint Goal intact
• informing the Product Owner that the Sprint Goal cannot be

met
The Daily Scrum optimizes the probability that the

Development Team will meet the Sprint Goal.
The Daily Scrum contributes to the increased probability of

meeting the Sprint Goal in two ways :
On the one hand, it provides a forum for the entire Development

Team to synchronize, make impediments transparent , and plan
how to work for the upcoming 24 hours. This coordination and
the subsequent collaboration increase the efficiency of the work
of the Development Team and therefore makes the delivery of the
selected Product Backlog items more likely.
On the other hand, the Development Team reassesses their path
towards the Sprint Goal every day and is, therefore, able to react
quickly once it becomes apparent that not all the selected Product
Backlog items will be deliverable. It may then choose to work with
the Product Owner to re-negotiation the selected items while still
keeping the Sprint Goal intact , increasing the chance to still meet
the Sprint Goal, albeit with a smaller number of selected items.
7 Scrum Events 143
Every day, the Development Team should understand how it

intends to work together as a self-organizing team to
accomplish the Sprint Goal and create the anticipated
increment by the end of the Sprint.
-
In Scrum, the Development Team is a self organizing entity. The
Daily Scrum provides a powerful benchmarking mechanism for
-
whether it is ( already) capable of self organizing. If every Daily
Scrum ends with the team understanding how it will work towards
-
the Sprint Goal, that is a strong indicator for a self organizing
.
team Troubles reaching this understanding, conversely, can be
an indicator that the team needs more support in becoming
-
self organizing, especially from their Scrum Master.
The structure of the meeting is set by the Development Team

and can be conducted in different ways if it focuses on
progress toward the Sprint Goal. Some Development Teams
will use questions, and some will be more discussion-based.
Here is an example of what might be used:
• What did I do yesterday that helped the Development

Team meet the Sprint Goal?
• What will I do today to help the Development Team meet

the Sprint Goal?
• Do I see any impediment that prevents me or the

Development Team from meeting the Sprint Goal?
This section was one of the more profound changes in the 2017
update to the Scrum Guide. Previously, the Guide introduced the
three questions with "During the meeting, the Development Team
members explain:", thereby mandating these three questions.
With the 2017 update, the Guide grants the Development Team
the freedom to determine the structure of the Daily Scrum for
themselves. The three questions remained part of the Scrum
Guide, but are now introduced as an example. The three
7 Scrum Events 144
questions can be seen as dealing with the same issues as the

other events within a Sprint:
•' What did I do yesterday. . ." - Answering this question

looks back at work conducted since the previous Daily
Scrum like a Review looks back at work conducted ( and
the value generated ) in the last Sprint .
•‘ What will I do t o d a y. - Answering this question looks

ahead at work to be conducted until the next Daily Scrum
like a Planning looks ahead at work to be conducted in the
upcoming Sprint.
• "Do / see any impediments. - Answering this question

looks at what has been or will be problematic lor the success
of the Development Team like the Retrospective looks at the
problems that impeded the process and tries to generate
ideas for solutions.
The Development Team may choose to adopt another way of

conducting their meetings, as the Guide outlines it may answer
questions or engage in discussions. If the Scrum Team integrates
a methodology into the Scrum framework, the Development
Team may choose to replace the three questions with structures
more suited to their methodology. If the Scrum Team, for
example, chooses to integrate Kanban, the three questions may
be replaced with a discussion based on the current status of the
Kanban board.
The Development Team or team members often meet

immediately after the Daily Scrum for detailed discussions,
or to adapt, or replan, the rest of the Sprint 's work.
Meetings after the Daily Scrum are not mandatory. This sentence
describes a common occurrence and implicitly gives advice on
how to keep the Daily Scrum within its time-box. During the Daily
Scrum, questions may arise, e.g. , of a technical nature, or larger
issues may be identified.
7 Scrum Events 145
Instead of discussing them within the short time-box of the Daily

Scrum, these topics should be moved into a separate meeting.
This allows for focus in the Daily Scrum and potentially saves
members of the Development Team time, as some discussions
may not be relevant for every member ; therefore, the Guide
specifies that the meetings may be of the entire Development
Team or only of a relevant subset.
The Scrum Master ensures that the Development Team has

the meeting, but the Development Team is responsible for
conducting the Daily Scrum. The Scrum Master teaches the
Development Team to keep the Daily Scrum within the
15-minute time-box.
The Scrum Master is tasked with ensuring the Scrum process

and therefore has to ensure that the Daily Scrum takes place.
-
The Development Team is a self organizing entity within the
Scrum Team and, therefore, responsible for their own meetings.
The Scrum Master may facilitate the Daily Scrum if requested or
needed. However, the ability to conduct their own meetings
properly is a critical benchmark for self -organization and provides
both the team and the Scrum Master with valuable input
regarding the achieved quality of self organization. These inputs
-
may provide a basis for further improvement driven by the
Development Team , as well as further actions to be taken by the
Scrum Master.
The involvement of the Scrum Master in the Daily Scrum is
limited; the Guide refrains from ascribing to them the function of
enforcing the time-box. Instead, the Scrum Master is given the
responsibility to teach the Development Team to follow the
- -
time box. This explicit non use of terminology such as "enforce”
may be interpreted as a guideline to the Scrum Master to not
point out expired time-boxes on the spot, but instead to provide
feedback outside the Daily Scrum about this fact.
7 Scrum Events 146
The Daily Scrum is an internal meeting for the Development

Team. If others are present , the Scrum Master ensures that
they do not disrupt the meeting.
Aside from ensuring the Daily Scrum takes place and teaching
the Development Team to keep it within the time-box, the
responsibility of the Scrum Master is to ensure that others do not
disrupt the meeting. Outsiders may not actively partake in the
Daily Scrum. The Scrum Guide uses the expression "internal
meeting to describe the Daily Scrum, outlining that even if others
attend, the decision on how to conduct the meeting remains with
the Development Team and should be made in a way that the
meeting best serves the needs of the Development Team, not the
others present.
-
An anti pattern for this would be for a manager to attend the Daily
Scrum, leading the Development Team to conduct the Daily
Scrum as a status update meeting instead of as a proper Daily
Scrum, which would weaken the possibility of transparency,
inspection and adaptation.
The Product Owner might be present during the Daily Scrum to

answer urgent questions that may arise, such as clarifying
priorities, but they too do not engage in the internal discussions
of the Development Team, nor should they have any influence on
how the meeting is conducted.
Daily Scrums improve communications, eliminate other

meetings, identify impediments to development for removal,
highlight and promote quick decision-making, and improve
the Development Team s level of knowledge. This is a key
inspect and adapt meeting.
Daily Scrums follow the 6th principle of the Agile Manifestof 141. to
-
which both co creators of Scrum were original signees: The
most efficient and effective method of conveying information to
-
and within a development team is face to- face conversation.".
Therefore, Daily Scrums serve to improve communications and
7 Scrum Events 147
promote quick decision-making. This, in turn, may make other

potential meetings obsolete .
As the Development Team synchronizes every day, it actively

engages in sharing their knowledge on the business matter as
well as potentially on the technical matter.
The inspection ot achieved progress and planning of upcoming

work will create transparency regarding issues that will impede
the development , which are then collected as impediments to be
removed by the Development Team or potentially by the Scrum
Master.
The Daily Scrum is described by the Scrum Guide as a key inspect
and adapt meeting, because
• its regularity allows the timeframe in-between , i.e.,

workdays, to be of the same length, which fosters
necessary transparency for further inspection and possible
adaptations
• using the Daily Scrum to break down the Sprint into micro-
iterations allows constant adjustment of plans via inspection
and adaptation
• having all Development Team members attend the same

meeting creates maximum transparency regarding the
work done by the entire Development Team and therefore
provides a basis for inspection
• the meeting inspects the current progress towards the

Sprint Goal and makes immediate adjustments to the
existing plans, which combined with the high frequency
allows for fast adjustments as new things are learned
7 Scrum Events 148
7.4 Sprint Review
A Sprint Review is held at the end of the Sprint to inspect the

increment and adapt the Product Backlog if needed.
The Sprint Review is, like all Scrum events, aimed at fostering
empirical process control. It does so by providing a dedicated
platform for the inspection of the increment , i.e .. the sum of all
previous increments plus the "Done" work of the current Sprint .
The Scrum Team actively participates in the Review based on the
values of openness and courage . The key stakeholders actively
participate, based on an understanding of Scrum, ensured by the
Scrum Master , and the principle of customer collaboration. These
together provide the transparency for the subsequent insp>ection
outlines in the previous paragraphs. Based on these inspections,
adaptations are made, most notably an alteration to the Product
Backlog.
This inspection allows for potential adaptations to be made to the
Product Backlog, as the functionality of the Increment, as well as
external data, becomes available.
Furthermore, feedback and insights gathered during the Sprint

Review may be used as inputs for the subsequent Sprint
Retrospective.
During the Sprint Review, the Scrum Team and stakeholders

collaborate about what was done in the Sprint
With this sentence , the Scrum Guide defines the foundation of the
Sprint Review :
It is intended as a meeting attended by the Scrum Team as well
as stakeholders. The presence of both is necessary to allow for
maximum transparency, which subsequently allows inspection
and may lead to adaptation.
7 Scrum Events 149
The parties are meant to collaborate. The Cambridge English

Dictionary defines "collaborate" as "to work with someone else for
.
a special purpose:" The parties involved in the meeting are not
merely supposed to inform each other, but to work with each
other throughout the meeting on inspecting what was done in the
Sprint.
The use of done instead of "Done" in this sentence indicates that

the inspection during the Sprint Review deals not only with what
Product Backlog items were ’Done", but with all the work of the
Sprint, whether it resulted in something "Done" or not.
Based on that and any changes to the Product Backlog

during the Sprint, attendees collaborate on the next things
that could be done to optimize value.
This inspection, combined with the inspection of other changes

made to the Product Backlog since the last Review, in which the
Sprint Backlog was inspected together, provides the basis for
adaptation. The subject of adaptation is not specified and thus
leaves room to address any area where adaptations may lead to
improved value delivery. Typical areas include:
• the work of the next Sprint,

• decisions on possible releases of the increment ,
• the collaboration between the Scrum Team and

stakeholders
This is an informal meeting, not a status meeting, and the

presentation of the increment is intended to elicit feedback
and foster collaboration.
With this sentence, the Scrum Guide seeks to distance the Sprint
Review from a conventional project status meeting. Status
meetings, often held weekly or bi-weekly, are meant to update
stakeholders on the status of the project. Oftentimes, this
7 Scrum Events 150
meeting is a very formal event and only involves the stakeholders

and the project manager.
The Sprint Review covers aspects of a status meeting, in that it

updates the stakeholders about the status of the project . It does,
however, define aspects that are untypical for mere status
meetings: The Scrum Guide uses the term "informal meeting" to
describe the Sprint Review, defining the expectation of a meeting
where the titles and status of those involved are secondary to the
collaboration towards the common goal.
The Scrum Master, who is responsible for educating stakeholders

about Scrum, is tasked to motivate the stakeholders to embrace
this format , which, especially for stakeholders from environments
with more conventional management methods and formal status
meetings, may be a significant change . Furthermore, the
Increment is presented ( as opposed to just described) and
serves as the centerpiece for eliciting feedback from the
stakeholders.
A common method to foster this feedback is to let key
stakeholders use the Increment with its added functionality and
gather their immediate thoughts on the user experience.
This is at most a four-hour meeting for one-month Sprints.

For shorter Sprints, the event is usually shorter. The Scrum
Master ensures that the event takes place and that attendees
understand its purpose. The Scrum Master teaches everyone
involved to keep it within the time-box.
These sentences are analogous to the ones describing the time-

box and Scrum Master s involvement in the Sprint Planning /
9
see oaoe 123
7 Scrum Events 151
The Sprint Review includes the following elements:
-
Here, the Scrum Guide provides a non exhaustive list of
characteristics a Sprint Review must follow.
• Attendees include the Scrum Team and key

stakeholders invited by the Product Owner ;
The Scrum Team attends the Sprint Review:
• the Development Team members as the ones who have

built the Increment which will be inspected during the
Sprint Review
• the Product Owner as the one responsible for maximizing

the value of the Development Team s work, the person most
knowledgeable about the business side of the product and
as the main contact person for the stakeholders
• the Scrum Master as member of the Scrum Team, observer

and possible facilitator if needed or requested
The Product Owner is required to invite key stakeholders, who

are supposed to attend the Review. The identification of who
constitutes a key stakeholder is subjective and may be
determined by the Product Owner .
The Scrum Guide uses the term Include” to indicate that
individuals who are neither members of the Scrum Team, nor key
stakeholders, may attend the Sprint Review. This typically
includes other members of the parent organization.
7 Scrum Events 152
• The Product Owner explains what Product Backlog

items have been "Done" and what has not been
’’Done”;
The Product Owner explains what Product Backlog items have

been added to the Sprint Backlog , which of those have been
delivered in accordance with the definition of "Done" and which
ones have not been delivered in a "Done" status. This process
creates greater transparency for the stakeholders regarding the
current status of the overall development of the product .
• The Development Team discusses what went well

during the Sprint , what problems it ran into, and how
those problems were solved;
During the Review, the Development Team creates transparency

towards the Product Owner, the Scrum Master and the present
key stakeholders , how the process of development went
throughout the Sprint.
The Scrum Guide uses the term "discuss”, instead of "describe”,

to highlight that it is not intended as a one-sided update, but a
conversation, in which the stakeholders are supposed to gain a
greater insight into the processes of the Development Team.
Furthermore, the Development Team has the chance to gain an
insight into the expectations and thought processes of the
stakeholders and thus become better at delivering according to
their needs.
In contexts where the Scrum Team develops a product for an
external customer, the key stakeholders may include
representatives from the customer. Under such conditions, this
aspect of the Review creates transparency to help the customer
understand why the service they are paying for takes as long and
costs as much as it does.
7 Scrum Events 153
• The Development Team demonstrates the work that it

has "Done ” and answers questions about the
Increment ;
As the purpose of the Review is to gather feedback about the
newly created increment, a key component of the Review is the
demonstration of all the work that is "Done ", i.e., the increment
that could potentially be released by the Product Owner. The
Scrum Guide explicitly uses the term "demonstrate" rather than
"present”, highlighting that the Development Team is not
supposed to talk about what they did, but either show the
attendees the newly added features in action or even let key
stakeholders try the new functionality themselves.
• The Product Owner discusses the Product Backlog as

it stands. He or she projects likely target and delivery
dates based on progress to date (if needed);
Once again, the Scrum Guide uses the term "discuss" to

emphasize the need for active participation of the Scrum Team
and the key stakeholders. If it is deemed necessary, the Product
Owner uses the discussed status of the Product Backlog as well
as the progress to project potentially crucial dates regarding the
product . The "progress" in this case refers to both the overall
progress manifesting in the current increment , as well as the
speed with which the Development Team has delivered the
functionality in the past. The Scrum Guide describes that these
dates as assumptions by using the term likely". This is a
manifestation of the principle of empiricism, under which
knowledge ( such as a target date) cannot be known beforehand
with absolute certainty.
7 Scrum Events 154
• The entire group collaborates on whatto do next, so

that the Sprint Review provides valuable input to
subsequent Sprint Planning;
The Scrum Team and the key stakeholders work together on what
the next steps should be. As the Scrum Guide does not limit what"
to do next", e.g., by specifying it to ’what the Scrum Team should

do next", it can be assumed that these collaborations may yield
tasks for the stakeholders as well. These results may become
influences for the next Sprint Planning, either
• directly, e.g., through a revised Product Backlog , or
• indirectly, e g., by providing inputs into the Retrospective

from which a changed Definition of Done may be crafted
The overall goal of the Review is to synchronize the key players

of the product development, in order to determine a commonly
agreed upon the further course of action for the next Sprint .
• Review of how the marketplace or potential use of the

product might have changed what is the most valuable
thing to do next ; and,
The Review provides an opportunity to inspect the conditions in

which the product will be used to determine the direction of further
development. The Scrum Guide gives two aspects to consider.
On the one hand, changes to the marketplace, which may include
factors affecting the product, such as general technological trends
and competing products. On the other hand, the potential use of
the product may change, for example, when the key stakeholders
consider expanding the user base to groups not previously using
the product.
7 Scrum Events 155
Both aspects may lead to a reconsideration ot priorities and

subsequently to a different determination of the most valuable
thing to do next. This determination is ultimately taken by the
Product Owner upon the inputs of the attendees of the Sprint
Review.
• Review of the timeline, budget, potential capabilities,

and marketplace for the next anticipated releases of
functionality or capability of the product.
The Review, as a meeting point of the entire Scrum Team and

the key stakeholders , provides a forum to review the plans for the
next releases of Increments In this sentence, the Scrum Guide
describes four aspects to consider and distinguishes between two
potentially different reasons for a release. The Review inspects:
• the timeline, meaning a planned schedule of upcoming

releases
• the budget ,meaning the monetary considerations around

the development of the product
• potential capabilities, referring to what the product could be

able to do in the future
• the marketplace, referring to the overall conditions in which

the product needs to exist and potentially compete
The Scrum Guide distinguishes between "functionality" and

"capability" as reasons for releases. The Cambridge English
Dictionary defines functionality as "any or all of the operations
performed by a piece of equipment or a software program" and
capability as "the ability to do something". The difference
between these may be understood by using an example:
A Scrum Team builds an online shop. At the point of the Review,

the system allows the customer to look at items, add them to a
shopping cart and pay for the selected items. The next release is
7 Scrum Events 156
supposed to include the possibility for the user to maintain a list

of items they are interested in, but don’t want to add to their
shopping cart . This addition is an operation performed by a
computer program and, therefore, a functionality.
In the following Review, the new piece of functionality delivered

by the increment is inspected, found to be acceptable , and the
increment is subsequently released. In the meantime, the
popularity of the online shop has soared and the system begins
,
to show weaknesses handling massive user traffic. It is

determined that in the upcoming release, these weaknesses
need to be fixed. The fix for these may include the use of more
efficient algorithms, migration to better hardware or the
outsourcing of images to an external hoster. None of these
aspects add a new operation that can be performed by the user
and is subsequently no functionality. The fix does however , affect
the ability of the system to serve its intended purpose and is thus
a capability.
The result of the Sprint Review is a revised Product Backlog

that defines the probable Product Backlog items for the next
Sprint. The Product Backlog may also be adjusted overall to
meet new opportunities.
The Sprint Review inspects:
• the sum of already delivered Product Backlog items in the

form of the increment and
• the plans for what will be delivered next in the form of the
Sprint Backlog
Based on these inspections, which include the feedback from

stakeholders and information about the conditions surrounding
the product , the Product Owner defines what will likely be built
next . The Scrum Guide uses the term ' probable', to outline that
these items may change, as alterations to the Product Backlog
7 Scrum Events 157
may be made at any time by the Product Owner, including

throughout the subsequent Sprint Planning ,
The Product Backlog may also be adjusted beyond the scope of

what will likely constitute the upcoming Sprint. The Scrum Guide
provides "new opportunities" as the reason for this, which may
come in the form of new ideas from key stakeholders, ideas
presented and discussed by the Product Owner or reactions to
newly attained information about the marketplace.
7 Scrum Events 158
7.5 Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum

Team to inspect itself and create a plan for improvements to
be enacted during the next Sprint.
The Sprint Retrospective provides a forum for inspection of the

Scrum Team by the Scrum Team. In this sentence, the Scrum
Guide does not specify the categories of what is to be inspected,
and in further sentences, it narrows the scope down only slightly,
to four very broad areas. Therefore, it is left up to the Scrum Team
to determine where inspection might yield the greatest insights.
The inspection conducted during the Sprint Retrospective is done

in order to create possible improvements. A plan for how to
improve in the next Sprint is crafted during the Sprint
Retrospective.
The dedicated timeslot for this meeting, the settings ensured by
the Scrum Master and the participation based on the value of
openness provide the necessary transparency for empirical
process control. On this basis, the Scrum Team conducts an
inspection and develops subsequent (possible) adaptations.
The Sprint Retrospective occurs after the Sprint Review and

prior to the next Sprint Planning. This is at most a three-hour
meeting for one- month Sprints. For shorter Sprints, the event
is usually shorter. The Scrum Master ensures that the event
takes place and that attendants understand its purpose.
These sentences are analogous to the ones describing the time-

box and Scrum Masters involvement in the Sprint Planning 1 .
10
see paoe 123
7 Scrum Events 159
The Scrum Master ensures that the meeting is positive and

productive.
An inspection of the team by the team, which includes inspection

of people and relationships, has the potential to become
destructive. On the other hand, the limited time-box and the wide
scope of what can be inspected bear the risk of losing focus and
running out of time without concrete results. The Scrum Guide
defines the Scrum Master as responsible for the quality of the
meeting. However it does not provide details on how this is to be
,
achieved beyond the broad requirements of positivity and

productivity. This leaves the Scrum Master with a large number of
possible approaches , only limited by the Scrum Values. The
Guide does not even, like at other times, determine that the role
of the Scrum Master in the Sprint Retrospective is that of a
facilitator. Choosing appropriate approaches for the Sprint
Retrospective is highly contextual, as it depends on the product ,
environment and the team involved. Therefore, Scrum as a
framework only defines the broad requirements, leaving the
manner in which these are to be achieved up to the Scrum
Master.
The Scrum Master teaches all to keep it within the time-box .
This sentence is analogous to the one describing the Scrum

Master 's role in the Sprint Planning.1
" see page 124

7 Scrum Events 160
The Scrum Master participates as a peer team member in the

meeting from the accountability over the Scrum process.
The Sprint Retrospective differs from the other events within a

Sprint in that the Scrum Master actively participates as what the
Scrum Guide calls "a peer team member", instead merely
facilitating or ( occasionally) observing to provide feedback . All
events within a Sprint aim at inspecting at least one thing:
• The Planning inspects the Product Backlog and business

objective, for which the Product Owner is accountable, and
the Development Team capacity, for which the Development
Team is accountable.
• The Daily Scrum inspects the Sprint Backlog , for which the
Development Team is accountable
• The Sprint Review inspects the increment , the delivery of
which is in the Development Team s accountability and the

Product Backlog, which is the accountability of the Product
Owner
The Retrospective inspects, among other things, the functionality

of the Scrum process for the Scrum Team . As the Scrum
process, its implementation and understanding are the ,
accountability of the Scrum Master, they need to participate in a

role, where they receive feedback and inspect along with their
peer team members.
The purpose of the Sprint Retrospective is to:
• Inspect how the last Sprint went with regards to people,

relationships, process, and tools;
• Identify and order the major items that went well and
potential improvements; and,
• Create a plan for implementing improvements to the

way the Scrum Team does its work.
7 Scrum Events 161
The points draft a layout for the Sprint Retrospective. The team
inspects how the last Sprint went along the metrics of:
• people, which may be members of the Scrum Team,

stakeholders or others in contact with the team , such as
members of the parent organization
• relationships, especially the ones within the team and those

between the team and the stakeholders
• process referring to the overall product development

,
process within the Scrum framework, as well as the

implementation of Scrum
• tools, which
, for example, may refer to the tools used in the
development work. Product Backlog management or testing
This inspection provides the basis for identifying major items.

Two categories are defined by the Scrum Guide: those items that
represent what went well, and those that represent potential
improvements. Differentiating between things that went well and
potential improvements, rather than between things that went
well and those that did not, outlines that the Sprint Retrospective
should aim for a solution-oriented approach, rather than a
problem-oriented one.
Items of both categories are ordered. How the items are to be
ordered is left to the Scrum Team, similar to how the ordering of
the Product Backlog is left up to the Product Owner.
Finally, the team creates a plan for implementing improvements,
taking what went well and the potential improvements from before,
as well as the outlook of the next Sprint into consideration. The
Scrum Guide emphasizes that these improvements are not limited
to the work of the Development Team but aim at the way the entire
Scrum Team works.
7 Scrum Events 162
The Scrum Master encourages the Scrum Team to improve,

within the Scrum process framework, its development
process and practices to make it more effective and
enjoyable for the next Sprint.
This sentence contains the following crucial components:
• "The Scrum Master encourages the Scrum Team to

improve" - A Scrum Team that does not wish to improve,
will not improve. Empirical process control in Scrum has
the potential to serve to perpetually adapt to the situations
discovered throughout product development This does ,
however, require a desire for improvement by those
applying empirical process control. Therefore, the Scrum
Master has to, in necessary, encourage the Scrum Team to
improve and thus lay the foundation on which improvement
may take place .
• "within the Scrum process framework" - The improvements

made have to be compliant with the Scrum framework, i.e.,
they may not violate the values or break the rules of
Scrum. Should a Scrum Team decide, for example, that the
Product Owner assigns tasks to individual developers, this
would violate the self-organization of the Development
Team. The Scrum Master 's task in this scenario would be
to explain why this would not be a valid improvement
proposal.
• "its development process and practices' The

improvements are focused on the development process
and practices. The word process refers to the way the
Scrum Team organizes itself and the work on a larger scale
within the Scrum framework. The process, for example,
includes events and agreements regarding Product
Backlog refinement , the definition of "Done" or the duration
of a Sprint.
The practices refer to individual aspects within the process ,

such as the use of Story Points for estimations, specific
7 Scrum Events 163
automated testing suites or the way the increment is

demonstrated during the Sprint Review.
• to
" make it more effective and enjoyable" - With this
section, the Scrum Guide provides the reasons for
improvement, which are an increase in both effectiveness
and enjoyability. These two aspects are not portrayed as
contradicting each other or having to be weighed against
each other but are instead listed as equal parameters. This
idea reflects the fifth principle of the Agile Manifesto, which
starts with "Build projects around motivated individuals*.
This idea breaks with traditional process improvements,
which usually are focused exclusively on efficiency
improvements, often disregarding eniovment.M 4l
• "for the next Sprint " - This is used to highlight that

improvements should aim to improve the situation of the
next Sprint. Large ideas that may be developed, whose
implementation takes a longer period of time, should be
broken down into an iterative process, and steps should be
taken immediately. The section also outlines that the
improvements are not permanent fixtures, but experiments
conducted for the duration of one Sprint, after which the
efficacy of the improvement is revisited, and further
adjustments may be made.
During each Sprint Retrospective, the Scrum Team plans

ways to increase product quality by improving work
processes or adapting the definition of "Done '*, if
appropriate and not in conflict with product or organizational
standards.
One goal of the Sprint Retrospective is to determine way to

improve the quantity of what can be delivered. Another goal,
which is described in this sentence, is the improvement of the
quality of the product that is being delivered by the Scrum Team.
The Scrum Guide, therefore, requires the Scrum Team to inspect
7 Scrum Events 164
its development process and the current definition of 'Done' and

make adaptations if deemed appropriate. These adaptations may
not create conflicts with other established standards.
By the end of the Sprint Retrospective , the Scrum Team

should have identified improvements that it will implement
in the next Sprint . Implementing these improvements in the
next Sprint is the adaptation to the inspection of the Scrum
Team itself. Although improvements may be implemented at
any time, the Sprint Retrospective provides a formal
opportunity to focus on inspection and adaptation.
The Sprint Retrospective serves as an opportunity for inspection
of standards and processes. A standard like the Definition of
"Done" may be changed during the Retrospective, which would
be an adaptation following an inspection . Other improvements
are, at the end of the Sprint Retrospective, plans that will be
implemented in the next Sprint . For these improvements, the
Sprint Retrospective provides transparency and an opportunity
for inspection and the upcoming Sprint is the opportunity for the
,
adaptation.
In the last sentence , the Scrum Guide emphasizes two aspects:
• The Sprint Retrospective provides a formal opportunity to

inspect and adapt , meaning a time specifically designated
for these activities. It, therefore, fosters empirical process
control within the Scrum framework.
• Identifying and implementing improvements is not restricted

to the Retrospective, but may be done at any time, including
but not limited to the Daily Scrum.
8 Scrum Artifacts
Scrums artifacts represent work or value to provide

transparency and opportunities for inspection and
adaptation.
The Oxford English Dictionary defines the term artifact as

"something observed in a scientific investigation or experiment
that is not naturally present but occurs as a result of the
preparative or investigative procedure **. This terminology relates
to empirical process control on which Scrum is based.
The Scrum Guide understands the artifacts as a representation

of work or value. The Product Backlog represents potential
product value that may be realized through the Development
Team s work in the future. The Sprint Backlog represents a plan
of the Development Team s work in the Sprint. The Increment is a
representation of the combined value delivered since the first
Sprint.
The purpose of artifacts is defined as supporting empirical
process control by providing transparency and opportunities for
inspection and adaptation. This can be compared to the
sentence [ the] events are specifically designed to enable critical
transparency and inspection" J Scrum and its aspects are set up
to enable and foster empirical process control.
see corresponding quote on page 109

Artifacts defined by Scrum are specifically designed to

maximize transparency of key information so that everybody
has the same understanding of the artifact.
This sentence is a reference to the Scrum Guide's section on

transparency.- In this, it states that "significant aspects of the
process must be visible to those responsible for the outcome",
which mirrors in the present sentence as "transparency of key
information”. Both sections restrict the need for transparency to
information crucial to the success of product development.
The transparency section further states that transparency

"requires those aspects [to] be defined by a common standard so
observers share a common understanding” , which the Guide
claims the artifacts have been "specifically designed" for. The
Scrum Guide claims that the setup has been so that
transparency is maximized. How this is achieved is outlined in
the respective sections below.
2
see the section on transparency on pages 29»
8.1 Product Backlog
The Product Backlog is an ordered list of everything that is

known to be needed in the product .
Two characteristics in this sentence define the Product Backlog:
• It contains "everything that is known to be needed in the

product”. This statement makes two implicit requests:
- The Product Backlog is the artifact in which all

available information on what is needed for the
product is gathered ,Once information becomes
available that relates to the product , it must be
worked into the Product Backlog. This ensures that
there is a single source of truth, allowing for
transparency and a simple inspection of the current
status of plans for the product .
- The Product Backlog collects only information that is

needed for the product . This focus makes it easier for
those inspecting the Product Backlog to understand
the current state of plans for the product and thereby
fosters transparency.
• It is maintained in the form of an ordered list. An ordered

list ensures that there are items that , by some
measurement defined by the Product Owner , more
important and some that are less important. This hierarchy
of importance is represented in the ordering of the list . An
ordered list, usually implemented in the form of important
items at the top. provides an intuitive, easy-to-understand
visualization mechanism for all those inspecting the
Product Backlog. This setup increases the understanding
of the Product Backlog and, therefore , its transparency.
It is the single source of requirements for any changes to be

made to the product.
This sentence underlines the argument implicitly made in the prior

sentence. The Product Backlog serves as a single source of truth
regarding change requirements. Requirements for changes to the
product that are not contained in the Product Backlog are not valid
according to the Scrum Guide.
This artificial restriction forces the Scrum Team, especially the
Product Owner, to ensure that all requirements are placed in the
Product Backlog, where they are transparent.
The Product Owner is responsible for the Product Backlog ,

including its content , availability, and ordering.
The section defining the role of the Product Owner outlines that
the management of the Product Backlog is the responsibility of
the Product Owner. In this sentence, the Scrum Guide underlines
this idea by assigning to the Product Owner the responsibility for
its content and its ordering. Furthermore, it assigns the
responsibility of ensuring the availability, meaning the existence
and the transparency towards others, to the Product Owner.
A Product Backlog is never complete.
In more conventional product development approaches, plans for

the product are developed and written down in some form of a
project plan. The closest equivalent to this in Scrum is the
Product Backlog, which lists requirements that may be turned
into features and capabilities. With this sentence , however , the
Scrum Guide distances the Product Backlog from project plans,
which are finished at some point and then handed over to be
developed. The Product Backlog, however, is at no time
"complete". It reflects the best understanding of what could
deliver value at any given time, and as requirements and market
potential are always changing , so does the Product Backlog.
The earliest development of it lays out the initially known and

best-understood requirements.
The Product Backlog underlies the principles of inspection and

adaptation to evolve For the earliest development , meaning the
first few Sprints of the Scrum Team, it reflects those requirements
that are known at that point and that are best-understood. The
latter serves to limit the risk of developing features that may have
a higher value delivery, but are not understood well yet , due to the
early stages of the product development.
The Product Backlog evolves as the product and the

environment in which it will be used evolves.
The Product Backlog reflects what is currently known about the

product requirements and how the Product Owner ranks these .
The evolution of the product , referring to the ongoing
development and addition of features and capabilities to the
Increments, has effects on the requirements. So does the
environment in which the product will be used, which may
include, among others, the customer, users, marketplace and
general technological trends. The Product Backlog evolves to
reflect these changes and therefore
• the composition, i.e., what items are in it, as well as

• the ordering, i.e., how it reflects maximizing value
evolve along.
The Product Backlog is dynamic; it constantly changes to

identify what the product needs to be appropriate ,
competitive , and useful.
The Product Backlog is described as dynamic, by which the
Scrum Guide differentiates it from conventional project plans,
which are relatively static once the phase of project planning has
been finalized.
Being dynamic is defined as constantly changing , lay which the

Guide expresses that the Product Backlog changes throughout
all stages of the product development. The purpose of these
changes is given as ensuring that it is identified what the product
needs to be:
• appropriate, i.e.. something that can be handed over to a

user
• competitive , i.e.something that can compete with similar

,
products, potentially in an open marketplace
• useful, i.e. , something that adds value for those using the
products
If a product exists, its Product Backlog also exists.
The Product Backlog is an instrument to make the current status

of what is known and the direction the product development is
planned to go transparent . This transparency drives empirical
process control in Scrum and is obligatory as long as the product
exists.
The Product Backlog lists all features, functions,

requirements, enhancements, and fixes that constitute the
changes to be made to the product in future releases.
Items in the Product Backlog reflect what should be changed

about the product in the future. Change in this circumstance
includes both additions and alterations of existing parts of the
product. Using "ail” in this sentence further underlines the idea
that everything known about the (potential ) direction of the
product must be reflected in the Product Backlog to create
transparency. The categories given in this sentence are:
• features: pieces of functionality that serve a purpose for the

user, e.g., being able to store one's score in a mobile game
in the cloud
• functions: in this context refers to the product's ability to

do something , usually within the context of a feature , e g. ,
a login mechanism to connect to the cloud, allowing score
synchronization
• requirements: a need or want, in this case by a stakeholder,

e g. , a user might want to use social media for their login,
while a key stakeholder may want only certain social media
methods to be possible
• enhancements: improvements to the existing features and

functions, e g. , adding a new social media sign- on method
beyond the three already offered
• fixes: repairs to existing features or functions, e.g. . updating

the sign-on methods after an API change lead to an existing
one not working anymore
Product Backlog items have the attributes of a description,

order, estimate, and value.
Scrum makes few prescriptions regarding the Product Backlog

and its items. One of the few mandates the Guide gives though is
reflected in this sentence, listing the (minimum) attributes each
Product Backlog item must have:
• Description: The item is formulated so that it can be

understood by the Development Team. This mandate is in
place to ensure that the Development Team is capable of
turning the item into a piece of an Increment without the
need for extensive clarification to save potential time waste.
The form and scope of the description are left to the
Product Owner and should be agreed with the
Development Team.
• Order : The Product Backlog is an ordered list, outlining the

current assessment of the Product Owner on what items
hold the highest priority. This order is not necessarily the
same as value, as a high-value item that takes a long time
to implement may add less immediate value than a lower

value item that is quickly implemented The exact
,
mechanism of ordering is not prescribed and is left up to

the Product Owner.
• Estimate: Each item is estimated by the Development

Team , in order to estimate during the Sprint Planning how
many and which items can likely be implemented during a
Sprint. The method chosen for estimating is left to the
Scrum Team; typical examples are Story Points and t-shirt
sizes, estimating either effort , complexity or a combination
thereof. The decision on this is up to the Scrum Team.
• Value: Items in the Product Backlog must hold some

measurement of value. This, together with the estimated
provided by the Development Team, allows the Product
Owner to determine what they believe to be the maximum
possible value to be delivered by the work of the
Development Team. Value ultimately reflects the Product
Owner's belief of what constitutes value, as they are the
one taking the - often highly subjective - decision on what
value an item in the Product Backlog is believed to hold.
Product Backlog items often include test descriptions that

wilt prove its completeness when "Done”.
In addition to the four attributes required , the Scrum Guide states

that test descriptions are often included . They are not mandatory
but good practice.
The goal of test descriptions is to give pre-defined criteria to

validate the completeness of item beyond the criteria in the
Definition of "Done". Such test descriptions may be highly
technical, for example, defining minimum standards for
penetration test results on a security-critical feature. They may
also be much simpler, for example, describing that a user on their
phone must be able to fill and submit a form without an error
occurring.
As a product is used and gains value, and the marketplace

provides feedback , the Product Backlog becomes a larger
and more exhaustive list.
Once the product is released to the users, it gains value. The

potential value the Product Owner aimed at maximizing the work
of the Development Team for is realized . The marketplace , in this
case being used symbolically for the sum of users, customers
and other outside stakeholders, provides feedback on the
product, which can be used to determine the future course of the
product. Feedback from the marketplace allows the Product
Owner to explore more possibilities for future development, which
are reflected in the Product Backlog. Thus, it becomes larger and
more exhaustive, meaning that the list that constitutes the
Product Backlog contains more items and that those items
describe a larger number of different paths to explore.
This sentence also refers back to an earlier one. in which it was

indicated that the initial Product Backlog needs only to consist of a
few requirements that are best understood. The Product Backlog
grows with the knowledge about the product ; hence as more is
learned, the Product Backlog will become more exhaustive.
Requirements never stop changing, so a Product Backlog is

a living artifact. Changes in business requirements, market
conditions, or technology may cause changes in the Product
Backlog.
These sentences outline a fundamental understanding of product

development in Scrum. Where in the past product development
projects may have been over at the point when the product was
"finished".
Scrum instead understands the product as a solution to a

complex , adaptive problem consisting of changing requirements.
As requirements change and are understood by the Product
Owner, the Product Backlog changes accordingly, which is why it
is referred to as a living artifact ”, as compared to a static

requirement list as in waterfall projects.
The Scrum Guide gives the following possible causes for

requirement changes and subsequently for changes to the
Product Backlog:
• Business requirements, which refers to the requirements of

the users. As the situation for which the product was
developed changes, so do the requirements for the
product.
For example, a system for managing a logistics center has

to be extended as a new workflow process in the center
has been implemented, which needs to be reflected in the
software.
• Market conditions, which refer to the products standing in

the wider market , covering aspects such as direct
competition, general market trends and the overall
economic situation. As the market changes, so must the
product to remain competitive.
For example, the general trend in the logistics industry may

be moving from custom-built software to more generic
software- as- a-service solutions, forcing the product to be
altered towards more flexible use at different locations and
under different conditions.
• Technology, which refers to the technological possibilities

available and useful. As technology progresses, more and
different features may become possible and even expected
if the product should remain competitive.
For example the wide and availability of NFC readers in
,
mobile phones and, therefore their relatively inexpensive

,
availability may make identifying items in the logistics center

via RFID a new feature that might help the users.
Multiple Scrum Teams often work together on the same

product. One Product Backlog is used to describe the
upcoming work on the product. A Product Backlog attribute
that groups items may then be employed.
Scrum Teams are limited in size to nine Development Team
members. Larger products may justify the need to have more
developers than can fit in one Scrum Team. In those cases , the
Scrum Guide prescribes that multiple Scrum Teams should be
formed, which work on the same product, delivering one
integrated Increment .
To ensure transparency, one Product Backlog is maintained for

one product to act as a single source of truth. Therefore, even
with multiple Scrum Teams, a product will only have one Product
Backlog and subsequently, only one Product Owner responsible
for it. The Product Backlog describes the upcoming work on the
product , regardless of whether one or multiple teams pull work
from it.
In the final sentence, the word "may" is not intended to convey
permission, implying that a grouping attribute is not permitted if
only one Scrum Team works on the product . Rather, the Guide
gives an optional practice of grouping items. Whether such an
attribute is used and by what criteria these groupings are done
remains up to the Product Owner.
Product Backlog refinement is the act of adding detail,

estimates, and order to items in the Product Backlog.
Product Backlog items are defined as having the attributes of

description , order, estimate, value. All of these, except for the
value, are addressed in the Product Backlog refinement:
• Detail is added during the refinement process, referring to

the quality and quantity of the description, as well as other
factors such as testing requirements. A sufficient level of
detail , as determined by the Development Team and the
Product Owner, allows for the item to be understood and

subsequently estimated.
• Estimates are given by the Development Team for each

item. These generally refer to either the complexity of the
item, the effort needed to deliver it , or some combination of
both.
• With the value having been determined by the Product

Owner and the estimate having been provided by the
Development Team, the Product Owner can re-order the
Product Backlog according to their criteria of value
maximization. These may include the ratio of eflort and
value, which becomes apparent throughout the refinement ,
as well as dependencies and synergies between items
revealed throughout the process of adding detail.
The goals of Product Backlog refinement are to:
• foster the understanding of what are possible next steps in

the product development,
• raise transparency towards the Product Owner of the work

required for implementing items and
• raise transparency towards the Development Team about

the content of individual Product Backlog items, ensuring
they are understood and can be implemented in a future
Sprint
This is an ongoing process in which the Product Owner and

the Development Team collaborate on the details of Product
Backlog items.
As the Product Backlog is a living artifact , Product Backlog

refinement is necessary as long as the product is being
developed. The process of adding details involves the Product
Owner and Development Team collaborating, as both have an
active interest in a sufficient level of detail of each item.
The Product Owner needs to ensure that the Development Team

has enough detail to provide a qualified estimate on an item . The
Development Team needs to ensure the level of detail is high
enough to deliver the item into an Increment with as little
dependency on the Product Owner as possible.
Some teams may choose to define the criteria of what constitutes

a sufficient level and refer to it, analogously to the Definition of
"Done”, as the Definition of "Ready”.
During Product Backlog refinement, items are reviewed and

revised.
With this sentence, the Scrum Guide defines Product Backlog
refinement as an iterative process, Items are "reviewed".
meaning they are inspected potentially multiple times, and
adaptations are made as necessary, which the Guide expresses
as items being "revised”. As the conditions around the product
change , items in the backlog may change not only regarding
value but also in terms of necessary details, estimation and
order.
For example, an item has been estimated to have eight story

points: however , due to improved technological capabilities , the
item is re-estimated as only three story points. This makes the
Product Owner re-assess the return on investment of the item
and give it a higher priority in the Product Backlog.
The Scrum Team decides how and when refinement is done.
Product Backlog refinement is not a prescribed Scrum Event ,

noticeable among other things by the lack of capitalization of the
word "refinement" throughout the guide. Unlike the events, which
have defined cadences and sets of requirements, the details of
the refinement are left up to the Scrum Team . Some teams may
choose to integrate regular refinement meetings into their
Sprints: others may spontaneously conduct ad-hoc refinements

when they become necessary.
The format of refinements may vary widely. In some teams, a

refinement may involve all of the Development Team for all
occasion; others may choose to separate into smaller groups and
work on items in those.
Refinement usually consumes no more than 10% of the

capacity of the Development Team.
Here, the Scrum Guide gives a guideline rather than an explicit

rule. Refinement should ideally take up no more than 10% of the
Development Team's capacity. This may, at times, be easy to
achieve, however, especially in early Sprints or in times of rapid
changes, this percentage may be exceeded , Regularly
exceeding 10% can be used as an indicator for the Scrum Team,
that the refinement process needs to be inspected and that
improvements may be necessary.
However, Product Backlog items can be updated at any time

by the Product Owner or at the Product Owner ’s discretion.
The suggested limit of 10% in the previous sentence refers

explicitly only to the Development Team. The Product Backlog
should reflect what is currently known about the potential next
steps for the product. Therefore, the Product Owner, as the
person responsible for the Product Backlog , may at any time
make changes or request others to make changes on their
behalf .
Higher ordered Product Backlog items are usually clearer

and more detailed than lower ordered ones. More precise
estimates are made based on the greater clarity and
increased detail; the lower the order, the less detail.
With these sentences , the Scrum Guides gives a recommendation

rather than a prescriptive rule.
"Higher ordered’ refers to those items that are deemed more
important according to the metrics of the Product Owner.
Refining only higher-ordered items thoroughly ensures that the

details are being added when the item will likely be implemented
soon. Thus , adding details and ensuring clarity relatively late
minimizes the risk of waste. Furthermore, the details added
reflect the knowledge that is still recent and, therefore, less likely
to have been affected by changes, for example, in the
technological environment of the product.
The second sentence can be read in two ways:

On the one hand, it might express that the quality of estimates is
higher when they are based on greater clarity. In this sense, the
Guide would give a cause and effect relationship, pointing out that
a higher degree of clarity and detail leads to better, "more precise",
estimated.
On the other hand, it can be read as recommending an iterative

approach to estimations , i.e. , suggesting that rough estimates are
made for less clear and detailed items and revised, more precise,
estimations are made, when the degree of clarity and detail
increases.
Both readings are valid and mutually complementary. The second

interpretation is supported by a prior sentence, which describes
that items are "reviewed and revised” , as well as the idea that the
Product Backlog should maximize transparency.
Items that are higher ordered are often broken down into smaller
units to allow for more detailed estimates.
PBI Higher priority

Hems, broken
PBI down and more
property refined
PBI
PBI
Lower priority
items, less
broken down
PBI and less refined
Figure 8.1: An illustration of a Product Backlog
Product Backlog items that will occupy the Development

Team for the upcoming Sprint are refined so that any one
item can reasonably be ’’Done” within the Sprint time-box .
Product Backlog items that can be Done ” by the
Development Team within one Sprint are deemed Ready”
for selection in a Sprint Planning. Product Backlog items
usually acquire this degree of transparency through the
above-described refining activities.
While the Scrum Guide leaves the overall state of clarity and level
of details of the Product Backlog items up to the Scrum Team, it
makes a clear requirement for those items that will be pulled into
the next Sprint Backlog. These items must be refined so that they
can be ’’Done" within the next Sprint .
The expression "items that will occupy . .. the upcoming Sprint”

implies at least one of two things to be necessary:
• The team must be aware of what items will ( very likely )

constitute the upcoming Sprint , so that it can ensure those
items to be sufficiently refined.
• Refinement may need to take place during the Sprint

Planning, if the scope of the Development Team's forecast
exceeds the capacity of "Ready" items in the Product
Backlog.
A Product Backlog item should be 'Ready'' before it can be

selected during the Sprint Planning. The exact definition of what
constitutes "Ready" is left to the Scrum Team, especially to the
Development Team, but must , according to the Scrum Guide,
contain the possibility of that item being "Done" within one
Sprint .
While refinements within a Sprint Planning are not explicitly

forbidden and may, at times, be necessary to ensure that a
high- value item can be placed in the Sprint Backlog, the Scrum
Guide clarifies in the third sentence , that this is not the norm.
Rather, the refinement activities described in the earlier
sentences should usually suffice to generate the required levels
of clarity and details, which the Scrum Guide here refers to as the
"degree of transparency".
The Development Team is responsible for all estimates. The

Product Owner may influence the Development Team by
helping it understand and select trade-offs, but the people
who will perform the work make the final estimate.
The Development Team is self-organizing and, therefore, must be

able to estimate the work they will do. The decisions on the
estimates are made only by the Development Team, as they will
later be used along with the capacity forecast for a Sprint to
create a Sprint Backlog, which describes the work of the

self-organizing Development Team.
The Product Owner is involved in the estimation process by

providing a greater degree of transparency of the business
needs. Often multiple different scopes of realizing an item are
possible ; in such cases, the Product Owner may work with the
team to ensure they understand their Product Owner 's priorities
and make trade-offs accordingly.
8.1.1 Monitoring Progress Toward Goals
At any point in time, the total work remaining to reach a goal

can be summed.
The Product Backlog is used to create transparency about the

work on the product and reflects, among other things, the work
that may be done in the future. Goals are expressed in the form
of achieving Product Backlog items. Based on the estimates
provided by the Development Team during Product Backlog
refinements, the total ( estimated) work remaining to reach any
goal can be calculated.
The Product Owner tracks this total work remaining at least

every Sprint Review.
With the Sprint Review, the development work of the Sprint ends.
It is, therefore, possible to assess the progress made by the
Development Team in realizing the Sprint Goal through the
implementation of Product Backlog items. Differentiating between
the items that have been finished and those that have not ( yet)
been finished, allows the Product Owner to determine the total
remaining work left to achieve a specific goal.
The Product Owner compares this amount with work

remaining at previous Sprint Reviews to assess progress
toward completing projected work by the desired time for the
goal. This information is made transparent to all
stakeholders.
The Product Owner compares the remaining work at past Sprint

Reviews with each other. Understanding the progress made
towards a goal throughout the previous Sprints allows for
forecasts to be made how much work the Development Team can
likely achieve in the upcoming Sprints. This measure is then
compared to the remainder of work towards the goal at the

current (or most recent ) Sprint Review.
This process allows the Product Owner to make projections

about when the goal will likely be achieved. This projection is
iteratively adjusted, after every Sprint a new projection is made,
and with more data about previous performance available and
less remaining work each Sprint, the accuracy of the projections
increases over time.
The information is made transparent to all stakeholders, to allow

for potential adjustments to the goal, further feedback, or for the
stakeholders to use it for their own respective planning
processes.
Various projective practices upon trending have been used to

forecast progress, like bum-downs, burn-ups, or cumulative
flows. These have proven useful.
The process conducted by the Product Owner described above

can be aided by tools. The Scrum Guide gives the examples of
• burn-downs, which track and visualize the remaining work

over time towards a goal: they are usually assuming a finite
and known amount of total work; they often contain a trend
line expressing when the entire work should be finished
• burn-ups, which track and visualize the total work done over
time and the total known work necessary for achieving a
goal; with burn-ups, the work necessary can be increased
over time as more is learned; they often contain a trend line
predicting when the total work done will be equal to the total
work necessary to achieve the goal
• cumulative flows, which are commonly used in Kanban,

track and visualize the cumulated number of items in each
development stage (e.g., To-Do, In- Progress, Testing,
Done)
The Scrum Guide does not prescribe either of these tools, does,
however, achkowledges that using them has proven useful in
applying Scrum.
•6m
•1 u u i) M n H t r i i » x a
Figure 8.2: An example of a burn-down chart
Figure 8.3: An example of a burn-up chart

Figure 8.4: An example of a cumulative flow diagram (CFD)
However, these do not replace the importance of empiricism.

In complex environments, what will happen is unknown. Only
what has already happened may be used for forward-looking
decision-making.
The use of burn-downs, burn-ups and cumulative flows can assist

the Product Owner. These tools do not replace empirical process
control, though. The trend line of a burn-up chart, for example, is
only a projection based on what is currently known and assumes
conditions to remain as they have been on average in the past.
Such an assumption cannot be reasonably made in complex
environments, as what will happen in the future cannot be known
by definition.1
Therefore, employing such tools is only useful when combined

with frequent inspection and subsequent adaptation of the key
parameters and if always bearing in mind that the projections
made are only forecasts, which may change, possibly even
significantly, as more is learned.
3
see explanation of complexity in the Cynefm Framework on pages 7«.
8.2 Sprint Backlog
The Sprint Backlog is the set of Product Backlog items

selected for the Sprint, plus a plan for delivering the product
Increment and realizing the Sprint Goal.
The Sprint Planning is created to determine for the upcoming

Sprint:
• What can be delivered?

• How can it be delivered?
The Product Owner and Development Team collaborate on what
items are selected for the upcoming Sprint, determining what will
be delivered. The Development Team also creates a plan for
turning the selected items into an Increment that will fulfill the
Sprint Goal.
These two parameters, the selected items on the one hand, and
the plan on how to turn them into an Increment to realize the Sprint
Goal, are together referred to as the Sprint Backlog.
The Sprint Backlog is a forecast by the Development Team

about what functionality will be in the next Increment and
the work needed to deliver that functionality into a ’ Done ”
Increment.
.
In this sentence, the crucial word is "forecast" As the creation of
a new Increment constitutes a complex problem, there can be no
certainty about what functionality can be added and how the
necessary work should best be done. Therefore, the Sprint
Backlog is not a static artifact but instead serves as a reflection of
the current assumption of the Development Team on what it can
deliver by the end of the Sprint and how this is best done.
The Sprint Backlog makes visible all the work that the
Development Team identifies as necessary to meet the
Sprint Goal.
The purpose of the Development Team s work in the Sprint is to

achieve the Sprint Goal through an Increment, The work
necessary and the scope of what will be done in the Sprint may
change as more is learned. These changes are made through
empirical process control, for which transparency is required.
This transparency is provided by having the work visible, for
which Scrum defines the artifact of the Sprint Backlog.
There is no prescribed format for a Sprint Backlog, and the Guide
only demands that it creates visibility and thus transparency, often
realized in the form of a physical board, sometimes referred to as
a "Scrum Board".
To ensure continuous improvement, it includes at least one

high priority process improvement identified in the previous
Retrospective meeting.
The goal of incremental empirical process control is the
improvement of the process over time. To improve the process of
product development, improvements must not only be
determined ( transparency and inspection) but also implemented
(adaptation). To ensure this implementation takes place, the
Scrum Guide mandates that at least one process improvement
from the last Retrospective should be included in the Sprint
Backlog.
The included improvement is described as having to be "high

priority ", a determination that is left up to the Scrum Team.
The Sprint Backlog is a plan with enough detail that changes

in progress can be understood in the Daily Scrum.
The Sprint Backlog, as an artifact, was created to create
transparency. In order to maximize transparency about the
progress of the work of the Development Team, it must contain a
sufficient amount of details. This allows the Development Team
to inspect their rate of progress and potentially make adaptations
to the Sprint Backlog or their process. The exact level of detail is
not specified, however, it
• must be high enough to allow for inspections during two

consecutive Daily Scrums to generate insights about the
progress , and
• should be low enough to leave the Development Team with

enough flexibility
The Development Team modifies the Sprint Backlog

throughout the Sprint, and the Sprint Backlog emerges
during the Sprint. This emergence occurs as the
Development Team works through the plan and learns more
about the work needed to achieve the Sprint Goal.
The Scrum Guide describes the Product Backlog as a living
artifact , as it always changes in response to changing conditions
around the product and is never 'finalized" or "finished" . An initial
Product Backlog may be created when the product development
begins; however, the Product Owner constantly changes it.
Similarly, the plan within the Sprint Backlog is initially created by
the Development Team but is not static after that point. Changes
are made by the Development Team "throughout the Sprint’,
meaning they only end once the Increment is presented during
the Sprint Review. The Sprint Backlog is described as emerging ,
which the Cambridge Dictionary defines as "growing and
developing".
This "developing" is done by the Development Team to ensure that

the Sprint Backlog continually reflects what is known about the
work needed and make the plan to conduct that work transparent
within the team.
As new work is required, the Development Team adds it to

the Sprint Backlog.
The Development Team may add new work to the Sprint Backlog
as it deems necessary to achieve the Sprint Goal, The right to
add work to the Sprint Backlog is reserved exclusively for the
Development Team, as it is self -organizing.
This "work", however, does not refer to the Product Backlog items
contained in the Sprint Backlog, but only to the work planned for
delivering them. Changes to Product Backlog items in the Sprint
are negotiated with the Product Owner.
As work is performed or completed, the estimated remaining

work is updated.
The Sprint Backlog is a plan for achieving a Sprint Goal. To be

able to understand the progress towards that goal and to make
changes if necessary, the Sprint Backlog must create
transparency on how much work is left in the Sprint. Therefore,
the Scrum Guide prescribes that upon finished work, the
-
remaining work in the Sprint Backlog must be re estimated .
-
In practice, this is often done in the form of a burn down chart ,
which displays the amount of work done and the amount of work
still left over a time axis.4
* for an example of a burn-down chart, see page 185

When elements of the plan are deemed unnecessary, they are

removed.
-
The Development Team is self organizing and aims for efficiency.
Therefore, it is free to remove work from its Sprint Backlog. The
term elements of the plan" does not refer to Product Backlog
items, as their removal must be coordinated with the Product
Owner, but to parts of the plan on implementing the Product
Backlog items to realize the Sprint Goal.
Only the Development Team can change its Sprint Backlog

during a Sprint.
-
The Development Team is self organizing, meaning it organizes
how it does its own work. As the Sprint Backlog is an artifact
that represents the best knowledge and plans of the Development
Team regarding their work, changes to the Sprint Backlog may
only be made by the Development Team.
There may, however, be a need for the Development Team to

coordinate with the Product Owner on addition or removal of
Product Backlog items to or from the Sprint Backlog.
The Sprint Backlog is a highly visible , real-time picture of

the work that the Development Team plans to accomplish
during the Sprint, and it belongs solely to the Development
Team.
The Sprint Backlog as an artifact is created to maximize

transparency about the planned work of the Development Team.
Therefore, the Scrum Guide defines two characteristics it must
fulfill:
The Sprint Backlog must be highly visible, as this allows for
transparency. While not required by the Scrum Guide many ,
teams choose to maintain their Sprint Backlog as a physical

board, modeled after Kanban boards and sometimes referred to

as "Scrum Boards*.
Furthermore, the Sprint Backlog must reflect changes in real- time,
as this ensures that decisions based on the Sprint Backlog always
reflect the most current knowledge on the work in the Sprint.
The final part of the sentences outlines that the Sprint Backlog
"belongs solely to the Development Team", which emphasizes
again the autonomy the Development Team has regarding all
changes to it but also ascribes the responsibility for maintaining it
to the Development Team.
Finally, the section may be understood as giving the Development

Team the right to choose how and to which degree they wish to
make their Sprint Backlog transparency to persons who are not
part of the Development Team.
Example of a Scrum Task Board

Product Sprint In Peer In Done Blocked
Backlog Progress Review Test
Figure 8.5: An example of a Scrum Board, with the big cards

representing Product Backlog items (e.g. in the format
of stories ) and the smaller representing decomposed,
smaller units of work (e.g. in the format of tasks)
8.2.1 Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in

the Sprint Backlog can be summed.
The Sprint Backlog is used to create transparency about the work

in the Sprint and reflects, among other things, the remaining
work. This count is updated as work is performed or completed.5
Therefore, it is possible to add up the estimates of how long the
remaining work will take.
The Development Team tracks this total work remaining at

least for every Daily Scrum to project the likelihood of
achieving the Sprint Goal.
The Development Team is supposed to use this sum and
compare it to the available capacity. This inspection should be
done frequently, at least during every Daily Scrum. Comparing
the projection of how much more work is necessary with the
available capacity of the Development Team until the end of the
Sprint allows the Development Team to make a statement on the
likelihood of the Sprint Goal being achieved if key parameters
remain as they are.
If the projection of remaining work is significantly smaller than the

available capacity, the Sprint Goal will likely be achieved. If the two
are of a similar size, the Development Team should inspect the two
regularly and carefully to ensure that the Sprint Goal can be met .
If the available capacity is significantly lower than the projections ,
the Development Team has to adapt by making adjustments to
their plans, their process or - if deemed necessary - to the items
in the Sprint Backlog in coordination with the Product Owner .
5
for more detail see page 190
By tracking the remaining work throughout the Sprint, the

Development Team can manage its progress.
Continually tracking the remaining work, especially as compared

to projections about work being done, creates transparency
about the results generated by the Development Team.
This transparency can be used to inspect the development
process and, if necessary, make adaptations. This is what the
Guide refers to when speaking of managing progress.
8.3 Increment
The Increment is the sum of all the Product Backlog items

completed during a Sprint and the value of the increments of
all previous Sprints.
In this sentence, the Scrum Guide differentiates two spelling of the

term, one using a leading capital letter , implying a proper noun,
while the other is written with a leading lowercase letter, implying
a common noun.
An "increment ”, written in lowercase, describes the sum of Product
Backlog items "Done” during a Sprint and the value of previous
.
increments. It is therefore, the total sum of all the work of all the
Sprints. This spelling indicates the descriptive term, i.e.. the result
of an incremental process.
The "Increment ”, written with a capital T, refers to the artifact

and exclusively to the increment of the current Sprint. Thus,
every Increment is an increment, but not every increment is the
Increment.
The Increment is not only the result of the work of the current
Sprint, but also explicitly includes the results of previous Sprints.
Thus, an inspection of the Increment always refers to the
inspection of the sum of all work of the entire product as it is right
now. This creates transparency about the entire product .
including how the most recent work functions together with
previous work.
At the end of a Sprint, the new Increment must be Done,*'

which means it must be in useable condition and meet the
Scrum Team s definition of ’ Done '.
The purpose of a Sprint is to deliver an lncrement . 6 This
Increment is inspected during the Sprint Review and must be
potentially releasable if the Product Owner decides to release it.
Therefore, it must adhere to the quality standards defined in the
definition of *Done".
An increment is a body of inspectable, done work that

supports empiricism at the end of the Sprint. The increment
is a step toward a vision or goal.
An increment (note the lowercase Y) is understood by the Scrum
Guide as work in the direction of a vision or goal. This implies the
need for the product being developed to have a vision or goal that
provides the direction for product development. The work that is
done must be inspectable at the end of the Sprint, thus allowing for
empirical process control to be usable. The specific requirements
of what inspectable means is contextual.
The increment must be in useable condition regardless of

whether the Product Owner decides to release it.
The goal of the Scrum Team is to produce an increment at least

by the end of every iteration that could be potentially shippable.
Usable in this sentence refers to the ability of the increment to
be used by the end-users, which is one criterion for reusability.
Ensuring the increment is always in usable condition allows there
to always be a potentially shippable increment that the Product
Owner could release when they deem it necessary.
6
see section The Sprint on page 112
9 Artifact Transparency
Scrum relies on transparency.

The foundation of Scrum is empirical process control.1_The Scrum
Events and the roles within a Scrum Team rely on transparency
to execute an inspection and possible subsequent adaptation to
adjust to new challenges in complex environments and improve
the product development over time.
Decisions to optimize value and control risk are made based

on the perceived state of the artifacts.
The purpose of Scrum is to allow delivery of value while managing
risk . This can most notably be seen in the role of the Product
Owner as a maximizer of the value of the Development Team's
work and Scrum’s use of Sprints to limit the risk of waste to at
most a month.
The artifacts ( the Product Backlog. Sprint Backlog and Increment )

are created to reflect what is currently known about the product , its
requirements and the immediate next steps in its development as
well as possible. They have to do this in a manner that is visible to
those responsible for the respective outcomes and that everyone
inspecting the artifacts has the same understanding of what they
are seeing . The artifacts have to be transparent.
see the section on empirical process control on pages 2411.

The artifacts further serve as the basis on which decisions are

made. For example:
• The Product Backlog provides the Scrum Team with an

understanding of which next steps have priority for the
upcoming Sprint and is the source from which items are
pulled into the Sprint Backlog.
• The Sprint Backlog allows the Development Team to

inspect their progress towards the Sprint Goal and make
adjustments to their plans if necessary.
• The Increment provides the Scrum Team and its

stakeholders an understanding of the current functionality
and capability of the product , which in turn allows for
common decisions to be made on the next steps.
To the extent that transparency is complete, these decisions

have a sound basis. To the extent that the artifacts are
incompletely transparent , these decisions can be flawed,
value may diminish and risk may increase.
The best decisions can be made if the artifacts are completely

transparent. The decisions made based on completely
transparent artifacts may still be wrong, as in complex
environments, even transparency does not create certainty ;
however, they are more likely to be correct and more likely to limit
risk and maximize value. This is what the Guide refers to as
decisions having "a sound basis".
If artifacts are, however, not transparent , decisions will have a
less sound basis. The decisions made on this basis may still be
correct: however, the likelihood of flawed decisions is increased,
and subsequently, the risk may increase and value be
diminished.
The Scrum Guide uses the expression ’[to] the extended" for
both cases, implying that transparency is not a boolean
parameter, that is either fully achieved or not achieved at all, but
rather a parameter that can be more or less achieved for each of

the artifacts. In the following sentences, the Scrum Guide
explains the process of maximizing transparency.
The Scrum Master must work with the Product Owner,

Development Team, and other involved parties to
understand if the artifacts are completely transparent.
The Scrum Master is tasked with ensuring the transparency of

the artifacts. To do this, they have to work with those using the
artifacts to gam a collective understanding of whether or not the
artifacts are ’completely transparent” and if not to what extent they
are not.
There are practices for coping with incomplete

transparency ; the Scrum Master must help everyone apply
the most appropriate practices in the absence of complete
transparency.
If the inspection reveals a lack of transparency, the Scrum Master

must work towards increasing transparency. However, as this
may be a lengthy process, the Scrum Guide outlines that
mitigations for the time until complete transparency is achieved
should be used. The Scrum Master is responsible for everyone
understanding how best to make decisions and apply the best
practices in the absence of complete transparency.
This approach allows the Scrum Team to deliver the highest
value it can. while at the same time adjusting their artifacts.
A Scrum Master can detect incomplete transparency by

inspecting the artifacts, sensing patterns, listening closely
to what is being said, and detecting differences between
expected and real results.
In this sentence, the Scrum Guide provides broad pointers to the
Scrum Master for how to determine whether or not transparency
is complete. The advice given is:
• inspecting the artifacts: this may reveal more obvious

impediments to transparency, such as the missing visibility
of the Product Backlog to the stakeholders
• sensing patterns: this refers especially to patterns of

behavior, such as Development Team members hiding
technical debt from the Product Owner, thus lowering the
transparency of the Increment
• listening closely to what is being said: attentiveness to

details in conversation may reveal implied statements on
the lack of transparency; for example: a stakeholder
criticizing the Product Owner during the Sprint Review for
not providing a clear picture of the next steps may be an
indicator that they do not have a good understanding of the
Product Backlog
• detecting differences between expected and real results:

inspecting the delta between what is expected to happen
and what actually hap>pens can provide indications of a
lack of transparency; if the differences are minimal,
transparency is likely achieved , while large, repeated
differences may be due to a lack of common
understanding, i.e., transparency
The Scrum Master ’s job is to work with the Scrum Team and
the organization to increase the transparency of the artifacts.
This work usually involves learning, convincing, and change.
Transparency doesn’t occur overnight, but is a path.
The Scrum Master is responsible for ensuring transparency of the

artifacts and increasing it if it is found to be improvable. This work
is highly contextual, but the Scrum Guide outlines that it must be
done in collaboration with the Scrum Team and the organization.
-
As the Scrum Master is a servant leader1 . their approach is not
to force through what they believe to be transparency, but rather
to ensure understanding in others of why transparency plays a
crucial role in empirical process control and thus in the product
development.
Therefore, the Scrum Guide outlines that this may be a lengthy
process, which usually involves learning on the part of the Scrum
Team and the organization, convincing done by the Scrum
Master through good arguments rather than hierarchical authority
and change to the way this is currently done .
2
see the definition of a servant-leader on pages 84 T
9.1 Definition of ’’Done”
When a Product Backlog item or an Increment is described

as ’Done”, everyone must understand what " Done ” means.
Although this may vary significantly per Scrum Team,
members must have a shared understanding of what it
means for work to be complete, to ensure transparency. This
is the definition of Done " for the Scrum Team and is used to
*
assess when work is complete on the product Increment.
The definition of "Done" is given as an example for the

requirement of common standards to achieve transparency
earlier in the GukJe.3aln order for empirical process control to
work, those doing the inspection must have a common
understanding of what is being observed. One factor for this is a
shared understanding of when a Product Backlog item or an
Increment is "Done".
The Guide defines no requirement regarding the contents of the

definition of Done", as the specific requirements are highly
contextual and may differ significantly even between Scrum
Teams in the same field. It does, however, mandate that
definition of "Done" must be transparent for those involved, to
allow everyone to have the same understanding of what "Done"
entails.
The definition of "Done" is used for common understanding and
as a required benchmark for whether a piece of work towards an
Increment is completed. Thereby, the definition of "Done" acts
as a de facto minimal quality standard, as all work done by the
Development Team must adhere to it.
3
see page Jfl
The same definition guides the Development Team in

knowing how many Product Backlog items it can select
during a Sprint Planning.
The definition of "Done "

is an input into the Sprint Planning.
Understanding the requirements of what it means to deliver a
'’
Done'’ Product Backlog item towards a "Done” Increment
provides the Development Team with guidance on how much it
believes to be able to implement during the Sprint .
If. for example, the definition of "Done" is very tight and includes
several automated testing levels, implementing a new Product
Backlog item may include writing automated tests. This creates
additional effort, which needs to be factored in when forecasting
how many Product Backlog items can likely be implemented in a
Sprint.
The purpose of each Sprint is to deliver Increments of

potentially releasable functionality that adhere to the Scrum
Team s current definition of ’ Done ”.
The purpose of Scrum Teams is iteratively to deliver product

Increments to maximize the opportunities for feedback . 4 These
have to be potentially releasable to ensure a potentially useful
version is always available "
The iteration of Scrum is the Sprint; therefore, the purpose of a

Sprint is the delivery of an Increment. According to this sentence
of the Scrum Guide, this Increment has to adhere to the current
definition of "Done", ensuring that the Increment adheres to the
current quality standards and is "Done" in a way that all involved
have the same understanding.
4
see pages 59 ff.
'
see page ft}
Development Teams deliver an Increment of product

functionality every Sprint. This Increment is useable, so a
Product Owner may choose to immediately release it.
These sentences further emphasize that a Sprint s purpose is the

delivery of an Increment, specifically one with added product
functionality. As this Increment has to adhere to the definition of
"Done", which includes everything the Development Team deems
necessary for Product Backlog items and the Increment to be

releasable, the Product Owner may at their discretion decide to
release it . This includes the possibility of releases before the end
of a Sprint.
If the definition of ’’Done” for an increment is part of the

conventions, standards or guidelines of the development
organization, all Scrum Teams must follow it as a minimum.
If 'Done for an increment is not a convention of the
development organization, the Development Team of the
Scrum Team must define a definition of ' Done ' appropriate
for the product.
When developing products, the development organization may

have its own definitions for what is acceptable to be released.
The development organization is the parent organization within
which the development takes place, or a subset thereof. If such
definitions exist, these become the minimum definition of “Done”.
The Development Team may choose to add their own
requirements for "Done” on top of it, however, it may not remove
any of the external requirements from their definition of "Done ".
If there are no definitions from the development organization, the

Development Team is responsible for creating its own definition
of "Done". The Guide again gives no prescription of what it must
entail and merely points out that it must be " appropriate for the
product" .
If there are multiple Scrum Teams working on the system or

product release , the Development Teams on all the Scrum
Teams must mutually define the definition of " Done ".
If the work of multiple Scrum Teams affects the same ( potential)

release, their definitions of "Done" cannot be contradicting each
.
other Therefore, the respective Development Teams need to
" mutually define the definition of "Done ”" , which means they
have to agree on a minimum common definition of "Done" shared
across all teams. This minimum definition must be followed,
cannot be changed unilaterally by any team and no further rules
contradicting it may be made. The individual Development Teams
are, however, allowed to define stricter requirements for their own
work.
Each Increment is additive to all prior Increments and

thoroughly tested, ensuring that all Increments work
together.
With this sentence, the Scrum Guide requires that the definition
of "Done" must ensure that additions to the previous Increment to
form the new Increment must be working together and that this
.
must be thoroughly tested How this is ensured is left to the
development organization or the Development Team.
As Scrum Teams mature, it is expected that their definitions

of Done " will expand to include more stringent criteria for
higher quality.
The Guide suggests that the quality of the work delivered by the
Scrum Teams, particularly by the Development Teams, should
increase over time. Its definition of "Done reflects the quality
standard of a team". Therefore, over time the definition of "Done”
should become stricter and aiming at a higher quality Increment.
This may include a wide variety of issues, for example, tighter
User Experience requirements, more thorough security testing or

a higher level of technical documentation.
New definitions, as used, may uncover work to be done in

previously Done ’ increments.
*
When adding new criteria to a definition of "Done” and applying

the new complete definition of "Done”, it may be revealed that
existing parts of the product do not comply with the definition of
"Done". These parts, delivered in previous Increments, adhered
to the definition of "Done valid at the time, but fail to comply with
the newer, usually tighter, definition of "Done”.
The work revealed to be un-"Done" must then be completed to
adhere to the current standard in order to have an Increment that
complies with the most recent requirements.
Any one product or system should have a definition of

is a standard for any work done on it.
’’Done ” that
The use of the expression "any one" rather than simply "any"
implies that this sentence expresses the idea that each product
or system should have its own, separate definition of “Done ’.
Should a Scrum Team contribute work to another product or
system than their own, the definition of that product or system
would be applicable, ensuring that any work done for it fulfills the
minimum standards laid out in its definition of "Done”.
10 Endnotes 207
10 Endnotes
Scrum is free and offered in this Guide.

Scrum as a framework is openly available and shared in the
Scrum Guide, which is freely accessible under a Creative
Commons license.
Scrum's roles, events, artifacts, and rules are immutable and

although implementing only parts of Scrum is possible, the
result is not Scrum. Scrum exists only in its entirety and
functions well as a container for other techniques,
methodologies, and practices.
The Scrum Guide defines the roles, events, artifacts and rules of
Scrum. All of them are carefully attuned to maximize the
possibilities of empirical process control. Creating only partial
implementations leads to loss of crucial aspects in this balance
and is, therefore, not Scrum.
Example: A team is applying Scrum, but leaves out the Sprint
Retrospectives, as they are seen as taking too much time.
Through this, the team loses a key opportunity tor inspection and
subsequent adaptation of its development process. It is thereby
foregoing a possibility for improvements. This setup of "Scrum
without a Sprint Retrospective" is not Scrum.
Scrum is conceptualized as a container, within which other
techniques, methodologies , and practices may be applied as long
as they don't contradict the Scrum Guide's ideas. These may
10 Endnotes 208
further improve collaboration and coordination within the teams ,

lead to fast feedback cycles or raise the quality and speed of
product development .
Example: Kanban principles can be applied within a Scrum

environment. A Scrum Team may use a Kanban Board to track
its Sprint Backlog , limit its work in progress ( WIP) and use cycle
times to make predictions about future delivery capacity.
A Development Team may employ test-driven development
( TDD), which leads to higher product quality, lower technical
debt , and a higher level of transparency about the current state of
the Increment.
11 Acknolwedgements 209
11 Acknolwedgements
The following lines speak for themselves and need no

explanation. Despite this, they are reproduced here out of
respect for individuals and organizations' contributions in the
creation of Scrum.
11.1 People
Of the thousands of people who have contributed to Scrum,

we should single out those who were instrumental at the
start: Jeff Sutherland worked with Jeff McKenna and John
Scumniotales, and Ken Schwaber worked with Mike Smith
and Chris Martin, and all of them worked together. Many
others contributed in the ensuing years and without their
help Scrum would not be refined as it is today.
11.2 History
Ken Schwaber and Jeff Sutherland worked on Scrum until

1995, when they co-presented Scrum at the OOPSLA
Conference in 1995. This presentation essentially
documented the learning that Ken and Jeff gained over the
previous few years, and made public the first formal
definition of Scrum.
11 Acknowledgements 210
The history of Scrum is described elsewhere. To honor the

first places where it was tried and refined, we recognize
Individual, Inc., Newspage, Fidelity Investments, and IDX
(now GE Health).
The Scrum Guide documents Scrum as developed, evolved,

and sustained for 20-plus years by Jeff Sutherland and Ken
Schwaber. Other sources provide you with patterns,
processes, and insights that complement the Scrum
framework. These may increase productivity, value,
creativity, and satisfaction with the results.
License of the Scrum Guide 211
License of the Scrum Guide
© 2018 Ken Schwaber and Jeff Sutherland.

Offered for license under the Attribution Share- Alike license
of Creative Commons, accessible at
http:/ /creativecommons.orq/licenses/bv-sa74.0/leqalcode
and also described in summary form at
http:/ /creativecommons.orq , licenses/by-sa/ 4.0/.
By utilizing this Scrum Guide you acknowledge and agree
that you have read and agree to be bound by the terms of the
Attribution ShareAlike license of Creative Commons.
The full Scrum Guide can be found in a web version and as a PDF
in English and various other languages at:
https:// www.scrumauides.orQ/
Postface 212
Postface
Thank you for reading this book. I hope it has granted you a
deeper insight into and understanding of the Scrum framework.
If you have made it this far, you will undoubtedly understand that
no product is ever finished. Rather , this book is to be understood
as a hopefully high- value first increment released into the market
for feedback . Should you have found anything in the book difficult
to understand , if you believe I have made any factual error, or if you
have found spelling or grammar errors please have the courage
,
to utilize your openness with me and do let me know.
For these and other feedback or questions around Scrum, feel free
to reach out to me under :
scrumauide@ moritz-knueooel.eu.
Bibliography 213
Bibliography
( 1J Cynthia Kurtz and David Snowden. The new dynamics at strategy . Sense-making tn
a complex and compfccaled world. 2003. URL
- brooka/atot ybi 2/k.ur tz.pdf.
[2] IntornvMonsiechnkuentrum Bund. V-Modell XT Bund - Das Referee/ mode fur

Systernemwckkjngsprofekte in dec Bundesverwaltung ( German). 2009. URL
*
htto://download .gab. bund.de/BundeaCIO/V » Modeli XT _ Bund/ _
V«?tode l » XT»Sund«2.Q» GeSdS.
>
> .&dt.
[3] Jeffrey Viclor Sutherland and Ken Schwaber Business object design and implementation :
OOPSLA 95 workshop proceedings University of Mchigan. 1995. ISBN 9783540760962
[4] Ken Schwaber Agile Protect Management with Scrum Microsoft Press. 2015 ISBN
9780735619937
.
(51 Scrum ( software development ) 2020 URL
Scruafsottwaredevelocment >.
(6) Roger Sermon. Modem Phdosophy: An Introduction and Survey . Penguin Grot
* . 2000 ISBN
.
)
9780140249071.
(7J Norman Kecth. Project Retrospectrves A Handbook tor Team Renew. Dorset House
Publishing Co Inc. 2001. ISBN 9780932633446.
[8] Ken Schwaber and Jeffrey Vdor Sutherland Software in 30 Days : How Agie Managers Beat
the Odds. Delight Ttmr Customers and Leave Competitors m the Dust Wiley. 2012. ISBN
,
9781118206669
(91 Robert K Greenleef Servant leadership. 2016.
-
what ia»servant*leader ah ip/ .
[10| Ken Schwaber. Se -organizaton and our belief that we are in charge. 2012. URL
*
//bit.ly/2CcjlL2.
(11J Cyril N. Parkinson Partason's law The Economist. 19 November 1955. 1955
( 121 Cyril N. Parkinson. Parkmson's Law. or The Pursuit of Progress. Penguin Books Lid. 2002.
ISBN 9780141186856
( 13] Jeffrey Viclor Sutherland Satan: The art of doing twice the work in had the tme Random
.
House. 2015. ISBN 9781847941107.
[14] Manifesto for agile software development. 2001. URL

^ £ao^ « ^ ^
httpf / e nan ea 3
ot
^
List of Figures 214
List of Figures
1.1 Image from the cover of the November 2017

Scrum Guide. to be found at
https :/ /www . scrumquides .ora/download.html . . . 4
2.1 Published under CC BY 3.0, all relevant information

can be found under https://w wiki/UnZ 7
8.1 Illustration by Moritz Knuppel, published under

license CCO 180
8.2 Published under CCO, all relevant information can
be found under https://w.wiki/Unc 185
8.3 Published under CC BY- SA 4.0, all relevant
information can be found under https //w wiki/WtC . 185
information can be found under httpsV/w. wiki/WtH , 186
information can be found under https:/ /w. wiki/Wsi . 192

Moritz Knueppel - The Scrum Guide Explained A Comprehensive Analysis of The Scrum Guide (2020)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Moritz Knueppel - The Scrum Guide Explained A Comprehensive Analysis of The Scrum Guide (2020)

Uploaded by

Copyright:

Available Formats

The Scrum Guide Explained

A Comprehensive Analysis of the Scrum Guide

Dr. Peter Stormer

Self -published in September 2020

Copyright © Moritz Knueppel 2020

1 Purpose of the Scrum Guide 1

6 The Scrum Team 53

7 Scrum Events 1QZ

License of the Scrum Guide 211

List of Figures 214

Scrum is simple to understand but difficult to master.

This paraphrased statement from the Scrum Guide holds a special

As I moved around different companies and got to observe

This book represents my attempt to explore the Scrum Guide

To explain the Scrum Guide, I am taking apart the entire Scrum

I sincerely hope this book can be of help to anybody who is

1 Purpose of the Scrum

Scrum is a framework for developing, delivering, and

The first sentence of the Scrum Guide is only 11 words long;

2. The trifold of " developing , delivering , and sustaining"

3. When speaking of " complex products " , the Scrum guide

a) There are situations in which using Scrum is

This Guide contains the definition of Scrum. This definition

Unlike some other project management methodologies or

The Scrum Guide is not descriptive in nature, meaning it does

' see explanation ol complexity in the Cynefin Framework on pages 7H,

that by definition, what is written in the Scrum Guide and it alone

Ken Schwaber and Jeff Sutherland developed Scrum; the

Some approaches to product development gradually emerged as

Ken Schwaber and Jeff Sutherland. Both developed approaches

Figure 1.1; Jeff Sutherland ( left ) and Ken Schwaber (right )

In 2002 , Schwaber, together with others, founded the Scrum

In 2009, he left over differences - mainly regarding the

These two sentences in the Scrum Guide can be seen as a

Scrum (n): A framework within which people can address

This one sentence definition contains a highly distilled essence of

2. It clarifies the correct way of spelling Scrum, which is often

" A framework within which... * once again indicates that Scrum

does not provide a definitive methodology, but a set of definitions

The choice of "address complex [. .. ] problems" can be explained

problems into four primary clusters: simple, complicated ,

1. Simple problems are ones with "known knowns”. in which

2. Complicated problems are ones where "known unknowns"

to that for simple problems but replaces "categorize" with

3. Complex problems are ones in which the "unknown

4. Chaotic problems are ones where any knowledge-based

In the context of product development , those categories imply the

2. Complicated; analyze the problem beforehand, choose the

3. Complex: run an experiment, evaluate the result and

4. Chaotic: do anything, evaluate the result, based on that

1 . "probe " , which aims at generating data, or in other words,

2. "sense", which describes the inspection of the generated

3. ’respond", which means to take appropriate action based on

By " address [. . . ] adaptive problems" the Scrum Guide claims

see the section on empirical process control on pages 24H

progress in developing the solution to the problem. This is the

Using the adjective "productively " highlights Scrum's focus on

The adjective ”creatively " outlines the necessary approach to

problems - and complex adaptive in particular - require trying

Finishing the sentence with " delivering products of the highest

To illustrate: A Sprint spent on cleaning up technical debt (often

1. Characterizing Scrum as "lightweight refers to two aspects:

a) The number of prescriptive rules and definitions