Session 12 - 13 - Agile - Scrum in A Nutshell 92-227

AGILE & Scrum
IN A NUTSHELL
1
Table Of Content
Section 1 Introduction Page 3
Section 2 The Agile manifesto and the birth of Scrum Page 6
Section 3 Overview of the Scrum Framework Page 11
Section 4 Scrum Theory Page 23
Section 5 Scrum Values Page 28
Section 6 Scrum Artifacts Page 45
Section 7 Scrum Events Page 103
Section 8 The Scrum Team and accountabilities Page 143
Section 9 Scaling Scrum Page 178
Section 10 Terms and tools used in Agile and Scrum projects Page 195
Section 11 Frequently asked Scrum questions & Scrum myths Page 209
2
SESSION 1
INTRODUCTION
3
CONTEXT
VUCA:
Volatility, Uncertainty,
Complexity & Ambiguity
4
CONTEXT
TEAM STAKEHOLDERS
5
SESSION 2
AGILE MANIFESTO AND
THE BIRTH OF Scrum
6
Agile Manifesto
In the 1990s there was a growing movement throughout the software development world. Teams were
growing tired of the traditional way of building software using a waterfall process, where the team first
defines strict requirements, then draws up a complete design, and builds out all of the software architecture on
paper before the code is written.
In 2001, a group of seventeen open-minded people got together. The group included thought leaders from all
across the new “lightweight” world, including the creators of Scrum and XP. They weren’t sure exactly what
would come out of the meeting, but there was a strong sense that these new lightweight methods for
building software had something in common. They wanted to figure out if they were right, and maybe find a
way to write it down.
7
Agile Manifesto
The values and ideas contained in this manifesto were

derived from a larger range of software development
frameworks including Scrum, KanBan, Extreme
Programming and many others. So this is why Scrum is
considered an agile framework and associated with the
agile movement.
8
Agile Manifesto
There’s no single “best” way to build software. The Agile Manifesto is effective because it lays out
values that help teams get into an agile mindset. When everyone on the team genuinely incorporates
these values into the way they think, it actually helps them build better software. 9
The birth of Scrum
Ken Schwaber and Jeff Sutherland first co-presented Scrum at the OOPSLA Conference in 1995. It
essentially documented the learning that Ken and Jeff gained over the previous few years and made
public the first formal definition of Scrum.
10
SESSION 3
OVERVIEW OF THE Scrum
FRAMEWORK
11
Overview of the Scrum Framework
Describes a framework for dealing with complex

work often encountered when developing new
products.
With constantly changing market conditions and

technology improvements, giving a high level of
uncertainty.
It is impossible to predict from the beginning how a

product should be developed.
12
Case: Spending six months to create a detailed plan with requirements and following that plan for
another one or two years until the final product is ready to be released does not work anymore.
So in these conditions, working with time boxes and quick adaptation is mandatory to ensure that a
product does not fail.
Scrum is a framework that imposes time box's feedback loops and encourages small increments while
overall trying to deal with uncertainty.
Timebox Adaptation
13
There is a bit of all the steps required to develop a

product, this may include:
- Gathering requirements and understanding
what customers want
- Planning
- Design and Architecture
- Development
- Testing
- Documentation
And to put them in a fixed length iteration, call a

Sprint (in Scrum). So a sprint combines all
aspects of the work required to build a product.
14
- Right from the first sprint, a Scrum team will try to create a valuable and usable product even if it is
not released to the customers or end users.
- After each sprint, the Scrum team demonstrates what they have accomplished and discussed what to
do next. Customers often need to see the wrong product before they can see what they really want.
- The short iterations allow for constant feedback and improvement, this considerably increases the
probability of creating the right product, a product that customers use and love.
- In order to accomplish that, the team needs to have all the necessary skills to understand the
business requirements, to do any design, development and testing work so that by the end of the
sprint, a valuable and usable product is created.
Sprint 1 Sprint 2 Sprint 3

15
- A Scrum team consists of a Scrum master, a product owner and the developers.
- The product owner will create a list of features called the product backlog and organize that list to ensure
that customers get the maximum amount of value.
- During Sprint Planning, the developers will select list of items from the top of the product backlog, work
on them during the sprint and turn them into a usable product (increment product). Increment is simply a
new version of the same product.
16
- The Scrum team has a fixed time frame to complete a work which cannot be longer than one
month, and the developers meet in a Daily Scrum to synchronize, identify problems and keep the
work moving forward.
- Along the way, the Scrum master keeps the team focused on the sprint goal and helps remove any
impediments that affect them.
17
- At the end of the sprint, the product increment should be valuable and usable and a Scrum team,
together with the stakeholders, conduct a review of the work completed and discuss what to do next.
- The last event of the sprint is a retrospective of the process, the Scrum team looks back at how the
sprint went and figured out a way to improve their development process.
- Then they start from the beginning with the next Sprint Planning and the cycle repeats.
18
Scrum Definition
19
Scrum Definition
Scrum is a lightweight framework that helps people, teams and organizations
generate value through adaptive solutions for complex problems.
The Scrum framework is purposefully incomplete. Rather than provide people

with detailed instructions, the rules of Scrum guide their relationships and
interactions.
Important to notice is the word FRAMEWORK. A framework provides a structure. It provides the
rules it governs. But it's not a complete solution. So, therefore, the name framework. It's just
producing it's just offering a frame in which the work should be done.
And Scrum is definitely not a process, a technique, a definitive method or a methodology or

anything like that.
- Complex things where you do not know in advance what will be the outcome and exactly how the path to the
solution should look like.
- They need to deliver the highest possible value that they can. So the end user or the customer should always get the
value from whatever it's being built.
20
Scrum Definition
Scrum is a lightweight framework that helps people, teams and organizations

generate value through adaptive solutions for complex problems.
The Scrum framework is purposefully incomplete. Rather than provide people

with detailed instructions, the rules of Scrum guide their relationships and
interactions.
- Scrum is lightweight. It is simple to understand but it is difficult to master.

- It's easy to understand because it's only described inside the Scrum Guide in a few pages.
- It's difficult to master, which means it's hard to implement everything that you see inside the Scrum
Guide.
21
What Scrum is actually used for
Scrum has been used to:

● Develop and sustain product enhancements
● Sustain or renew products
● Research and identify markets, technologies and product capabilities
It's important not to associate Scrum only with software development. Scrum is especially known in the software
industry and it has been tremendous successful but Scrum is not only about developing software.
Scrum has been used to:

● Develop hardware / software
● Build autonomous vehicles
● In schools and governments
● In marketing
● Or anywhere
22
SESSION 4
Scrum THEORY
23
Scrum Theory - What does this means?
- Scrum is actually founded on the Empirical Process of control theory, also called Empiricism, and
lean thinking
- Empiricism asserts that knowledge comes from experience. You need to make a decision based
on what is known at this point and what actually happened.
- Lean thinking reduces waste and focuses on the essentials.
- Scrum employs an iterative, incremental approach to optimize predictability and to control risk.
- What is important regarding this Empirical Control Process that is build on three pillars:
- Transparency
- Inspection
- Adaptation
24
Transparency
- The emergent process and work must be visible to those performing the work as well as those
receiving the work. Observers need have a common understanding of what is being seen.
- Transparency enables inspection. Inspection without transparency is misleading and wasteful.
- E.g:
- At the Daily Scrum, everyone on the team know each other's work.
- If you have like technical people discussing with business people if they don't share the same
language it's kind of hard to discuss about what is being observed.
- The Increment must share a common "Definition of Done".
25
Inspection
- The Scrum artifacts (product backlog, sprint backlog, increment) and the progress toward agreed
goals must be inspected frequently and diligently to detect potentially undesirable variances or
problems. (but it should not really get in the way of getting work done)
- To help with inspection, Scrum provides cadence in the form of its five events (Sprint Planning,
Daily Scrum, Sprint Review, Sprint Retrospective, Sprint itself).
- Inspection enables adaptation. Inspection without adaptation is considered pointless.
- Scrum events are designed to provoke change.
26
Adaptation
- If any aspects of a process deviate outside acceptable limits or if the resulting product is
unacceptable, the process being applied or the materials being produced must be adjusted.
- The adjustment must be made as soon as possible to minimize further deviation.
- Adaptation becomes more difficult when the people involved are not empowered or self-managing.
A Scrum Team is expected to adapt the moment it learns anything new through inspection.
27
SESSION 5
Scrum VALUES
28
Scrum values
- The Scrum values make the team more effective

- Scrum comes with its own set of five values that do exactly the same thing as Agile Manifesto for
Scrum teams.
- Commitment,
- Focus,
- Openness,
- Respect, and
- Courage
29
Scrum values - Commitment
- Every person on the team is committed to delivering the most valuable product that they can—and
supporting each other.
- Commitment facilitates empiricism and collaborative teamwork
- When we commit to the success of the team, not just caring about our individual
achievements, that creates an environment of trust, productive problem solving, and high team
standards.
- When we commit to doing Scrum fully, not just picking and choosing the easy parts, we can
fully experience the benefits of transparency, inspection, and adaptation.
- Committing to continuous improvement makes it easier to change direction based on new
information or empirical data.
- Commitment is about dedication to doing our best. We cannot predict or control all of the
complexities in product development, but we can commit to taking action and adjusting our
behaviors based on feedback and new learnings.
- When we commit to delivering value, we feel a greater sense of shared purpose that drives
our motivation to collaborate.
30
Scrum values - Commitment (cont.)
- Every Scrum role has a distinct accountability, and this is a commitment:

- The Product Owner demonstrates commitment by making the best decisions to optimize
the value of the product, not simply trying to please every stakeholder.
- The Developers demonstrates commitment by creating an Increment that meets their
definition of "Done", not something that is almost done.
- The Scrum Master demonstrates commitment by upholding the Scrum Framework, which
means we don't extend the Sprint or other time-boxes under pressure to get to "Done." The
Scrum Master demonstrates commitment by removing impediments that the Scrum Team
cannot resolve themselves, rather than tolerating the status quo in the organization.
31
Scrum values - Focus
- Every team member is focused on the Sprint Goal, and everything they do in the Sprint helps move
them toward it.
- During the Sprint, everyone works only on Sprint tasks, and does one task at a time and moves on
to the next task only when the current one is done until the Sprint is done.
- Focus facilitates empiricism and collaborative teamwork:
- When there are multiple issues, focus helps a team determine what to tackle first, inspect
their progress frequently, and try new experiments as they work towards a solution.
- When there are competing priorities, focus helps a team decide what is the most important
thing right now.
- When the future is uncertain, there is a tendency to want to keep analyzing. Focus helps a
team accept uncertainty, look at what they know today, and take a small step. This approach
works because we learn from doing and can change direction based on what we learn.
- The Scrum Team's shared accountability to create a valuable, useful Increment creates a
focus on the overall outcome, not simply on what each individual can accomplish.
- Having a product vision creates focus on where we are going, and that can inform the team's
decisions on a daily basis.
32
Scrum values - Openness
- We always know what our team members are working on, and are comfortable that they know what
you’re working on.
- If we run into a problem or an obstacle, we can bring it up with the team.
- Openness facilitates empiricism and collaborative teamwork:
- Being open about our work helps create transparency to our progress.
- Openness enables team members to ask for help.
- Openness allows team members to offer help to each other.
- Openness enables team members to share their perspectives, feel heard by their peers, and
be able to support team decisions.
- When our assumptions turn out to be invalid, openness helps us admit we were wrong and
change direction.
33
Scrum values - Respect
- Scrum Team members respect each other to be capable, independent people, and are respected as
such by the people with whom they work.
- Respect facilitates empiricism and collaborative teamwork:
- By having respect for people's diverse backgrounds, experiences, and range of skills,
teams are able to effectively solve complex problems in creative ways.
- When we respect that people are motivated by autonomy, mastery, and purpose, we
create an environment that engages people and enables teams to become greater than the
sum of their parts.
- If we respect that people are doing their best given what they know at the time and their
current resources, we enable transparency.
- When we show respect for people and assume they have good intentions, we can have
difficult conversations that help us figure out ways to resolve conflict and grow stronger as a
team.
- When there is respect for all opinions and perspectives, we can ensure everyone has the
opportunity to be heard. When we feel we have been heard, it is possible to fully support team
decisions even if the decision was not our preference.
34
Scrum values - Courage
- The Scrum Team members have the courage to do the right thing, to work on tough problems.
- Courage facilitates empiricism and collaborative teamwork:
- It takes courage to be transparent about progress under pressure to deliver more faster.
- It takes courage to ask for help or admit we do not know how to do something.
- It takes courage to hold others accountable when they are not meeting commitments to the
team.
- We may discover we built something our customers don't want. It takes courage to admit our
assumptions were wrong and change direction.
- It takes courage to try to build something we've never built before, not knowing if it will work or
not.
- It takes courage to share a dissenting opinion with a team member and engage in productive
conflict.
- It takes courage to admit our mistakes. This could apply to our technical work, our decisions,
or how we conduct ourselves.
35
The most important ideas regarding the Scrum framework
- Scrum is a framework for developing complex products

