Scrum

Book of
Knowledge
An unofficial compilation of a few scrum knowledge
sources in order to provide a comprehensive and short
description of Scrum.
Written by Illya Pavlichenko, CSM, CSPO, CSP, PSM I, PMI-ACP
Email: fancydev@gmail.com, scalestudy.com@gmail.com
January 2013, Version 1.0

Why this document?

There are so many sources of Scrum that you can find in web. ScrumAlliance has its own Scrum
Atlas, the creators of Scrum (Ken Schwaber and Jeff Sutherland) own the Scrum Guide. Which
one is correct and the true source of knowledge? My intention is to create a compilation of many
Scrum sources and thus give you a detailed and comprehensive Scrum description. More than
that, as the owner of ScaleStudy, I want to give you an ability to check your Scrum knowledge with
a help of Scrum questions. You can find them at the end of the document.
This is the living document and will be frequently updated.
This document is a compilation of several sources:
1.
2.
3.
4.

Core Scrum (ScrumAlliance)

Scrum Guide (Scrum.org)
Do Better Scrum-v2 (ScrumSense)
ScaleStudy questions on Scrum (ScaleStudy.com)

Future version will include compilation of the following sources:

1.
2.
3.
4.
5.

Agile Estimation and Planning (Mike Cohn)

User Stories Applied (Mike Cohn)
Essential Scrum (Kenneth S. Rubin)
Agile Product Management With Scrum (Roman Pinchler)
Other (please send me an email to suggest a book)

Scrum Basics
Scrum is a Framework within which people can address Complex Adaptive Problems, while
productively and creatively delivering products of the highest possible value.
Characteristics:
1. Lightweight
2. Simple to understand
3. Extremely difficult to master

Scrum Theory
Scrum is founded on Empirical Process Control Theory, or Empiricism. Empiricism asserts that
knowledge comes from experience and making decisions based on what is known. Scrum
employs an Iterative, Incremental approach to optimize predictability and control risk.
Scrum is based on Transparency, Inspection, and Adaptation.

Creators of Scrum

Ken Schwaber
Jeff Sutherland

Scrum and Agile

Scrum is the best-known of the Agile frameworks. It is the source of much of the thinking behind
the values and principles of the Agile Manifesto, which form a common basis for all of these
approaches. It is frequently used in conjunction with Extreme Programming (XP).

Why is Scrum silent on software development practices?

Scrum does not attempt to instruct teams how to do their work. Scrum expects teams to do
whatever necessary to deliver the desired product. It empowers them to do so. Development
practices and tools change and improve all the time and good teams will constantly work to take
advantage of these.

How does Scrum map to traditional methods?

The short answer is that is does not. Agile and Scrum are based on a different paradigm.
Founders Jeff Sutherland and Ken Schwaber have frequently stated that attempts to map defined
to empirical methods are futile.

Scrum Values
All work performed in Scrum needs a firm basis of values to serve as a foundation for the team's
process and principles. Through the use of teamwork and continuous improvement, Scrum both
creates these values and relies on them.

The values are:

1.
2.
3.
4.
5.

Focus
Courage
Openness
Commitment
Respect.

Scrum Framework
Scrum Framework consists of:
1.
2.
3.
4.

Roles
Events
Artifacts
Rules that bind them together

1.1 Roles
The Scrum Team consists of:
1. The Product Owner
2. The Development Team
3. The Scrum Master

1.1.1 The Scrum Team

Characteristics:
Self-organizing
Self-organizing teams choose how best to accomplish their work, rather than being
directed by others outside the team. Self-organization does not at all imply a laissezfaire approach; on the contrary, self-organized teams are highly disciplined. They are
given full autonomy and carry correspondingly greater responsibility for delivery
accordance with their own commitments.
Cross-functional
Cross-functional teams have all competencies needed to accomplish the work
without depending on others not part of the team. There is no dictated leadership
hierarchy within the team members.
Responsibilities:
1. Sprint Backlog is created by the collaborative work of the entire Scrum Team
2. Accountable for the overall project success
Owns:
1.
2.
3.
4.