- Scrum addresses complex problems in an iterative way
- Scrum is lightweight, simple to understand but difficult to master
- The Scrum framework consists of Scrum Teams and their associated accountabilities, events,
artifacts, and rules.
- Scrum is used in very diverse areas, from developing software and hardware to managing the
operation of organizations and almost everything we use in our daily lives, as individuals and
societies.
- The essence of Scrum is a small team of people
- Scrum is founded on empirical process control theory, or empiricism.
- Three pillars uphold every implementation of empirical process control: transparency, inspection,
and adaptation.
- The Scrum Values are: commitment, courage, focus, openness and respect
36
Questions
Which of the following best describes Scrum? Select the best answer.
a. Scrum is a methodology for dealing with complex problems.
b. Scrum is a framework for dealing with complex problems.
c. Scrum is a process for dealing with complex problems.
d. Scrum is a technique for dealing with complex problems.
e. Scrum is a set of best practices for dealing with complex problems.
f. All of the options above apply.
g. None of the options above apply.
B. "Scrum is a lightweight framework that helps people, teams, and organizations generate value
through adaptive solutions for complex problems."
37
Questions
Complete the following sentence: The Scrum Team consists of _____ .

a. Developers, a Product Owner, and a Scrum Master.
b. At least one Product Owner and a few Developers.
c. Developers and Stakeholders from the organization.
d. All of the options above apply.
e. None of the options above apply.
A. “The Scrum Team consists of one Scrum Master, one Product Owner, and Developers.”
38
Questions
Complete the following sentence: Scrum can be used for _____

a. software development.
b. developing hardware products.
c. identifying viable markets and potential technologies.
d. research work.
e. All of the options above apply.
f. None of the options above apply.
39
Questions
Complete the following sentence: Scrum is founded on _____

a. Trust.
b. rationalism (the principle of basing actions on reason and knowledge).
c. idealism (the pursuit of perfection) and thinking outside of the box.
d. empiricism (the empirical process control theory) and lean thinking.
e. scientific research work.
f. All of the options above apply.
g. None of the options above apply.
D. “Scrum is founded on empiricism and lean thinking.”
40
Questions
Complete the following sentence: The Scrum framework consists of _____

a. Scrum Teams and their accountabilities.
b. Events.
c. Artifacts.
d. Rules.
e. All of the options above apply.
f. None of the options above apply.
E.
41
Questions
How does Scrum control risk?

a. Through a waterfall process.
b. By dealing with riskier aspects of the work first.
c. Scrum does not deal with risk.
d. Through an incremental approach.
D. “Scrum employs an iterative, incremental approach to optimize predictability and to control risk.”
42
Questions
The empirical process control is at the core of Scrum and contains three pillars. Which are these
Scrum pillars?
a. rules, roles, and events.
b. transparency, examination, and adaptation.
c. transparency, verification, and adaptation.
d. transparency, inspection, and adaptation.
f. clarity, verification, and adaptation.
D. The empirical Scrum pillars are transparency, inspection, and adaptation.
43
Questions
Which of the following are the five Scrum values?

a. commitment, courage, focus, openness, and respect.
b. empiricism, transparency, inspection, adaptation, and trust.
c. responsibility, courage, focus, iterations, and respect.
d. commitment, courage, focus, and a positive mindset.
A.
44
SESSION 6
Scrum ARTIFACTS
45
Scrum Artifacts
- The Scrum guide defines three artifacts: product backlog, sprint backlog, Increment
- Scrum artifacts represent work or value. They are designed to maximize transparency of key
information. Thus, everyone inspecting them has the same basis for adaptation.
- Each of the Scrum artifacts contains a commitment to something
- The product backlog exists to reach the long term objective - product goal
- The sprint backlog exists to reach the sprint goal that the Scrum team defines for every sprint.
Each sprint goal is a step toward achieving the goal.
- The product increment is committed to fulfilling the definition of done, which usually describes
the desired quality that the product should have.
PRODUCT BACKLOG PRODUCT GOAL
SPRINT BACKLOG SPRINT GOAL
INCREMENT DEFINITION OF DONE
*A commitment means to be dedicated to achieving something specific. Having a commitment ensures that everyone knows why the work is
46
important and what is the desired outcome.
PRODUCT BACKLOG
47
What is Product Backlog?
- In Scrum, the product backlog is an artifact designed to provide transparency and opportunities for
inspection and adaptation.
- The product backlog is an ordered list of everything that is needed in the product. Can contain new
features or improvements to existing once, fixes or any other changes that need to be done on the
product.
- The items in the product backlog are referred to as product backlog items or simply PBIs.
48
What is Product Backlog? (cont.)
- The characteristics of a backlog item depend on the product or the domain where the development
work takes place, typically an item will have attributes like:
- Description
- Order
- Size
- Value
- Acceptance criteria (to test if the work is complete)
- The sole person accountable for the product backlog is
the product owner, we call the activity of making changes
to the product backlog - product backlog management.
49
How exactly is the product backlog created and managed?
- Everything starts with a goal or a vision.
- The product owner is expected to define an objective that a product should achieve. This is the
product goal.
- The product owner try to understand the business requirements by constantly collaborating with the
stakeholders, knowing the market conditions and considering any other relevant information
sources.
- The product owner will add features or ideas to the product backlog as they deem relevant for a
product, but the product backlog content (PBIs) needs to be aligned with the product goal.
- The product goal is a commitment for the product backlog and is a part of it.
- There's only one product goal at a time.
50
- Managing the product backlog is an ongoing process, while the product owner is accountable for
the product backlog and can order, add or remove product backlog items any time they want.
- Product Owner closely work with the developers. During the product backlog refinement
activity, the product owner and the developers collaborate on breaking down larger items into
smaller ones that are easier to describe and develop. The smaller the items, the better it is.
- It will also work on adding details, size and order to the product backlog.
- The size of an item shows how big or small the effort of doing the work is, the process of figuring out
the size of an item is called sizing or estimation. The developers doing the work are responsible
for sizing and have the final say.
51
- The product owner and the developers collaborate to understand the items and often look for ways
to reduce complexity by making tradeoffs.
- Refinement activity is not part of the mandatory Scrum events, the Scrum team decides if, how
and when refinement is done.
- The product backlog is emergent and never complete or final. It is constantly changing the product
backlog growth with the product itself and changes based on business requirements, market
conditions or other relevant factors.
- The product backlog items that can be done in the next sprint are deemed as ready for selection.
This means that the items are small enough to fit within a sprint, detailed enough and
immediately actionable, meaning that the developers can start working on them right away.
PRODUCT BACKLOG
1. Create Homepage
PRODUCT GOAL 2. Display one product
3. Display list of products
1000 online orders per day in 4. Order form
the next 1 year 5. Add to cart
6. Online payment
52
User stories
- User stories are relatively short descriptions of a feature explained from the perspective of the
person who desires the functionality. Usually a user of the product.
- Commonly, when writing user stories, you go through a three step process (also known as the 3
Cs):
- Card
- Conversation
- Confirmation
53
User stories
- The card refers to the people card size, used to write the user story, usually a Sticky note.
- The main idea of the card remains the same because the card can only hold so much information.
We need to be brief. A template for a user story typically looks like this (but feel free to adapt)
CREATE HOMEPAGE
As a customer interested in ABC

products
I want to open a browser and use some
basic contact information
So that can help me get in touch.
54
User stories
- Another way of looking at the user story format is identifying the WHO, the WHAT and WHY.
- Often it brings value to the conversation is understanding the way the benefit of implementing the
user story, we don't want to build things that have no value and nobody wants it mentioned an
important aspect of conversation. This is the second C.
- The information contained by the product backlog item should be brief and to the point, think of the
items more like a reminder of what needs to be done. A conversation starter, not necessarily
detailed specification. This activity helps to have the same understanding of the work to be done.
55
User stories
- The last C is confirmation. We commonly refer to this as acceptance criteria. It is a way to test if
the story has been completed.
CREATE HOMEPAGE ACCEPTANCE CRITERIA
As a customer interested in ABC - I should see the logo of ABC

products - I should see the postal address,
I want to open a browser and use some the email address and phone
basic contact information number
56
User stories
- The product backlog item is written as a user story, but this doesn't mean that every item in the
product backlog needs to be written using this format.
- The Scrum team decides which format works best. It is OK to have different formats in the same
backlog use.
DISPLAY ONE PRODUCT BACKGROUND

The Apple Juice is the best selling product at ABC. A
As a customer interested in lot of customers ask questions about a product
products from ABC, acceptance criteria.
I want to open a browser and find ACCEPTANCE CRITERIA
some basic information about a The start page should include a button called Our
Apple Juice product to be better Product
informed about the ingredients and When Clicked. It should open a new page. The
available sizes. products page.
The product page should display one or more images
of the product. The product page should include a short
description. The product page should include an FAQ
U.S. with questions and answers.
57
User stories
- Backlog is by no means complete nor it will ever be more product backlog items will be created
and refined in the following sprint as more is learned about the product.
- While the product owner is accountable for the product, backlog content and order. It does not mean
that the rest of the Scrum team cannot write product backlog items or user stories and discuss them
with a product owner. However, the product owner still remains accountable.
58
Estimation or Sizing
- The stories now have a description, acceptance criteria and order as they are the first and second
items in the backlog.
- The next step would be to take this product back, look item written as a user story and discuss it
with the clarify details, see if the order makes sense and get an estimate. The words estimation or
estimate, size or sizing - they are referring to the same thing.
- This collaboration between the product owner and the developers happens during the product
backlog refinement activity.
ESTIMATE
- An estimate in the usual sense is a guess of the effort necessary to carry out a given task. In our
case, one product backlog item.
- It is a guess, not a commitment or a promise, there is always some uncertainty and that is fine.
59
QUESTION: So it means we should say how long it will take us in days?
ANSWER:
- That would be an option, but is not the best way to think about this.
- As in a lot of other aspects, Scrum is different from classic project management methods. You see,
humans are good at comparing things, for example, which building is higher than the one next to it.
We have a good intuition at comparing things without actually need to know the exact height or the
number of floors each building has. We call this a relative sizing at the same time.
- Studies have shown that people are terrible at guessing the building's actual height. This would be
absolute sizing.
- So when building a feature, we want to know the size first. Is it just a small or big?

60
A: How to proceed?
B: A scale imagined that 0 is changing the color of homepage background, almost no effort and 100 is
proceed online payment. This would be the start and the end of the scale could, pick a number between
zero and 100 that you think represents the effort of building a functionality. There's no wrong or right here.
7 14 19 30
61
B: Now, let's imagine that you can only pick one of the following numbers 0, 1, 2, 3, 5, 8, 13, 20, 40 and
100. This is an estimation technique called planning poker.
8 13 20 20
62
B: Now, we only have 8, 13, 20 and 20 looks much better than what we have started with. Let's now
discuss your estimates and try to reach a consensus, OK, you had an eight one for your reasons why?
A: Well, this is a simple page with the logo and subtext. No big deal.
C: Have you considered that we need to have an admin panel to added that information?
A: Oh, I'm afraid I've only estimated the design work. All right, one, let's try again.
20 20 20 20 63
A: Is there anything I can change regarding the product backlog item in order to reduce the complexity?
B: I guess the admin panel is something that is driving complexity up. OK, I'm more than happy to leave
that out, at least for the moment. Can you estimate the product backlog item again, this time without the
admin panel?
8 8 8 8 64
B: It has no meaning, we are not talking about eight hours, eight days or anything else.
- This is relative sizing.
- However, we will use this story as a reference. When estimating other stories, we will ask ourselves
if another story is smaller or bigger than this one later on, as we learn more, we may even agree to
go back to the story and estimate it again.
8

65
PBIs Value
- What a Product Owner can do is to specify the value that he or she thinks that the respective
Product Backlog item will add to the Product.
- Value may be value for Business or value for Customers or somehow Technical value or
Knowledge value.
- A simple way to have a value is to create a simple value scale. And in the scale, you can add
multiple values starting from 100 to 1000. This activity can enroll the stakeholders. Just to give
him some input, is to have different Product Backlog items and to arrange them based on the
perceived value on the scale.
- The value is just a guess. It's not something that has been measured. So the Product Owner needs
to measure the respective decision or the implementation of the Product Backlog item to see if that
led to the expected results.
- The value should be known in advance and it should be made transparent so that it is obvious for
the Product Owner but for the others as well.
66
Product Backlog Refinement
- The Product Backlog is continuously changing and evolving, and managing the Product Backlog
is something that a Product Owner cannot do without getting input from the rest of the Scrum Team.
- The Product Backlog Refinement is an ongoing activity, but this meeting is not part of the
prescribed Scrum events. This means that the Scrum Team decides how and when refinement is
done. As there are no pauses or gaps between Sprints, this meeting can happen any time during
the Sprint.
- Nevertheless, the Product Backlog Refinement still has a time-box, in the sense that it should not
occupy more than 10% of the capacity of the Scrum Team.
- This activity is not connected to the Sprint goal but very important for preparing the next Sprints. The
goal of this meeting is to have enough Product Backlog Items at the top of the Backlog "ready"
for selection in the next Sprint Planning. This activity can even take place during the Sprint Planning
itself, but ideally, most of the Items should have been refined already.
- During the Product Backlog Refinement meeting, the Product Owner and the Scrum Team, work on
making sure that the items are small enough to fit in one Sprint and add details, estimates, and
order to the Product Backlog.
- Not all items in the Backlog need to reach the level of detail that Items at the top have. This is
an efficient way of eliminating waste and making sure that time is efficiently used.
67
Product Backlog Refinement
- Typically the Product Owner will come with new ideas, features, or fixes and will try to express
them in Product Backlog Items.
- The Product Owner and the Scrum team will collaborate on clarifying any questions and making the
items as clear as possible.
- However, the Product Backlog can be changed at ANYTIME by the Product Owner, not only during
this meeting.
- The Developers will be asked to estimate the items in the backlog. The Product Owner may offer
alternatives or make trade offs to reduce the complexity and to get a better estimate. But what is
important to remember is that the Developers is responsible for all estimates and it has the final
saying.
68
Questions
Complete the following sentence: The Product Backlog is _____ of everything that is known to be
needed in the Product.
a. a random list
b. a ordered list
c. a complete list
d. None of the above
B. The Scrum Guide refers to the Product Backlog as an ordered list.
69
Questions
Which of the options below represent a single source of requirements for any changes to the Product?
a. The Product Goal
b. The Sprint Backlog
c. The Product Backlog
d. The Definition of Done
e. The Increment
C. The Product Backlog is “the single source of work undertaken by the Scrum Team.” - Scrum Guide
v2020.
70
Questions
Who is accountable for the Product Backlog when it comes to content and order?
a. The Product Owner and the Developers
b. The Product Owner
c. The Scrum Master
d. The Stakeholders and the Product Owner
e. The Stakeholders
B. Only the Product Owner is accountable for managing the Product Backlog, even if they collaborate
with the rest of the Scrum Team and the Stakeholders.
71
Questions
The Product Backlog should be complete, clear, and refined before the next Sprint can begin.
a. True
b. False
B. The Product Backlog is never complete. Only the Product Backlog Items at the top of the backlog
should be refined, clear, and achievable in a Sprint.
72
Questions
Complete the following sentence: _____ is the act of adding detail, order, and size to items in the
Product Backlog.
a. The Product Refinement
b. The Product Increment
c. The Product development effort
d. The Backlog Grooming
e. The Product Backlog refinement
E. The Scrum Guide v2020 explains: "Product Backlog refinement is the act of breaking down and
further defining Product Backlog items into smaller, more precise items. This is an ongoing activity to
add details, such as a description, order, and size. Attributes often vary with the domain of work."
73
Questions
How much time should the Product Owner dedicate to managing the Product Backlog?
a. as much time as needed
b. no more than 10% of the capacity of the Scrum Team
c. no more than 4 hours for a 4-week Sprint
d. this will be decided by the Scrum Master responsible for the process
A. The Scrum Guide does not set a limit. As this is one of the Product Owner's primary
accountabilities, they should invest as much time as needed.
74
Questions
How should the Product Backlog be ordered?

a. By size
b. By complexity
c. By clarity by risk
d. By deadlines
e. As seen appropriate by the Product Owner
E. The Product Owner may order to Product Backlog as they think it is best, in order to maximize the
value. The Scrum Guide v2020 explains: “The Product Owner is accountable for maximizing the value
of the product resulting from the work of the Scrum Team.”
75
Questions
The Product Backlog can be modified even after the Sprint has started.
a. True
b. False
A. There are no restrictions on when the Product Backlog can be modified. The Product Backlog
should always be up to date and reflect what the Scrum Team will do next.
76
Questions
Which of the following represents the commitment for the Product Backlog?
a. The Product Owners do their best to update the Product Backlog in a timely manner.
b. The Product Vision
c. The Product Goal
d. The Sprint Goal
e. The Definition of Done
C. The Scrum Guide v2020 explains: “Each artifact contains a commitment […] For the Product
Backlog it is the Product Goal.”
77
SPRINT BACKLOG
78
Sprint Backlog
Sprint Planning
SPRINT GOAL SPRINT BACKLOG
79
Sprint Backlog
- During the Sprint Planning meeting, the product owner explains what needs to be done next to
increase the value of the product, and the entire Scrum team formulates a sprint goal.
- By collaborating with a product owner, the developers will decide which items starting from the top
of the product backlog will be added to the sprint backlog.
- The sprint backlog will also contain a plan to deliver the product increment and realize the sprint
goal.
Sprint Goal
80
Sprint Backlog
PRODUCT BACKLOG SPRINT BACKLOG
- The product backlog is an ordered list - The sprint backlog is created from
of ideas or features the product should scratch at the beginning of every
or could have basically everything that sprint and contains:
could be done. - the product backlog items that
- We call these items in the list product will be done in the current sprint
backlog items. - a plan on how to deliver the
functionality and
- the sprint goal.
- All items in the sprint backlog come from
the product backlog.
81
Sprint Backlog
- A plan is essentially a decomposition of each product backlog item in smaller work units that
allow the developers to build the increment. We often call the smaller units of work - tasks.
- Many people learning Scrum quite often forget that a sprint backlog also contains a plan and the
sprint goal, not just the selected items, don't make the same mistake.
- WHY: The sprint goal gives guidance and flexibility and explains why the sprint is valuable.
SPRINT
- WHAT: The product backlog items represent what will be delivered. BACKLOG
- HOW: The plan handles how this will happen
CREATE HOMEPAGE
- Creating Git Repository
Sprint Goal - Create the simple HTML page
- Create deployment pipeline that
will help them automatically publish
any changes
- Set up the hosting account
- Test the website on multiple
browsers
82
Sprint Backlog
- When the developers select the product backlog items, they think that can be completed in a sprint,
they create a forecast for what will be delivered.
- The sprint forecast is not a guarantee, a promise or a commitment. Unexpected things may
happen during the sprint.
- The sprint backlog makes transparent all the work that the developers deem as necessary to reach
the Sprint Goal, which represents the commitment that the sprint backlog has.
- You can do the sprint backlog as a temporary artifact that exists only during the sprint. Every
sprint will have a new sprint backlog.
- Any unfinished work that remains in the sprint backlog at the end of the sprint will be put back
into the product backlog. The product owner will decide what should happen next.
- Product backlog is the product owner's accountability # The sprint backlog, the developers are
accountable.
- The developers will modify the sprint backlog throughout the sprint as they think it is necessary to
reach the sprint goal when they identify new work that needs to be done, they immediately added to
the sprint backlog.
- The total work remaining in the sprint backlog will be tracked at least once with every Daily
Scrum, the developers are responsible for monitoring the progress toward the sprint goal. 83
Sprint Scope vs Sprint Goal
- One of the most confusing parts of Scrum is understanding the difference between the sprint scope
and the sprint goal.
- The sprint scope can be renegotiated
- The sprint goal remains the same
Weekend plan
Have a great picnic GOAL FOCUS
Search for place

Invite friends SCOPE
Buy camp What you want to do +
Check weather forecast the extent of the work
If during the day you notice that you are running behind your plan, you may reduce the scope, for
example, you decide to book a hotel instead of buying a camp. 84
Sprint Scope vs Sprint Goal
- The Sprint Scope represents the functionality that will be developed during the sprint.
- The scope of the sprint backlog is the amount of work selected by the developers, in other
words, the selected product backlog items.
- The scope is flexible and can be modified during the sprint.
- The terms Scope = Sprint scope = Scope of the sprint backlog
- With the time available, the developers will try to stay focused and do their best to reach the sprint
goal.
- The scope renegotiation with the product owner can happen any time. The idea is to meet the
sprint goal while making some compromises, usually in terms of features, NEVER ON QUALITY.
- In this process, the product owner and the developers decide which is the best course of action.
Some items in the sprint backlog may not directly contribute to reaching the sprint goal. Others
can be simplified. Items can even be replaced with other items from the product backlog.
Anything is possible as long as the sprint goal is not in danger.
- In practice, it is rarely the case that the entire spring backlog will contribute to reaching the Sprint
Goal, while most of the items in the sprint backlog must be related and must help reach the sprint
goal. It is not always possible to have a sprint backlog that only focuses on reaching the spring goal.
And this is also the part that allows for some flexibility to happen. 85
Questions
The Sprint Backlog is an output of the Sprint Planning meeting, as is the Product Goal.
a. True
b. False
B. The Sprint Goal is indeed an output of the Sprint Planning meeting, but not the Product Goal. Don’t
confuse the Sprint Goal with the Product Goal.
86
Questions
The Product Backlog refinement activity helps add details to Product Backlog Items for upcoming
Sprints, but NOT for the current Sprint.
a. True
b. False
A. The name of the activity says everything: Product Backlog refinement. Anything in the Product
Backlog is NOT in the current Sprint, as it would be in the Sprint Backlog. The fact that the Product
Owner can help clarify items in the Sprint Backlog has nothing to do with this activity.
87
Questions
The Sprint Backlog contains only the Product Backlog Items selected by the Developers during the
Sprint Planning meeting.
a. True
b. False
B. Please notice the word “only” in the question. The Sprint Backlog contains the selected items, but
also the Sprint Goal and the plan. The Scrum Guide v2020 explains: “The Sprint Backlog is composed
of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an
actionable plan for delivering the Increment (how).”
88
Questions
Who should create the Sprint plan?