Definition of Done
Retrospective Meeting
Sprint Planning Meeting
Sprint Goal

1.1.2 The Product Owner

Description:
The Product Owner is the single individual who is responsible for drawing out the most
valuable possible product by the desired date. This is done by managing the flow of work
into the team, selecting and refining items from the Product Backlog. The Product Owner
maintains the Product Backlog and ensures that everyone knows what is on it and what
the priorities are. The Product Owner may be supported by other individuals but must be a
single person.
The Product Owner, by choosing what the Development Team should do next and what to
defer, makes the scope versus schedule decisions to lead to the best possible product.
Characteristics:
Responsibilities:
1.
2.
3.
4.
5.
6.

Maximizing the value of the product

Return on Investment (ROI)
Prioritizing the items in the Product Backlog
Grooming(refining) items in the Product Backlog
Ultimately accountable for the Product Backlog items
The Product Owner tracks this total work remaining at least for every Sprint Review
to reach a goal
7. Accepting the software at the end of every Sprint
8. Managing the Release Plan (Optional: Scrum does not mandate creating a Release
Plan)
Owns:
1. Product Backlog
2. Release Plan (Roadmap Plan) Optional: Scrum does not mandate creating a
Release Plan
3. Product Vision
4. Review Meeting
5. Grooming activities
6. Budget
7. Product Increment

1.1.3 The Development Team

Description:
The Development Team is made up of the professionals who do the work of delivering
the Product Increment. They self-organize to accomplish the work. Development team
members are expected to be available to the project full time. Scrum requires that the
Development Team be a cross-functional group of people who, among them, have all the
necessary skills to deliver each increment of the product. The Development Team members
have the responsibility to self-organize to accomplish the Sprint goal, producing each new
Product Increment according to each Sprint Plan.
Characteristics:
Self-organizing. No one (not even the Scrum Master) tells the Development Team
how to turn Product Backlog into Increments of potentially releasable functionality;
Cross-functional, with all of the skills as a team necessary to create a product
Increment;
Does not contain sub-teams dedicated to particular domains like testing or business
analysis.
No titles for Development Team members other than Developer.
Optimal size is 7 2 (ScrumAlliance), 63 (ScrumGuide)
Empowered by the organization to organize and manage their own work
Accountability belongs to the Development Team as a whole

Responsibilities:
1.
2.
3.
4.

Accountable for creating the Increment of a Product

Selects the items from the Product Backlog for the Sprint
The Development Team is responsible for all estimates
The Development Team tracks the sum of the work remained in Sprint (Optionally
by using burndown, burnup and other projective practices)

Owns:
1. Sprint Backlog
2. Daily Scrum Meeting
3. Daily Plan

1.1.3 The Scrum Master

Description:
The ScrumMaster is a "servant leader", helping the rest of the Scrum Team follow their
process. The ScrumMaster must have a good understanding of the Scrum framework and
the ability to train others in its subtleties. The ScrumMaster works with the Product Owner to
help the Product Owner understand how to create and maintain the Product Backlog. He
works with the Development Team to find and implement the technical practices that will
allow them to get to done at the end of each Sprint. He works with the whole Scrum Team to
evolve the Definition of Done. Another responsibility of the ScrumMaster is to see that
impediments to the teams progress are removed. The ScrumMaster acts as a coach for
the Scrum Team, helping them to execute the Scrum process.
Characteristics:

Servant-leader
Facilitator
Coach
Trainer
Teacher
Protector
Mentor
Bulldozer

Responsibilities:
1. Responsible for ensuring Scrum is understood and enacted. Scrum Masters do
this by ensuring that the Scrum Team adheres to Scrum theory, practices, and
rules
2. The Scrum Master helps those outside the Scrum Team understand which of
their interactions with the Scrum Team are helpful and which arent. The Scrum
Master helps everyone change these interactions to maximize the value created
by the Scrum Team
3. Finds techniques for effective Product Backlog management
4. Clearly communicates vision, goals, and Product Backlog items to the
Development Team
5. Teaches the Scrum Team to create clear and concise Product Backlog items
6. Understands long-term product planning in an empirical environment
7. Understands and practices agility
8. Facilitates Scrum events as requested or needed
9. Ensures that the Development Team has the Daily Scrum meeting,
10. Coaches the Development Team in self-organization and cross-functionality
11. Teaches and leads the Development Team to create high-value products
12. Removes impediments to the Development Teams progress
13. Coaches the Development Team in organizational environments in which Scrum
is not yet fully adopted and understood
14. Leads and coaches the organization in its Scrum adoption
15. Plans Scrum implementations within the organization
16. Helps employees and stakeholders understand and enact Scrum and empirical
product development

17. Causes change that increases the productivity of the Scrum Team
18. Works with other Scrum Masters to increase the effectiveness of the application
of Scrum in the organization
19. Managing Impediment Backlog (Optional)
Owns:
1. Scrum Process
2. Impediment Backlog (Optional artifact)

1.2 Scrum Events

Rules:
1. Scrum uses time-boxed events, such that every event has a maximum duration.
2. Scrum contains the following meetings
Sprint Planning Meeting
Daily Scrum
The Sprint Review
The Sprint Retrospective
Grooming (Product Backlog Refinement)

1.2.1 The Sprint

Rules:
The heart of Scrum is a Sprint, a time-box of one month or less during which a
Done, useable, and potentially releasable product Increment is created
Sprints have consistent durations throughout a development effort
No changes are made that would affect the Sprint Goal during the Sprint
Development Team composition remains constant during the Sprint
Quality goals do not decrease during the Sprint
Scope may be clarified and re-negotiated between the Product Owner and
Development Team as more is learned
A Sprint can be cancelled before the Sprint time-box is over. Only the Product
Owner has the authority to cancel the Sprint, although he or she may do so under
influence from the stakeholders, the Development Team, or the Scrum Master
A Sprint would be cancelled if the Sprint Goal becomes obsolete

1.2.2 Sprint Planning Meeting

Description:
The work to be performed in the Sprint is planned at the Sprint Planning Meeting.
When
At the beginning
of the Sprint

Duration
Time-boxed to 8 hours for
a one-month Sprint.
For shorter Sprints, the
event is proportionately
shorter.

Inputs
1. Product Backlog
2. Latest Product Increment
3. Projected Capacity of the Development
Team
4. Past Performance of the Development
Team

1.
2.
3.
4.

Attendees
Product Owner
Scrum Master
Development Team
Other people to attend in
order to provide technical
or domain advice
(Optional)

Outputs
1. Sprint Goal
2. Sprint Backlog

Rules:
The Sprint Planning Meeting consists of two parts, each one being a time-box of one
half of the Sprint Planning Meeting duration.
1. What will be delivered in the Increment resulting from the upcoming Sprint?
In this part, the Development Team works to forecast the functionality that will be
developed during the Sprint. The Product Owner presents ordered Product Backlog
items to the Development Team and the entire Scrum Team collaborates on
understanding the work of the Sprint.

The number of items selected from the Product Backlog for the Sprint is
solely up to the Development Team. Only the Development Team can
assess what it can accomplish over the upcoming Sprint.
Sprint Goal

After the Development Team forecasts the Product Backlog items it will deliver
in the Sprint, the Scrum Team crafts a Sprint Goal. Sprint Goal is an objective
that will be met within the Sprint through the implementation of the Product
Backlog, and it provides guidance to the Development Team on why it is
building the Increment. The Sprint Goal gives the Development Team some
flexibility regarding the functionality implemented within the Sprint. As the
Development Team works, it keeps this goal in mind. In order to satisfy the
Sprint Goal, it implements the functionality and technology. If the work turns out
to be different than the Development Team expected, then they collaborate with
the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

2. How will the work needed to deliver the Increment be achieved?