a. The Product Owner
b. The Developers
c. The Scrum Team
d. There is no plan. The Product backlog is the only plan needed
B. The plan for Sprint is within the Sprint Backlog. The Scrum Guide v2020 explains: “The Sprint
Backlog is a plan by and for the Developers.”
89
Questions
Who decides when to update the Sprint Backlog?

b. The Developers
c. The Scrum Team
d. The Scrum Master
B. The Developers will update the Sprint Backlog regularly during the Sprint. The Scrum Guide v2020
explains: “The Sprint Backlog is a plan by and for the Developers. [...] Consequently, the Sprint
Backlog is updated throughout the Sprint as more is learned.”
90
Questions
What can the Sprint Backlog contain?

a. Tasks associated with a Product Backlog Item
b. User Stories
c. Sketches or wireframes
d. Diagrams
e. Test Criteria
f. All of the options above apply
g. None of the options above apply
F. Anything that is a decomposition of the work required to complete a Product Backlog Item and
create a working Increment will be placed in the Sprint Backlog. The Developers decide the format
used to describe how the work to be done.
91
Questions
Which of the following represents the commitment for the Sprint Backlog?
a. The Developers do their best to complete all the work in the Sprint Backlog.
b. The Product Vision
c. The Product Goal
d. The Sprint Goal
e. The Definition of Done
D. The Scrum Guide v2020 explains: “Each artifact contains a commitment […] For the Sprint Backlog
it is the Sprint Goal.”
92
INCREMENT
93
Increment
- The increment is a new version of the product and is additive to all previous increments from all
previous sprints (you can view it like a building block placed on top of all previous work completed)
- The developers were to deliver at least a new product increment with each sprint.
- Each new increment is an improved and usable version of the product.
- It is solely the discretion of the product owner if and when to release the increment, still, the
increment needs to be usable without needing any additional work, like testing, documentation
or even integrating it with the work other Scrum teams did.
94
Definition of Done
- When a product backlog item or increment is considered a complete or done, everybody must
understand what DONE means.
- Sometimes the organization may define quality standards and those need to be followed at a
minimum to make it easier for everybody to understand what complete work looks like. The
definition of done is mostly about quality.
95
Definition of Done
- In Scrum, each Sprint will create at least one product increment that needs to adhere to the
definition of done.
- If a product backlog item in the sprint does not follow the definition of done, it will not be included
in the product increment.
- When Scrum team gains more experience, it is expected that the definition of done will contain
more strict criteria to ensure higher quality.
- During the Sprint Retrospective, the Scrum team plans on how to increase product quality and one
way to ensure this is by adapting the definition of done.
- There is no standard on what the definition of done should include, as this can vary from team to
team and from product to product.
- By using a definition of done, it becomes transparent for everyone what it means for the product
increment to be done.
- The definition of done will also guide the developers on how many product backlog items to
choose during the spring planning meeting.
- The definition of done represents a commitment for the increment. As soon as one product
backlog item is completed and meets the definition of done, a new increment is created.
96
Definition of Done vs. Acceptance Criteria
- We use the definition of done is very general, makes no reference to particular functionality.
The definition of done tends to be more technical talk about code, quality, code coverage, security,
best practices.
- Acceptance criteria are specific to a particular item, the acceptance criteria tries to describe when
an item is complete, mostly from a functional perspective.
- Acceptance criteria apply to a single PBI, while the definition of done applies to that PBI + to
the entire product increment.
- For one product backlog item to be released to the users, it needs to meet the acceptance criteria
(if they exist) and the definition of done. A definition of done explicitly mentions that the
acceptance criteria must be fulfilled.
- The increment created from one or more PBIs also needs to meet the definition of done.
Definition of Done Acceptance Criteria
- Applies to every PBI & Product Increment - Applies to a single PBI

- Created by Scrum team - Created by Product Owner (accountable)
- Commitment to Increment - Part of a PBI
- Mandatory in Scrum - Optional in Scrum 97
Questions
When is the development work on a Product Backlog Item in the Sprint Backlog considered
complete?
a. When the Product Owner accepts the work.
b. At the end of the Sprint.
c. When the QA Engineer signs-off the release.
d. When all the work related to the Product Backlog Item is done according to the Definition of Done.
e. When the Sprint Goal has been reached.
D. The Definition of Done is used to identify work and add it to the Sprint Backlog. Work on an item is
considered complete when there is no more work left in the Sprint Backlog related to it, and the item
meets the Definition of Done.
98
Questions
What is the responsibility of the Developers during the Sprint?

a. To complete all the work in the Sprint Backlog by the end of the Sprint.
b. To create at least one usable Increment.
c. To do as much work as possible to reach the Product Goal.
d. To send a daily progress report to the Product Owner.
B. The Scrum Guide v2020 explains: “Developers are the people in the Scrum Team that are
committed to creating any aspect of a usable Increment each Sprint.”
99
Questions
Every Product Increment is a step toward reaching the Product Goal.

a. True
b. False
A. The Scrum Guide v2020 explains: “An Increment is a concrete stepping stone toward the Product
Goal.”
100
Questions
Which of the following represents the commitment for the Increment?

a. The Product Vision.
b. The Product Goal.
c. The Developers do their best to create one Increment by the end of the Sprint.
d. The Sprint Goal.
e. The Definition of Done.
E. The Scrum Guide v2020 explains: “Each artifact contains a commitment […] For the Increment it is
the Definition of Done.”
101
Questions
The Scrum Team can create and release multiple Product Increments in a Sprint.
a. True
b. False
A. There is no reason to wait for the Sprint Review to deliver an Increment. The Scrum Guide v2020
explains: "Multiple Increments may be created within a Sprint. [...] An Increment may be delivered to
stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to
releasing value."
102
SESSION 7
SCRUM EVENTS
103
Scrum Events
- Scrum uses prescribed events or meetings or ceremonies, to reduce the need for other meetings
that are not defined in Scrum.
- This does not mean that the Scrum team cannot have other meetings, but it is mandatory to have
the Scrum events.
- At the heart of Scrum is the sprint, which acts as a container for all Scrum events. Remember that
there are no pauses or gaps between sprints and everything happens within the sprint container.
- For this reason, the sprint is a special kind of an event. All events within Scrum have a maximum
duration and are therefore - Time-boxed.
- Events are designed to enable transparency and inspection. There are recommends that the
events are held at the same time and place to create a routine and to reduce complexity.
o Sprint Planning, where the work to be performed in the sprint is planned.
o The Daily Scrum, which is held every day of the Sprint
o Sprint Review, which is held at the end of the sprint to review the increment.
o Sprint Retrospective, which is an opportunity to discuss ways to improve our all Scrum events,
which are a formal opportunity to inspect and adapt
- In other words, all Scrum meetings are an excellent opportunity to get feedback and to take action
based on the feedback received. 104
Scrum Events
- These events are mandatory and team cannot simply decide to skip or postpone them.
- While Scrum makes these events mandatory, it does not mean that the Scrum team cannot have
other meetings. It is a common misconception to assume that any discussions within the Scrum
team or between the Scrum team and the stakeholders must happen in a Scrum event.
- The product backlog refinement activity is not a mandatory Scrum meeting and it is not
considered a Scrum event.
SPRINT
Sprint Planning Daily Scrum Sprint Review
Sprint Retrospective
105
Sprint
- A Sprint has a time-boxed of one month or less in which a valuable, usable Product Increment is
created.
- If the duration of the Sprint is too long, the complexity and risk may increase.
- Having these relatively short horizons it is also easier to plan what is being built and to get
early feedback.
- Sprints contain all the prescribed Scrum Events, a flexible plan on how to build a Product
Increment and of course the development work needed.
- Each Sprint has the Sprint Goal which is an objective that will be met within the Sprint time-box
and which helps the Developers better understand WHY it is building the Increment.
- During the Sprint, no changes should be made that would endanger the Sprint Goal.
- It is also important that the quality standards do not decrease, especially if the time-box is about
to expire.
- As the product increment is being built, new things are learned. When necessary, the scope of the
Sprint may be clarified and renegotiated between the Developers and the Product Owner.
- A new Sprint starts immediately after the previous Sprint has ended. There is no gap between
Sprints and nothing happens between Sprints.
106
Sprint
107
Cancel a Sprint
- Canceling a Sprint before the time-boxed expires is a very very rare occurrence.
- A Sprint can be canceled if the Sprint Goal becomes obsolete or if there are some major and
sudden changes on the market or if the company decides to change direction.
- Only the Product Owner has the authority to cancel the Sprint. It may do so if advised by the
Stakeholders, the Developers or the Scrum Master but only Product Owner can take this decision.
- If a Sprint is canceled, the Product Backlog Items that are completed will be reviewed. Incomplete
Backlog Items will be re-estimated and put back into the Product Backlog.
108
Sprint Planning
- The Sprint Planning is a time-boxed to a maximum of eight hours for a one-month Sprint. For
smaller Sprints it should be smaller.
- This event happens usually after the conclusion of the previous Sprint.
- During the event, the Product Owner and the Developers will agree on a Sprint Goal and discuss
which Items from the Product Backlog will be added to the Sprint Backlog.
SPRINT GOAL SPRINT BACKLOG
109
Sprint Planning
Step 1: Why is this Sprint valuable?
- The Product Owner proposes how the product could increase its value and utility in the current
Sprint.
- The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint
is valuable to stakeholders.
- The Sprint Goal must be finalized prior to the end of Sprint Planning.
SPRINT GOAL
110
Sprint Planning
Step 2: What can be Done this Sprint?
- The Developers will work to forecast what can be done in the Sprint. The number of Product
Backlog Items selected is solely up to the Developers.
- In order to make the above mentioned forecast. The Scrum Team has a few details they need to
take into account, which are their Definition of Done + the projected capacity of the Developers +
the past performance of the Developers.
Definition of Done
Projected Capacity
Past Performance
111
Sprint Planning
Step 3: How will the chosen work get done?
- For each selected Product Backlog item, the Developers plan the work necessary to create an
Increment that meets the Definition of Done.
- This is often done by decomposing Product Backlog items into smaller work items of one day or
less.
- How this is done is at the sole discretion of the Developers. No one else tells them how to turn
Product Backlog items into Increments of value.
Sprint Goal
112
Questions
How many Sprints are planned in the Sprint Planning event?

a. Exactly one.
b. At least one.
c. At least two.
d. As many as possible, as long as the time-box does not expire
A. The purpose of the Sprint Planning is to plan a single Sprint.
113
Questions
Who must attend the Sprint Planning meeting?

a. The Scrum Team
b. In the first two parts, the entire Scrum Team. For the last part, only the Developers are needed.
c. The Scrum Team, Stakeholders, and other experts.
d. The Developers and the Product Owner.
A.
114
Questions
The Stakeholders are allowed to participate in the Sprint Planning meeting to clarify the Product
Backlog Items and provide advice.
a. True
b. False
B. The Scrum Team may invite external people to attend the meeting and provide technical or domain
advice – this is not the same as saying they invite Stakeholders. Nobody attends without being
invited. The Stakeholders are mentioned in the Scrum Guide as participating in the Sprint Review
meeting. They have nothing to do with the Sprint Planning meeting. If Stakeholders attend this
meeting, they attend as domain experts (or similar) and provide advice. 115
Questions
Complete the following sentence: The Sprint Goal belongs to _____

a. The Developers
b. The Stakeholders
c. The entire Scrum team
d. The Product Owner
e. The Scrum Master
C. The Sprint Goal is shared by the entire Scrum Team, not just the Developers.
116
Questions
What do the selected Product Backlog Items during the Sprint Planning represent?
a. A forecast
b. A commitment
c. A goal
d. A plan
A. The selected items are a forecast for what will be accomplished in the Sprint. It is not a
commitment or a promise. The Scrum Guide v2020 explains: “Selecting how much can be completed
within a Sprint may be challenging. However, the more the Developers know about their past
performance, their upcoming capacity, and their Definition of Done, the more confident they will be in
their Sprint forecasts.” 117
Daily Scrum
- The Daily Scrum is a time-boxed (15-minute) event held at the same time and place each day to
reduce complexity.
- The Daily Scrum is held every day during the Sprint and it is an event intended for the Developers.
During this event the Developers plans what work will be performed in the next 24 hours.
- The Daily Scrum is a key "inspect and adapt" meeting in Scrum. The Developers can select
whatever structure and techniques they want, as long as their Daily Scrum focuses on
progress toward the Sprint Goal and produces an actionable plan for the next day of work. This
creates focus and improves self-management.
- If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they
participate as Developers.
- Daily Scrums improve communications, identify impediments, promote quick decision-making,
and consequently eliminate the need for other meetings.
- The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet
throughout the day for more detailed discussions about adapting or re-planning the rest of the
Sprint’s work.
118
Daily Scrum
- During this meeting the role of the Scrum Master is to make sure that the Developers has the
meeting and it is teaching to keep it within the time-box.
- While this is an internal meeting, the Developers could allow for others to be present. The Scrum
Master ensures that they do not disturb the meeting. This is a meeting for the Developers and not
for reporting the progress toward a Product Owner or the Stakeholders.
What did I do yesterday?

What will I do today?
Do I see any impediment?
119
Questions
Who should lead the Daily Scrum meetings?

a. The Scrum Master
b. The Lead Developer or the Team Lead
c. It is up to the Developers to decide how to conduct the meeting
C. The Scrum Guide v2020 is explicit about this: "The Developers can select whatever structure and
techniques they want."
120
Questions
Which of the following statements in regards to the Daily Scrum is FALSE?

a. The Daily Scrum meeting must take 15-minutes.
b. All Developers from the Scrum Team attend the Daily Scrum.
c. The Scrum Master is not present during the meeting.
d. The Daily Scrum is a key meeting to inspect the progress toward the Sprint Goal in the last 24
hours.
A. The time-box of the meeting is 15-minutes. This means that the meeting can also take less than
15-minutes. There is no need to use the entire time if the purpose of the meeting has been reached.
121
Questions
The Developers must have the Scrum Board open and visible during the Daily Scrum.
a. True
b. False
B. Scrum Boards are a complementary practice that can be used with Scrum. However, this is not
explicitly mentioned by the Scrum Guide, and therefore it is not a requirement.
122
Questions
What is the duration of the Daily Scrum meeting?

a. At least 15-minutes.
b. Exactly 15-minutes.
c. No more than 15-minutes.
d. Depends on the Scrum Team size.
e. At least 2 minutes for every Developer.
C. The Daily Scrum, like all other Scrum events, has a time-box of 15-minutes. The meeting should
not take more than 15-minutes, but it may also take less.
123
Sprint Review
- The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future
adaptations. The Scrum Team presents the results of their work to key stakeholders and progress
toward the Product Goal is discussed.
- During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint
and what has changed in their environment. Based on this information, attendees collaborate on
what to do next.
- The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a
working session and the Scrum Team should avoid limiting it to a presentation.
- It is a timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the
event is usually shorter.
- The Sprint Review is an informal meeting not a formal status meeting.
- This meeting is not only a good opportunity for the Scrum Team to gather feedback but also for the
Stakeholders to ask questions or to suggest changes or new features to the Product Owner.
124
Sprint Review
- The Product Backlog Items that have not been done yet or that are not fully done (For example
some functionality has not been built or more testing is needed and that is not completed yet). So
first of all there will NOT be demonstrated during this meeting and they should not be part of the
Product Increment. They will be put back in the Product Backlog.
125
Questions
During the Sprint Review meeting, one Stakeholder is not happy that a particular feature of the
Product has not been implemented yet. To whom should the Stakeholder talk to get this addressed?
a. Directly with the Developers responsible for building the Product.
b. The Scrum Master.
c. The Product Owner.
d. The Scrum Team.
C. By ordering the Product Backlog, the Product Owner decides which features will be implemented in
a Sprint.
126
Questions
During the Sprint Review meeting, the Scrum Team demonstrates complete and incomplete Product
Backlog Items and discusses what to do next.
a. True
b. False
B. Incomplete work (also called not "done" work) is not part of the Increment and is not an outcome of
the Sprint. Demonstrating unfinished work may give the impression that the work is done and can be
released immediately. This does not mean that incomplete work cannot be mentioned or discussed.
127
Questions
What should the Product Owner do if a Product Backlog Item is only partially done?
a. Inspect the work together with the Stakeholders and decide if it is acceptable.
b. Accept the Product Backlog Item and create a new Product Backlog item for the rest of the work
needed.
c. Put the remaining work back in the Product Backlog.
C. Incomplete work is not releasable. The Product Owner should put the item back into the Product
Backlog and decide what should happen next.
128
Questions
The Stakeholders have been complaining to the Scrum Master that the Sprint Review meeting is too
long. In order the speed-up the review meeting, the Scrum Team has created a presentation with
slides of the features it has completed in the Sprint. Is this a good idea?
a. Yes, this is acceptable as the meeting is time-boxed.
b. Yes, because the Product Owner has already reviewed the features before the meeting.
c. No, because the stakeholders cannot give valuable feedback.
C. This is generally not a good idea, as one aspect of the meeting foster collaboration and get
feedback on the actual Increment. This does not mean that slides cannot be used, but it should not
entirely replace the demonstration.
129
Questions
The Product Owner accepts work only during the Sprint Review meeting.
a. True
b. False
B. There is no need to wait for the Sprint Review meeting to review work. The Developers and the
Product Owner should collaborate throughout the Sprint to ensure that the Increment and any
completed items are acceptable. This is part of the inspection process.
130
Questions
What is the duration of the Sprint Review meeting for a three-week Sprint?
a. 1 hour or less
b. 2 hours or less
c. 3 hours or less
d. 4 hours or less
e. 8 hours or less
D. The Sprint Review is at most a four-hour meeting for one-month Sprints. The meeting is usually
shorter for shorter Sprints. The Scrum Guide does not say it should be proportionally shorter. In
practice, you can use math to figure out how long a meeting should take for Sprints that are shorter
than 4-weeks, but AGAIN, this is NOT imposed by Scrum.
131
- The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
- This Sprint Retrospective is the very last event in the Sprint, right after the Sprint Review but prior to
the next Sprint Planning.
- The Scrum Team inspects how the last Sprint went with regards to individuals, interactions,
processes, tools, and their Definition of Done.
- The Scrum Team discusses what went well during the Sprint, what problems it encountered, and
how those problems were (or were not) solved.
- The Scrum Team identifies the most helpful changes to improve its effectiveness. The most
impactful improvements are addressed as soon as possible.
- They may even be added to the Sprint Backlog for the next Sprint. The Sprint Retrospective
concludes the Sprint.
132
- It is timeboxed to a maximum of three hours for a one month Sprint. For shorter Sprints, the
event is usually shorter.
- The Sprint Retrospective is an internal Scrum Team event where no external parties are involved.
Having Stakeholders or Management involved in this meeting would most likely inhibit the team
towards openly discussing the problems they see and would reduce the effectiveness of the
meeting. Any discussion with external parties regarding the improvement of the process should be
done outside of this event.
- The Scrum Master acts as a facilitator for this meeting, makes sure that everybody understands
the purpose and ensures that the meeting is positive and productive and coaches a team to keep
the event within the time-box.
133
https://www.atoha.com/blogs/kien-thuc/agile-retrospectives-nhin-lai-va-cai-tien-hieu-qua-cong-viec-du-an
Questions
When should the Sprint Retrospective take place?

a. Anytime during the Sprint, as requested by the Scrum Team.
b. At the end of each Sprint.
c. At the beginning of the Sprint.
d. Only after a release (also called Release Sprint Retrospective)
B.
134
Questions
The Stakeholders can participate in the Sprint Retrospective but only when invited by the Product
Owner.
a. True
b. False
B. The Sprint Retrospective is an internal Scrum Team event. So no external people can be present.
135
Questions
What should be the maximum duration of the Sprint Retrospective for a 2-week Sprint?
a. 1 hour
b. 1.5 hours
c. 2 hours
d. 3 hours
D. The Scrum Guide prescribes a maximum of 3 hours duration for the Sprint Retrospective when the
Sprint is one month long. Nevertheless, the event should be shorter if the Sprint is shorter than four
weeks. However, the Scrum Guide does not say the event time-box should be proportional to the
Sprint length.
136
Questions
Complete the following sentence: The purpose of the Sprint Retrospective is to inspect how the last
Sprint went with regards to _____
a. the expectations of the Product Owner and the Stakeholders.
b. people, relationships, processes, tools, and the Definition of Done.
c. the performance of the Developers.
d. reaching the Product Goal.
B. The Scrum Guide v2020 explains: “The Scrum Team inspects how the last Sprint went with
regards to individuals, interactions, processes, tools, and their Definition of Done.”
137
Questions
Complete the following sentence: By the end of the Sprint Retrospective, the Scrum Team _____
a. should be able to explain to the Product Owner how they will improve the performance of the team.
b. should have identified improvements that will be done in the next Sprint.
c. should know which Product Backlog Items will be selected for the next Sprint.
d. should explain to the Product Owner which changes will be made to the Product.
B.
138
Questions
To reduce complexity, it can help if the Sprint Retrospective is held at the same time and place.
a. True
b. False
A. It is not mandatory, but doing so can reduce complexity. This applies to all Scrum events. The
Scrum Guide explains: "Optimally, all events are held at the same time and place to reduce
complexity."
139
Questions
What is the role of the Scrum Master in the Sprint Retrospective meeting?
a. Teaches the Scrum Team to keep the meeting within the 15 minutes time-box.
b. Ensures that the Scrum Team understands the Stakeholder feedback gathered in the Sprint
Review meeting.
c. The Scrum Master participates as a member of the Scrum Team. The Scrum Master ensures that
the meeting is positive and productive.
C. The Scrum Master is a member of the Scrum Team. Scrum Master is responsible for “ensuring that
all Scrum events take place and are positive, productive, and kept within the timebox.” - Scrum Guide
v2020.
140
Questions
How can the Scrum Team improve the quality of the Product?
a. by improving processes and adapting the Definition of Done.
b. by getting feedback from the Product Owner.
c. by following the recommendations of the Scrum Master.
A.
141
Questions
The Sprint Retrospective must start with a short and fun activity to make everybody more relaxed and
positive.
a. True
b. False
B. Notice the “must” in the question. The Scrum Guide does not make any explicit suggestions on
how this meeting should be structured and conducted. While such activities COULD be organized,
they certainly MUST not.
142
SESSION 8
SCRUM TEAM AND
ACCOUNTABILITIES
143
Scrum Team
- The fundamental unit of Scrum is a small team of people, a Scrum Team.
- The Scrum Team consists of one Scrum Master, one Product Owner, and Developers.
- Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals
focused on one objective at a time, the Product Goal.
144
Scrum Team
- Scrum Teams are cross-functional, meaning the members have all the skills necessary to create
value each Sprint.
- They are also self-managing, meaning they internally decide who does what, when, and how.
- The Scrum Team is small enough to remain nimble and large enough to complete significant work
within a Sprint, typically 10 or fewer people.
- In general, we have found that smaller teams communicate better and are more productive. If
Scrum Teams become too large, they should consider reorganizing into multiple cohesive
Scrum Teams, each focused on the same product. Therefore, they should share the same
Product Goal, Product Backlog, and Product Owner.
145
Scrum Team
- The Scrum Team is responsible for all product-related activities from stakeholder collaboration,
verification, maintenance, operation, experimentation, research and development, and anything else
that might be required.
- They are structured and empowered by the organization to manage their own work. Working in
Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.
- The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.
Scrum defines three specific accountabilities within the Scrum Team: the Developers, the
Product Owner, and the Scrum Master.
146
Product Owner
- The Product Owner is accountable for maximizing the value of the product (business value,
value of customers, technical value,...) resulting from the work of the Scrum Team. How this is done
may vary widely across organizations, Scrum Teams, and individuals.
- The Product Owner is also accountable for effective Product Backlog management, which
includes:
- Developing and explicitly communicating the Product Goal;
- Creating and clearly communicating Product Backlog items;
- Ordering Product Backlog items; and,
- Ensuring that the Product Backlog is transparent, visible and understood.
- The Product Owner may do the above work or may delegate the responsibility to others.
Regardless, the Product Owner remains accountable.
- For Product Owners to succeed, the entire organization must respect their decisions. These
decisions are visible in the content and ordering of the Product Backlog, and through the inspectable
Increment at the Sprint Review.
- The Product Owner is one person, not a committee. The Product Owner may represent the needs
of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do
so by trying to convince the Product Owner.
147
Questions
Complete the following sentence: The main accountability of the Product Owner is to _____
a. maximize the value of the Product by verifying the work the Developers do.
b. optimize the value of the work the Scrum Team performs.
c. check that the Scrum Team understands the items in the Product Backlog.
B. The Scrum Guide v2020 explains: “The Product Owner is accountable for maximizing the value of
the product resulting from the work of the Scrum Team.” Optimizing and maximizing have the same
meaning in this context.
148
Questions
The Product Owner may delegate architectural decisions regarding the Product to the rest of the
Scrum Team.
a. True
b. False
B. Trick question! How the Product is built (including its architecture and infrastructure) is the
responsibility of the Developers. So the Product Owner cannot delegate this responsibility.
149
Questions
If the workload should require this, the Product Owner accountability can be shared by two or more
persons.
a. True, as long as it is not a group or a committee.
b. True, because Product Owners can delegate work.
c. False, as the Product Owner can only be one person.
C. The Scrum Guide v2020 is very explicit about this aspect: “The Product Owner is one person, not a
committee.”
150
Questions
What does the Product Owner manage?