Having selected the work of the Sprint, the Development Team decides how it will
build this functionality into a Done product Increment during the Sprint. The Product
Backlog items selected for this Sprint plus the plan for delivering them is called
the Sprint Backlog.
The Product Owner may be present during the second part of the Sprint
Planning Meeting to clarify the selected Product Backlog items and to help make
trade-offs. If the Development Team determines it has too much or too little work, it
may renegotiate the Sprint Backlog items with the Product Owner. The
Development Team may also invite other people to attend in order to provide technical
or domain advice.
Good Practices:

1.2.3 Daily Scrum

Description:
Daily Scrum improves communications, eliminates other meetings, identifies and removes
impediments to development, highlights and promotes quick decision-making, and improves
the Development Teams level of project knowledge. This is a key inspect and adapt
meeting.
When
Each day

Duration
15-minute time-boxed
event

1.
2.

3.
4.

Inputs
1. Impediments faced
2. Information about what have
been done since the last Daily
Scrum

Attendees
Development Team
Scrum Master
(Optional, but highly
desirable)
Product Owner
(Optional)
Other people as
observers (Optional)

Outputs
1. Identified Impediments
2. Plan for 24 hours

Rules:

The Daily Scrum is held at the same time and place each day to reduce complexity
During the meeting, each Development Team member explains:
1. What has been accomplished since the last meeting?
2. What will be done before the next meeting?
3. What obstacles are in the way?
There may be brief clarifying questions and answers, but there is no discussion of any
of these topics during the Daily Scrum. However, many teams meet right after the Daily
Scrum to work on any issues that have come up.
Only the Scrum Team members, including ScrumMaster and Product Owner, speak
during this meeting. Other interested parties can come and listen in.
The Scrum Master ensures that the Development Team has the meeting, but the
Development Team is responsible for conducting the Daily Scrum. The Scrum Master
teaches the Development Team to keep the Daily Scrum within the 15-minute timebox.
Note:
The Daily Scrum is not a report to management, nor to the Product Owner, nor to the
ScrumMaster. It is a communication meeting within the Development Team, to ensure
that they are all on the same page.
Good Practices:

1.2.3 Sprint Review

Description:
Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the
Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders
collaborate about what was done in the Sprint.
The Sprint Review is sometimes, and wrongly, called the sprint demo. While it does include
a demonstration of the new features the team has completed during the sprint, its primary
purpose is to inspect what the team has delivered and gather feedback from the attendees to
adapt the plan for the succeeding sprint. Thus it is much more than a demonstration.
When
Duration
At the end of the 4 hour time-boxed
Sprint
meeting for one-month
Sprints. Proportionately less
time is allocated for shorter
Sprints.

Inputs
1. Increment of Potentially
Shippable Product
2. Product Backlog
3. Metrics (optional)

1.
2.
3.
4.
5.

Attendees
Product Owner
Scrum Master
Development Team
Stakeholders
Other people (Optional)

Outputs
1. Revised Product Backlog that
defines the probable Product Backlog
items for the next Sprint
2. Updated Release Plan (optional)

Rules:
The Product Owner identifies what has been Done and what has not been Done
The Development Team discusses what went well during the Sprint, what problems
it ran into, and how those problems were solved
The Development Team demonstrates the work that it has Done and answers
questions about the Increment
The Product Owner discusses the Product Backlog as it stands. He or she projects
likely completion dates based on progress to date. Release Plan is often updated
during Sprint Review (optional).
This is an informal meeting, and the presentation of the Increment is intended to elicit
feedback and foster collaboration.
Good Practices:

1.2.4 Sprint Retrospective

Description:
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create
a plan for improvements to be enacted during the next Sprint.
The purpose of the Sprint Retrospective is to:

Inspect how the last Sprint went with regards to people, relationships, process, and
tools
Identify and order the major items that went well and potential improvements

Create a plan for implementing improvements to the way the Scrum Team does its work

The Sprint Retrospective is restricted to the members of the Scrum Teamthat is the
Product Owner, Development Team and Scrum Master. Outsiders, including managers at
every level in the organization are strictly excluded unless specifically invited by the team.

When
After the Sprint
Review and
prior to the next
Sprint Planning
Meeting