a. The Product Backlog.
b. The Sprint backlog.
c. The Developers.
d. All of the above.
e. None of the above
A. The Product Owner manages the Product Backlog as the Scrum Guide v2020 explains: "The
Product Owner is also accountable for effective Product Backlog management."
151
Questions
The Stakeholders are unhappy about the transparency of the work the Scrum Team will do next. What
should the Product Owner do to improve this?
a. Ask the Developers to talk to the Stakeholders directly.
b. Order the Product Backlog and improve the clarity of the items.
c. Ensure the Developers understand the items in the Product Backlog to the level needed.
B. All future work on the Product comes from the Product Backlog. The Scrum Guide v2020 explains
that the Product Backlog “is the single source of work undertaken by the Scrum Team.” The Product
Owner must ensure that the Product Backlog is visible, transparent, and clear to all.
152
Developers
- Developers are the people in the Scrum Team that are committed to creating any aspect of a
usable Increment each Sprint. Who have all the skills in order to do the work needed.
- The specific skills needed by the Developers are often broad and will vary with the domain of work.
However, the Developers are always accountable for:
- Creating a plan for the Sprint, the Sprint Backlog;
- Instilling quality by adhering to a Definition of Done;
- Adapting their plan each day toward the Sprint Goal; and,
- Holding each other accountable as professionals.
- It is possible for the Product Owner or the Scrum Master to be part of the Developers if they are
doing the work of the Sprint Backlog. But this is not really recommended because then it would be a
mixture between the roles and responsibilities.
153
Questions
There are no titles or hierarchies within the Scrum Team except for the person or persons responsible
for testing.
a. True
b. False
B. Notice the "except" in the question. Scrum recognizes no titles, sub-teams, or hierarchies
regardless of the work being performed, including testing. The Scrum Guide v2020 explains: “within a
Scrum Team, there are no sub-teams or hierarchies.”
154
Questions
Who is responsible for creating potential releasable increment?

a. The Developers, but only if the Scrum Master is happy with the technical solution proposed.
b. The Developers.
c. The Scrum Master.
d. The Product Owner.
B. The Scrum Guide v2020 explains: “Developers are the people in the Scrum Team that are
committed to creating any aspect of a usable Increment each Sprint.”
155
Questions
Scrum Teams are cross-functional. What does this mean?

a. Every Scrum Team member has all the skills required to create the Product. This is useful in case
somebody is absent.
b. Scrum Teams can decide which skills they want to learn.
c. The Scrum Team, as a whole, has all the skills to create the Product.
C. The Scrum Guide v2020 explains: “Scrum Teams are cross-functional, meaning the members have
all the skills necessary to create value each Sprint.”
156
Questions
Can the testers organize themselves as a sub-team of the Scrum Team?

a. Yes, but only if the rest of the Scrum Team agrees.
b. Yes, because the Testing Team is anyway external to the Scrum Team.
c. No, because the Scrum Team is not responsible for testing.
d. No, because the Scrum Team cannot have sub-teams.
D. Scrum recognizes no sub-teams in the Scrum Team.
157
Questions
Who should decide which approach and tools to use for testing the Increment?
a. The Lead QA Specialist in the Scrum Team.
b. The Lead Developer.
c. The Developers of the Scrum Team.
d. The Product Owner.
e. The Scrum Master.
C. The Developers building the Product should decide which is the best approach to test the
Increment.
158
Questions
What is the desired size of a Scrum Team?

a. 5 people
b. 10 or fewer people
c. 3-7 people
B. The Scrum Guide explains: “The Scrum Team is small enough to remain nimble and large enough
to complete significant work within a Sprint, typically 10 or fewer people.”
159
Questions
A Scrum Team has 15 people from different departments within the organization. Is this allowed in
Scrum?
a. Yes, there are no restrictions, only recommendations.
b. Yes, but only if the Scrum Master agrees.
c. No, the group of people needs to be divided into two Scrum Teams.
A. The Scrum Guide recommends not having more than 10 people in a Scrum Team and explains the
risks. However, this is not a hard rule, and there are cases when it makes sense to have a large
Scrum Team due to the complexity of the work and the skills required.
160
Questions
What are the most important benefits of self-managing Scrum Teams?

a. None. Teams should be directed from outside.
b. Adherence rules and guidelines, accurate estimates, respect.
c. Increased productivity, commitment, accountability, creativity.
C.
161
Questions
What should the Developers do towards the end of the Sprint?

a. Stop developing new features so that Testers have enough time to test.
b. Work on items in the Sprint Backlog.
c. Inform the Product Owner about the Sprint status.
d. Prepare the next Sprint Planning meeting and the next Sprint Backlog.
e. Help the Product Owner write technical Product Backlog Items.
B. Developers should continue working on items in the Sprint Backlog to reach the Sprint Goal and
have a releasable Product Increment.
162
Scrum Master
- The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide.
- They do this by helping everyone understand Scrum theory and practice, both within the Scrum
Team and the organization.
- The Scrum Master helps those outside the Scrum Team (for example the Stakeholders)
understand which of their interactions with the Scrum Team are helpful and which aren't.
- The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling
the Scrum Team to improve its practices, within the Scrum framework.
- Scrum Masters are true leaders who serve the Scrum Team and the larger organization.
163
Scrum Master serves the Scrum Team
- Coaching the team members in self-management and cross-functionality;

- Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
- Causing the removal of impediments to the Scrum Team’s progress; and,
- Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.
164
Scrum Master serves the Product Owner
- Helping find techniques for effective Product Goal definition and Product Backlog management;
- Helping the Scrum Team understand the need for clear and concise Product Backlog items;
- Helping establish empirical product planning for a complex environment; and,
- Facilitating stakeholder collaboration as requested or needed.
165
Scrum Master serves the Organization
- Leading, training, and coaching the organization in its Scrum adoption;

- Planning and advising Scrum implementations within the organization;
- Helping employees and stakeholders understand and enact an empirical approach for complex
work; and,
- Removing barriers between stakeholders and Scrum Teams.
166
The Scrum Master Acts as a
- A Servant Leader whose focus is on the needs of the team members and the people they provide
value to (the customer) with the goal of achieving results in line with the organization’s values,
principles, and business objectives.
- A Facilitator by setting the stage and providing clear boundaries in which the team can collaborate.
- A Coach coaching the individual with a focus on mindset and behavior, the team in continuous
improvement and the organization in truly collaborating with the Scrum team.
- A Manager responsible for managing impediments, eliminate waste, managing the process,
managing the team's health, managing the boundaries of self-organization, and managing the
culture.
167
The Scrum Master Acts as a
- A Mentor that transfers Agile knowledge and experience to the team.
- A Teacher to ensure Scrum and other relevant methods are understood and enacted.
- An Impediment Remover solving blocking issues to the team's progress, taking into account the
self-organizing capabilities of the Developers.
- A Change Agent to enable a culture in which Scrum Teams can flourish.
168
The 8 Misunderstood Stances of a Scrum Master
- A Scribe. Taking notes during Scrum events. Writing down the entire Sprint plan, daily plan,
refinement discussions and Retrospective commitments. I’ve actually experienced a customer that
expected the “Scrum Master” to act as a scribe for 4 hours per week…
- A Secretary. Planning all the Scrum events in everyone’s agenda. Responsible for keeping the
teams’ schedule with holidays and days off up-to-date.
- The Scrum Police. Rigorously following the rules of Scrum without any empathy for the team’s
current situation and context. If you’re not acting according to the Scrum Guide you’re doing it
wrong. Period.
- The Team Boss. The so-called “servant-leader”, but actually just the boss of the team. The boss
who hires and fires. The boss who decides if someone deserves a salary increase.
169
The 8 Misunderstood Stances of a Scrum Master
- The Admin. If you need a change in JIRA, TFS or any other tool: the Scrum Master is your friend.
He (or she) knows every workflow by heart.
- The Chairman. Every morning the team provides a status update to the chairman of the Daily
Scrum. This offers the Scrum Master the necessary information to write the daily status report to
his/her superiors.
- A Super Hero. It’s a bird. It’s a plane. It’s the Super Scrum Master!!! Solving all your impediments
before it actually even was an impediment. The hero is addicted to the adrenaline of solving
“problems.” It’s not about the team, it’s about increasing his status as a hero.
- The Coffee Clerk. There’s nothing wrong with getting coffee for your team members. This is very
collegial. But if you’re main purpose during the day is providing the team with coffee… then you’re
missing the point of being a Scrum Master.
170
Questions
Who is responsible for Product planning?

b. The Scrum Master
c. The Stakeholders
A.
171
Questions
The Developers cannot find an agreement on which technical solution to use. Who is responsible for
resolving the impediment and making the technical decision?
b. The Scrum Master
c. The Developers
C. The Developers is responsible for making technical decisions. While the Scrum Master could assist
the team in resolving the impediment, the Scrum Master cannot make the technical decision.
172
Questions
The Developers want to split into sub-teams: Developers and Testers. What should the Scrum Master
do in this situation?
a. Encourage this approach, as the Scrum Team is self-managing and knows better how to perform
the work.
b. Advice against this and coach the Scrum Team to take ownership of the Product they build as a
team.
c. Encourage this approach, as this makes the roles and responsibilities within the Scrum Team
clearer.
B. Accountability belongs to the Scrum Team as a whole. There are no sub-teams in the Scrum
Team, and Scrum does not recognize any titles or hierarchies.
173
Questions
The Scrum Master should reduce the Scrum team's workload and take care of arranging meetings,
booking rooms, and sending invitations to Scrum events when requested or needed.
a. True
b. False
B. The Scrum Master is not the secretary of the Scrum Team. The Scrum Master just needs to make
sure that the events happen when requested or needed.
174
Questions
All Developers are working remotely. A video conferencing system is available, but the effort to set up
the conference for the Daily Scrum is significant, and nobody takes reasonability for doing the
preparation. What should the Scrum Master do?
a. Take the responsibility to organize the Daily Scrum, send invitations, and start the video conference
on time.
b. Ask the Developers to rotate the duty of organizing the Daily Scrum.
c. Inform the Management that the conferencing system is outdated and hard to use.
d. Coach the Developers to self-manage and to find the solution that works best for them.
e. Assign this responsibility to one of the Developers and make them accountable.
D.
175
Questions
The Scrum Master can also be a Developer and work on items in the Sprint Backlog.
a. True
b. False
A. There is no rule saying that the Scrum Master cannot be a Developer as well. Take into
consideration that this practice is not recommended as mixing the accountabilities can lead to other
problems, such as a lack of focus or neglecting one accountability in favor of the other.
176
Questions
The Scrum Master role is considered a management position in Scrum.

a. True
b. False
A. You can find this aspect in some of the trick questions in the exam. The Scrum Master does
manage the Scrum process and is considered a management position in Scrum. Do not confuse this
with the traditional idea of a manager that has a form of authority over people.
177
SESSION 9
SCALING SCRUM
178
Multiple Scrum Teams work on the same Product
- When there is one Product there can only be one Product Backlog and only one Product Owner.
- There will be a new Developer team and a Scrum Master. The existing Scrum Master can handle
both teams, or can be two different persons. The Product Owner will be the same person.
- During the Sprint Planning meeting, the representatives from each Scrum Team and the Product
Owner will collaborate on finding solutions that make sense for them.
- When multiple Scrum Teams start working on the same Product, different challenges arise. The key
concern, in this case, is to reduce dependencies between the Teams.
- Generally, it is less of a concern if there's enough work for every Team or how is the velocity of
every team.
179
Nexus Framework
https://www.Scrum.org/resources/nexus-guide 180
How many Product Owners are there?
- The rule is pretty simple. For one Product, there can only be one Product Backlog and one
Product Owner.
- Only one person is responsible
- Clear decision-making process.
- There is no Chief Product Owner or Proxy Product Owner
181
The Definition of Done
- When multiple teams work on the same Product, they must coordinate to create an integrated
Product Increment. This means that any work they create must be integrated into a single Product
Increment by the end of the Sprint.
- Everybody needs to understand what "Done" means. So the Scrum teams must define a
common "Definition of Done", that all the teams must respect. The Product Increment is "Done" only
when it is integrated, usable and valuable.
- Individual teams may choose to apply a more stringent "Definition of Done" within their own teams.
As long as it does not conflict with the common "Definition of Done" that was defined for all the
teams.
182
The Sprint length
- A common misconception is, when multiple teams work on the same Product, it is commonly
thought that the Sprints must be aligned, meaning that they must start and end at the same time,
so have the same length. Scrum does not have a requirement that states this.
- The only requirement is that the work should be integrated by the end of the Sprint.
- If all the teams have the same Sprint duration and start and end date, this process is a bit easier to
manage especially in some organizations. If the Scrum Teams have different Sprint lengths, so the
Sprints are not aligned. The integration process may be harder but still within the Scrum rules.
183
The Sprint length
- There are no integration Sprints, testing Sprints or hardening Sprints in a Scrum.
- Any integration work or testing work must be done within the normal Sprint.
- There are no gaps between Sprints and nothing happens after a Sprint, apart from the next Sprint
the starting.
184
Feature teams vs. Component teams
- The architecture of the shop is currently divided into three separate layers.
- There is the user interface, this is what you see and this makes it easier for the customers to
interact with the shop, to see products and to order them.
- Then there is the business logic layer which you don't see, but the application handles the
business logic and connects the user interface with the database.
- And finally, the database contains all the information regarding the products, the customers
and orders, so everything that needs to be persisted.
185
Feature teams
- For example, the feature is giving the customers the ability to order a Product. So a Product must be
visible on the website and then when the customer clicks on, buy it, the application must handle the
order in the database must store all this information for the processing or whatever the internal
processes are. So you have to go through all the layers in order to implement most of the features.
- So a Feature Team will work through all the layers of the application to fulfill a customer or user
need. A Feature Team is cross-functional and cross-component because it has all the skills
needed to complete the feature and does that by working through all the layers or components of
the application.
186
Component teams
- Component Team. Sometimes also referred to as the Layer Team is focused on single or
multiple components of the system.
- A Component Team alone will typically not be able to deliver new functionality, that alone will
fulfill a customer's need.
- For example, one Team would only handle the user interface, the UI, then that team alone would not
be able to process orders, because it would not know how to work with a database layer or with the
application layer and would have to rely on other teams to do their jobs.
187
Feature teams vs. Component teams
- Component Teams increases the dependencies between the teams and reduces the chances of
producing an Integrated Product Increment by the end of a Sprint.
- If one team for whatever reason, did not provide what they plan to by the end of the Sprint, then the
other teams cannot work on their end. So that can cause problems. And this is why it says that
typically the chances of producing an integrated Product Increment is lower when using Component
Team.
- Feature Teams are desirable, as they are closer to the Cross-Functional aspect as it is described in
the Scrum Guide. Nevertheless, Feature Teams are not mandatory in Scrum.
188
Questions
If two Scrum Teams inside the company work on different Products, they should share the same
Product Backlog to reduce complexity.
a. True
b. False
B. Complexity has nothing to do with the Product Backlog. Each Product has its own Product Backlog.
Only if two or more teams work on the same Product can a single Product Backlog be used.
189
Questions
How many Sprint Backlogs should be used if three Scrum Teams work on the same Product?
a. Exactly one
b. Two
c. Three
d. Four
C. Each Scrum Team will have its own Sprint Backlog.
190
Questions
Four Scrum Teams work on the same Product. What do they have in common?
a. Product Goal, Product Backlog, and Product Owner.
b. Sprint Goal, Sprint Backlog, and Definition of Done.
c. Product Goal, Product Backlog, Product Owner, and Scrum Master.
d. Product Goal, Sprint Backlog, and Product Owner.
A. The Scrum Guide explains that multiple Scrum Team working on the same Product “should share
the same Product Goal, Product Backlog, and Product Owner. […] They must mutually define and
comply with the same Definition of Done.“
191
Questions
What is the best way for multiple Scrum Teams to produce integrated Product Increments?
a. Each Scrum Team should specialize on a single layer of the application.
b. Each Scrum Team creates functionality throughout all technical layers of the application.
c. Let the Scrum Master decide which approach is most appropriate.
B. Having feature teams reduces dependencies and increases the chances of delivering a working
Increment.
192
Questions
Multiple teams in an organization work on the same Product. What is the main concern of the Product
Owner when managing the Product Backlog?
a. Understanding the dependencies between the Product Backlog Items.
b. Making sure all teams use the same units when sizing Product Backlog Items.
c. Helping the Scrum Teams analyze the work and break-down the Product Backlog Items into tasks.
d. Making sure all Scrum Teams send at least one Developer to the Product Backlog refinement
activity.
A. When multiple teams work on the same Product, the main concern is reducing the dependencies
between the teams.
193
Questions
If multiple teams work on the same Product, only one Product Backlog should be used, and there will
be a single Product Owner for all the teams.
a. True
b. False
A. Remember the rule: 1 Product = 1 Product Backlog = 1 Product Owner
194
SESSION 10
TERMS AND TOOLS USED
IN AGILE AND SCRUM
PROJECTS
195
Burndown chart
- Once a team has assigned a story point
value to all of the user stories in the sprint
backlog, they can use burndown charts to
get a handle on how the project is
progressing.
- A burndown chart is a simple line chart
that shows how many story points are
completed each day during the sprint.
- The burndown chart gives everybody a
clear sense of how much work is left to be
done at any time.
- Using a burndown chart, it’s clear to
everyone on the team how close they are
to achieving their sprint goals.
196
Burndown chart
- Burndown Charts are only related to the
remaining work
- NOT related to the project costs or the
business value
- NOT related to the productivity of the team
or to the individual team member.
197
Burnup chart
- Another way to track your progress during
a sprint is to use a burn-up chart.
- Instead of subtracting the number you’ve
completed from the number you committed
to, burn-ups track a cumulative total
throughout the sprint and show the total
committed scope on a separate line.
- When stories are added or deleted from
the scope it’s obvious by looking at the
scope line.
- When stories are put into the “Done”
column on the task board, that’s easy to see
too, by looking at the total number of
points burned up in the sprint.
- Because the scope is tracked on a different
line from the number of points
Scrum does not enforce any of the reporting
accomplished, it’s clearer when the scope tools and charts mentioned. It is totally up to 198
is changing. the Scrum Team which tools to use.
Technical Debt
Example
- You need to create a presentation for a company and you only have one hour. You will begin by
downloading images, logos maybe some documents and putting all these files on your desktop.
Next, you will put a presentation together and finish just in time. Your desktop is a mess but the
presentation is done.
- A few minutes later you receive a phone call asking you to create another presentation for another
company. Again you start downloading a lot of images, logos, documents and putting everything on
top of the existing files on your desktop. Now you have your desktop filled with a lot of images. But
you are having a hard time identifying which image is for which presentation.
- To make things worse, you need to leave the office and a colleague offers to take over. Now your
colleague has to split the files apart and figure out which file is for which presentation. He gets the
job done but three hours were invested in creating the second presentation.
- The fact that the files were not organized after the first presentation was finished, made
everything take much longer. This is Technical Debt also known as Design Debt or Code
Debt.
199
Technical Debt
- Unresolved technical aspects from the past come back and haunt you today.
- Initially, you only expected to do one presentation and if this was the case ordering the files after the
presentation was over, would have taken more time, not a lot but a bit more.
200
Technical Debt
- Technical Debt is something that should be continuously dealt with and not postponed.
- It is part of the development approach and it is a continuous process similar to the architecture of
the Product, which is continually being worked on and improved.
- When developing software, often changes need to be made on a Software Product and due to time
constraints => shortcuts are taken.
- Solving technical issues is not always as simple as putting files in a folder. While in the short term
the software product seems to work. The Developers will get the impediments upon the
shortcuts they have taken in the past. This is the Technical Debt.
201
How to deal with Technical Debt as a Scrum Team?
- First of all transparency must be ensured.
- The Developers knows best about the Technical Debt that has been built into the product and must
constantly communicate and remind others in the Team especially the Product Owner about
the current issues.
- The team needs to collaborate with a Product Owner and try to reduce the Technical Debt in
every Sprint. If any actions are identified in order to reduce the Technical Debt, this should be part
of the Product Backlog and sometimes even adapting the "Definition of Done" makes sense to
include stricter requirements that will prevent more debt to accumulate in the Product.
- Technical Debt is something undesirable but every Product will eventually have it.
202
The "cone of uncertainty"
- The term Cone of Uncertainty is used in software development where the technical and business
environments are constantly evolving.
- At the start of a project, comparatively little is known about the Product or work results and the
uncertainty is high.
- As more is learned, uncertainty tends to decrease.
203
Velocity
- At the end of each sprint, you can count
the total number of story points that have PRODUCT BACKLOG SPRINT BACKLOG
been accepted by the Product Owner. The
number of points per sprint is called the Create homepage 8
velocity, and it’s a great way to gauge
Display one product 13
how consistently the team is delivering
work.
Order form 8
- During the Sprint Planning meeting, the
Developers will select a number of
29
Product Backlog Items or User Stories
from the Product Backlog.
Contact page
- If each has an estimation in story points at
the end of the Sprint, it is easy to see how Display multi products
many User Stories were completed and
what is the total number of story points Add to cart
for the Sprint.
204
Velocity Chart
- Many teams plot their velocity per sprint