Duration
3 hour time-boxed (Scrum
Guide) 4 hour time-boxed
(Scrum Alliance), meeting
for one-month Sprints.
Proportionately less time is
allocated for shorter Sprints.

Inputs
1. Sprint Data
2. Definition of Done
3. Metrics

Attendees
1. Product Owner
2. Scrum Master
3. Development Team
Outsiders strictly excluded

Outputs
1. Identified improvements

Rules:
The Scrum Master encourages the Scrum Team to improve, within the Scrum process
framework, its development process and practices to make it more effective and
enjoyable for the next Sprint.
The Scrum Team plans ways to increase product quality by adapting the Definition of
Done as appropriate.
By the end of the Sprint Retrospective, the Scrum Team should have identified
improvements that it will implement in the next Sprint. Implementing these
improvements in the next Sprint is the adaptation to the inspection of the Scrum Team
itself.
Good Practices:

1.2.4 Grooming (Product Backlog Refining)

Description:
Product Backlog grooming (Refining) is the act of adding detail, estimates, and order to
items in the Product Backlog. This is an ongoing process in which the Product Owner and the
Development Team collaborate on the details of Product Backlog items. During Product Backlog
grooming (refining), items are reviewed and revised. However, they can be updated at any time by
the Product Owner or at the Product Owners discretion. One key benefit of the Product Backlog
Grooming (Refinement) activity is to prepare for the upcoming Sprints.
When
During a Sprint

Duration
10% of the Capacity of the
Development Team

Inputs
1. Product Backlog

Attendees
1. Product Owner
2. Scrum Master
(Optional)
3. Development Team

Outputs
1. Groomed (refined) Backlog

Rules:

Keeping the Product Backlog ordered

Removing or demoting items that no longer seem important
Adding or promoting items that arise or become more important
Splitting items into smaller items
Merging items into larger items
Estimating items

Good Practices:

1.3 Artifacts
Scrum includes three essential artifacts:
1. The Product Backlog
2. The Sprint Backlog
3. The Product Increment.
The Team can also have optional artifacts (not core part of Scrum):
4. Burndown Chart
5. Impediment Backlog

In addition to these artifacts, Scrum requires transparency within the team and with the
stakeholders. As such, the Scrum Team produces visible displays of plans and progress.

1.3.1 Product Backlog

Description:
The Product Backlog is an ordered list of everything that might be needed in the product
and is the single source of requirements for any changes to be made to the product. Higher
ordered Product Backlog items are clearer and more detailed than lower ordered ones.
More precise estimates are made based on the greater clarity and increased detail; the lower
the order, the less detail. Each item on the Product Backlog includes a description and an
estimate. Product Backlog items that will occupy the Development Team for the upcoming
Sprint are fine-grained, having been decomposed so that any one item can be Done within
the Sprint time-box. Product Backlog items that can be Done by the Development Team
within one Sprint are deemed ready or actionable for selection in a Sprint Planning
Meeting.
Owned By:
The Product Owner is responsible for the Product Backlog, including its content,
availability, and ordering.
Characteristics:

A Product Backlog is never complete

The Product Backlog evolves as the product and the environment in which it will be
used evolves.
The Product Backlog is dynamic; it constantly changes to identify what the product
needs to be appropriate, competitive, and useful.
Requirements never stop changing, so a Product Backlog is a living artifact.
Multiple Scrum Teams often work together on the same product. One Product
Backlog is used to describe the upcoming work on the product.
At any point in time, the total work remaining to reach a goal can be summed. The
Product Owner tracks this total work remaining at least for every Sprint Review.
The Product Owner compares this amount with work remaining at previous Sprint
Reviews to assess progress toward completing projected work by the desired time for
the goal. This information is made transparent to all stakeholders.

Structure:
The Product Backlog lists all features, functions, requirements, enhancements, and fixes
that constitute the changes to be made to the product in future releases. Product Backlog
items have the attributes of a description, order, and estimate.
Good Practices:

The Product Backlog is often ordered by value, risk, priority, and necessity.

1.3.2 Sprint Backlog

Description:
The Sprint Backlog is a forecast by the Development Team about what functionality will be in
the next Increment and the work needed to deliver that functionality. The Sprint Backlog
defines the work the Development Team will perform to turn Product Backlog items into a
Done Increment. The Sprint Backlog makes visible all of the work that the Development
Team identifies as necessary to meet the Sprint Goal.
Owned By:
The Sprint Backlog is a highly visible, real-time picture of the work that the Development
Team plans to accomplish during the Sprint, and it belongs solely to the Development
Team.
Characteristics:

As new work is required, the Development Team adds it to the Sprint Backlog.
As work is performed or completed, the estimated remaining work is updated.
When elements of the plan are deemed unnecessary, they are removed.
Only the Development Team can change its Sprint Backlog during a Sprint.
At any point in time in a Sprint, the total work remaining in the Sprint Backlog items
can be summed. The Development Team tracks this total work remaining at least for
every Daily Scrum. The Development Team tracks these sums daily and projects the
likelihood of achieving the Sprint Goal.
Scrum does not consider the time spent working on Sprint Backlog Items. The work
remaining and date are the only variables of interest.

Structure:
The Sprint Backlog is the set of Product Backlog items selected for the Sprint plus a plan
for delivering the product Increment and realizing the Sprint Goal.
Good Practices:

1.3.3 Increment
Description:
The Increment is the sum of all the Product Backlog items completed during a Sprint and all
previous Sprints. At the end of a Sprint, the new Increment must be Done, which means it
must be in useable condition and meet the Scrum Teams Definition of Done. It must be in
useable condition regardless of whether the Product Owner decides to actually release it.
Owned By:
The Product Owner
Characteristics:

The new Increment must be Done, which means it must be in useable condition and
meet the Scrum Teams Definition of Done.
It must be in useable condition regardless of whether the Product Owner decides to
actually release it.

Structure:
The Increment is the sum of all the Product Backlog items completed during a Sprint and all
previous Sprints.
Good Practices:

1.3.4.1 Sprint Burndown Chart

Description:
The sprint Burndown Chart is designed to help the team monitor its progress and be a
leading indicator of whether it will meet its commitment at the end of the sprint. The classic
format requires teams to estimate the duration of each task in hours and on a daily basis to
chart the total remaining hours for all uncompleted tasks.
Owned By:

The Development Team

Characteristics:
Structure:

The X-axis scale is days

The Y-axis scale is hours

Good Practices:
Some teams like to burn down their sprint in story points. The rationale behind this is:

Estimating new tasks and re-estimating in-progress tasks requires effort

Estimating tasks is inaccurate
Estimating in units of time harks back to the bad old ways of working
Completion of tasks delivers no value; only completed stories (features) deliver value.
So the sprint burndown is just like the product or release burndown, except the the Xaxis scale is days rather than sprints.

1.3.4.2 Product or Release Burndown Chart

Description:
The Product Burndown Chart, sometimes known as the Release Burndown Chart,
measures the rate of delivery of a stream of running, tested, features over time. This rate is
known as the teams Velocity. Because features vary in complexity, and therefore effort and
time, we use a scale to compare their size. The most common scale is known as Story
Points. Once a team has worked together for a few sprints, it generally establishes its velocity
within a definable range. Product Owners then use this velocity to predict the rate at which the
team will deliver features in the future, leading to credible release plans.
Using this chart Product Owners are able to report progress, determine release dates and
predict release scope.
Owned By:

The Product Owner

Characteristics:
Structure:

The X-axis scale is Sprints

The Y-axis scale is Story Points

Good Practices:

1.3.5 Impediment Backlog

Description:
The impediment backlog is simply the current list of things that are preventing the
team from progressing or improving. These are things the ScrumMaster must bulldoze
out of the way in her never-ending quest to help the team be the best they can.

Owned By:

The Scrum Master

Characteristics:
Structure:

The current list of impediments

Good Practices:
A good ScrumMaster will try to remove impediments within 24 hours of them being
identified.

1.4 Agreement: Definition of Done (DoD)