as a bar chart so they can see how they
did across multiple sprints.
- Since each team’s scale for estimating
story points is different, you can’t use
velocity to compare teams to one
another. But you can use it to help figure
out how much work your team should
commit to based on their past
performance.
206
Sustainable pace
- When doing development work, it is important to be able to have a constant output.
- If the team is delivering more features but, for example, is working overtime, this is not a
sustainable pace.
- While one Sprint may have good results, others may have rather poor. Working overtime to
complete a Sprint or reach the Sprint Goal is not acceptable in Scrum.
- Scrum is about finding a good balance and keeping everyone happy. Think about if the team is
constantly under stress, the developers will be unhappy. Some may sooner or later decide to leave
the team/company.
- There might be short-time gains but in the long-term this cannot be good.
207
SESSION 11
FREQUENTLY ASKED
SCRUM QUESTIONS &
SCRUM MYTHS
209
Definition of Done
QUESTION: At what stage is the Definition of Done created?
ANSWER:
- This part with kickstarting the first Scrum Sprint (including the Definition of Done - DoD) is not
explained in the guide. The Guide explains the rules of the game, not every possible detail, which
means that this is left to the team to decide. Typically a definition of done may already exist within
the Development Organization (in one form or the other).
210
Definition of Done
QUESTION: Who creates the Definition of Done?
ANSWER:
- There are two possible options:
- 1) The development organization. Typically most organizations have already development
processes in place, standards that must be followed, procedures and quality standards. While
it may not be called a Definition of Done yet, the idea is quite similar.
- 2) The team - The Scrum Team must define a definition of "Done" appropriate for the Product
if there is none defined by the development organization. While it is not clearly explained in
the Scrum Guide, the Scrum Team may define rules and quality criteria that are stricter but still
following the Definition of Done that the organization has.
211
Definition of Done
QUESTION: During which Scrum Event the "Definition of Done" discussed and finalized?
ANSWER:
- The Definition of Done is never final. The Sprint Retrospective is used for adapting the Definition of
Done but this may happen anytime. There is no need for a specific event to do so. The team is self-
managing.
212
Scrum Mythbusters
Myth: The Scrum Master must be present during the Daily Scrum
- The Daily Scrum is a 15-minute event for the Developers of the Scrum Team.
- The Developers can select whatever structure and techniques they want, as long as their Daily
Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day
of work. This creates focus and improves self-management.
213
Scrum Mythbusters
Myth: The Sprint Backlog can’t change during the Sprint
- Instead of trying to keep the Sprint Backlog stable, encourage Developers to change, refine and
improve items as they go.
- If new work is discovered, the Developers adds it to the Sprint Backlog. If work proves to be
unnecessary, it is removed. It’s up to the Developers to make these changes and collaborate with
the Product Owner where necessary.
- Changes done to the Sprint Backlog are are always done with the purpose of achieving the Sprint
Goal by delivering a “Done” Increment.
214
Scrum Mythbusters
Myth: In Scrum, new features are delivered only at the end of the Sprint
- An Increment may be delivered to stakeholders prior to the end of the Sprint.

- There is nothing in the Scrum Framework that prevents Scrum Teams from releasing working
software throughout the Sprint, as long as the Product Owner is involved in the decision to release.
In fact, Scrum encourages it!
215
Scrum Mythbusters
Myth: In Scrum, the Product Backlog has to consist of User Stories
- The Product Backlog lists all features, functions, requirements, enhancements, and fixes that
constitute the changes to be made to the product in future releases. More succinctly put, it lists all
the work that is deemed necessary for the product.
- How Scrum Teams decide to capture this work is entirely up to them. They can write User Stories,
they can use a bunch of keywords, write use cases or even draw pictures.
- The Scrum Framework only describes what needs to be done, but does not enforce how it needs to
be done. The realities of product development are too complex for a one-size-fits-all solution, silver
bullets, and generic techniques.
216
Scrum Mythbusters
Myth: In Scrum, the Product Backlog is prioritized
- The Scrum Guide states that the Product Backlog is an ‘ordered list’ of everything that is known to
be needed in the Product. It is not a prioritized list.
- The focus on ordering (over ‘prioritization’) emphasizes that the Product Backlog must be
considered as a whole when re-order items. The Product Backlog expresses the order of delivery of
items, and thus how value is generated over time.
217
Scrum Mythbusters
Myth: The Scrum Master Must Resolve Every Problem
- Impediments are those problems that hinder a Developers’s progress towards the Sprint Goal and
lie outside of their capability to resolve on their own.
- Many categories of problems are resolvable by Developerss, like clarifying unclear specifications,
fixing problems in a deployment or even the resolution of a conflict within the team.
- Before solving a problem, consider if you’re really helping to the Developers to grow in their ability to
resolve similar problems on their own. A good guideline to remember is: “A Scrum Master should
reveal, not resolve.”
218
Scrum Mythbusters
Myth: The Scrum Master is a Junior Agile Coach
- Coaching the Scrum Team in self-organization and cross-functionality, helping the Product Owner
find techniques for effective Product Backlog management and supporting the organization in
delivering high-value products through the empirical process established through Scrum.
- “The chances of successful Scrum adoption will increase drastically when you consider your Scrum
Master as the true “inside out” change facilitators!”
- “Organisational change should be driven from the inside-out by people that are truly part of the
teams.”
219
Scrum Mythbusters
Myth: Story Points are required in Scrum
- Scrum Teams should apply some sort of ‘estimation’, there is no mention of Story Points, hours,
ideal days, gut feeling, t-shirt sizes or any other unit for that matter. The Scrum Guide does remind
us to use an approach that respects the complexity of software development and to not let
estimation replace the importance of empiricism itself.
220
Scrum Mythbusters
Myth: In Scrum, there is no planning
- During the Sprint Planning, the Scrum Team collaboratively plans the work that will be performed in
the Sprint.
- During the Daily Scrum, the Developers plans work for the next 24 hours.
- During the Sprint Review, the attendees collaboratively decide on the next things that could be done
to optimize value(‘What’s Next?’).
- During the Sprint Retrospective, the team plans potential improvements in collaboration and product
quality and how to implement these improvements.
- …
- “Planning needs to be a collaborative effort between everyone involved.” Whenever we talk of plans
in Scrum, we talk about plans as “shared understanding”, not as “documents”.
221
Scrum Mythbusters
Myth: The Sprint Review is a Demo
- The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future
adaptations. The Scrum Team presents the results of their work to key stakeholders and progress
toward the Product Goal is discussed.
- Based on this information, attendees collaborate on what to do next. The Product Backlog may also
be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum
Team should avoid limiting it to a presentation.
222
Scrum Mythbusters
Myth: Only The Product Owner Interacts With Stakeholders
- The Product Owner is responsible for maximizing the value of the product resulting from work of the
Scrum Team. This work is made transparent on the Product Backlog, and is managed by the
Product Owner. In order to determine what work is valuable and in what order, the input of
stakeholders is obviously needed.
- We prefer to explain the Product Owner as the person responsible for including stakeholders in the
process of collaborative discovery.
223
Scrum Mythbusters
Myth: The Scrum Master can’t remove people from the Scrum Team
- The Scrum Master is responsible for the removal of impediments that hinder the progress of a
Developers.
- People should never be called ‘impediments’. Instead, the dynamic between individuals can get in
the way of working with Scrum. Not the person, but this dynamic is the impediment.
- “Rather than decreasing trust, removal can be a powerful signal to help restore trust.”
- “It’s also good to keep in mind that a person is not being fired from the company, but removed from
a team.”
224
Scrum Mythbusters
Myth: The Product Backlog is maintained exclusively by the Product Owner
- The Product Owner may do the above work or may delegate the responsibility to others.
Regardless, the Product Owner remains accountable.
225
Scrum Mythbusters
Myth: A Sprint Goal Is Optional In Scrum
- “Find Sprint Goals that offer guidance during the Sprint and promote collaboration in your team.”
- “The lack of Sprint Goals is one of the biggest impediments facing Scrum Teams today.”
226
Scrum Mythbusters
Myth: You Can’t Do Projects With Scrum
- “Each Sprint may be considered a project with no more than a one-month horizon. Like projects,
Sprints are used to accomplish something.”
227

Session 12 - 13 - Agile - Scrum in A Nutshell 92-227

Uploaded by

Document Information

Original Description:

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

Session 12 - 13 - Agile - Scrum in A Nutshell 92-227

Uploaded by

Copyright:

Available Formats

AGILE & Scrum

Section 2 The Agile manifesto and the birth of Scrum Page 6

Section 3 Overview of the Scrum Framework Page 11

Section 4 Scrum Theory Page 23

Section 5 Scrum Values Page 28

Section 6 Scrum Artifacts Page 45

Section 7 Scrum Events Page 103

Section 8 The Scrum Team and accountabilities Page 143

Section 9 Scaling Scrum Page 178

The values and ideas contained in this manifesto were

Describes a framework for dealing with complex

With constantly changing market conditions and

It is impossible to predict from the beginning how a

There is a bit of all the steps required to develop a

And to put them in a fixed length iteration, call a

Sprint 1 Sprint 2 Sprint 3

The Scrum framework is purposefully incomplete. Rather than provide people

And Scrum is definitely not a process, a technique, a definitive method or a methodology or

Scrum is a lightweight framework that helps people, teams and organizations

The Scrum framework is purposefully incomplete. Rather than provide people

- Scrum is lightweight. It is simple to understand but it is difficult to master.

Scrum has been used to:

Scrum has been used to:

- The Scrum values make the team more effective

- Every Scrum role has a distinct accountability, and this is a commitment:

- Scrum is a framework for developing complex products

Complete the following sentence: The Scrum Team consists of _____ .

Complete the following sentence: Scrum can be used for _____

Complete the following sentence: Scrum is founded on _____

D. “Scrum is founded on empiricism and lean thinking.”

Complete the following sentence: The Scrum framework consists of _____

How does Scrum control risk?

D. The empirical Scrum pillars are transparency, inspection, and adaptation.

Which of the following are the five Scrum values?

PRODUCT BACKLOG PRODUCT GOAL

SPRINT BACKLOG SPRINT GOAL

INCREMENT DEFINITION OF DONE

As a customer interested in ABC

CREATE HOMEPAGE ACCEPTANCE CRITERIA

As a customer interested in ABC - I should see the logo of ABC

DISPLAY ONE PRODUCT BACKGROUND

CREATE HOMEPAGE ACCEPTANCE CRITERIA

As a customer interested in ABC - I should see the logo of ABC

As a customer interested in ABC - I should see the logo of ABC

B. The Scrum Guide refers to the Product Backlog as an ordered list.

How should the Product Backlog be ordered?

SPRINT GOAL SPRINT BACKLOG

PRODUCT BACKLOG SPRINT BACKLOG

Have a great picnic GOAL FOCUS

Search for place

Who should create the Sprint plan?

Who decides when to update the Sprint Backlog?

What can the Sprint Backlog contain?

Definition of Done Acceptance Criteria

- Applies to every PBI & Product Increment - Applies to a single PBI

What is the responsibility of the Developers during the Sprint?

Every Product Increment is a step toward reaching the Product Goal.

Which of the following represents the commitment for the Increment?

Sprint Planning Daily Scrum Sprint Review

SPRINT GOAL SPRINT BACKLOG

How many Sprints are planned in the Sprint Planning event?

A. The purpose of the Sprint Planning is to plan a single Sprint.