Description:
When the Product Backlog item or an Increment is described as Done, everyone must
understand what Done means. Although this varies significantly per Scrum Team, members
must have a shared understanding of what it means for work to be complete, to ensure
transparency. This is the Definition of Done for the Scrum Team and is used to assess
when work is complete on the product Increment.
Owned By:
The Scrum Team
Characteristics:

Development Teams deliver an Increment of product functionality every Sprint. This

Increment is useable, so a Product Owner may choose to immediately release it. Each
Increment is additive to all prior Increments and thoroughly tested.
As Scrum Teams mature, it is expected that their Definition of Done will expand to
include more stringent criteria for higher quality.

Structure:
Good Practices:

1.5 Scrum Questions

1. What can be called a placeholder for the requirements in Scrum?
a.
b.
c.
d.

Product Backlog Task (PBT)

User Story
Product Backlog Item (PBI)
User Cases

2. Which of the Scrum artifacts can be called a "living document"?

a. Sprint Backlog
b. Product Backlog
c. Product Increment
d. Burndown Chart
3. Grooming is an ongoing collaborative effort led by:
a. The Scrum Master
b. The Product Owner
c. The Development Team
d. The Scrum Team
4. As a general rule, how much time should the Development Team allocate for to assisting
the Product Owner with grooming activities?
a. Up to 10%
b. Up to 20%
c. Up to 15%
d. It depends
5. Definition of Ready refers to:
a. The Product Increment
b. The Product Backlog Item
c. The Impediment Backlog
d. The Sprint Backlog
6. Who is responsible for ensuring that good economic decisions are continuously being made
in Scrum?
a. The Product Owner
b. The Scrum Master
c. The Development Team
d. The Project Manager
7. All of the details associated with product backlog item:
a. Might not be fully known or specified at the start of the sprint
b. Is fully known after the Planning Meeting
c. Is quite unknown as Agile embraces uncertainty
d. It depends

8. Who "owns" quality in Scrum team?

a. The Scrum Team
b. The Scrum Master
c. The Testers
d. The Product Owner
9. By using Scrum, we measure progress by:
a. How we are proceeding according to the predefined pan
b. What we have delivered and validated
c. How far we are into a particular phase or stage of development
d. How many bugs left
10. Who is NOT required to attend a Daily Scrum?
a. The Scrum Team
b. The Development Team
c. The Scrum Master
d. The Product Owner

1.6 Scrum Answers

1. Answer: C
Explanation: Instead of compiling a large inventory of detailed requirements up front, we
create placeholders for the requirements, called Product Backlog Items (PBI).
2. Answer: B
Explanation: In Scrum, the product backlog is a "living document", available at all times
during product development.
3. Answer: B
Explanation: Grooming is an ongoing collaborative effort led by the Product Owner and
including significant participation from internal and external stakeholders as well as the
Scrum Master and development Team.
4. Answer: A
Explanation: As a general rule, the Development Team should allocate up to 10% of its
time each sprint to assisting the Product Owner with grooming activities.
5. Answer: B
Explanation: The definition of Ready is the checklist of the work that must be completed
before a product backlog item can be considered to be in respective state and ready to be
moved into a sprint so that the Development Team can confidently commit and complete it
by the end of a sprint.
6. Answer: A
Explanation: The product owner is responsible for ensuring that good economic decisions
are continuously being made at the release, sprint, and product backlog levels.
7. Answer: A
Explanation: All of the details associated with product backlog item might not be fully
known or specified at the start of the sprint. Therefore, it is completely reasonable for the
team to ask clarifying questions during a sprint and for the product owner to answer those
questions.
8. Answer: A
Explanation: In Scrum, quality isn't something a testing team "tests in" at the end; it is
something that a cross-functional Scrum team owns and continuously builds in and verifies
every sprint.
9. Answer: B
Explanation: When using Scrum, we measure progress by what we have validated and
delivered, not by how we are proceeding according to the predefined plan or how far we are
into a particular phase or stage of development.
10. Answer: D

Explanation: The product owner is not required to be at the daily scrum. Only The
Development Team is required to. The Scrum Master must ensure The Development Team
attends the Daily Scrum.