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. Core Scrum (ScrumAlliance)

2. Scrum Guide (Scrum.org)

3. Do Better Scrum-v2 (ScrumSense)

4. ScaleStudy questions on Scrum (ScaleStudy.com)

Future version will include compilation of the following sources:

1. Agile Estimation and Planning (Mike Cohn)

2. User Stories Applied (Mike Cohn)

3. Essential Scrum (Kenneth S. Rubin)

4. Agile Product Management With Scrum (Roman Pinchler)

5. 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. Focus 2. Courage 3. Openness 4. Commitment 5. Respect.

Scrum Framework

Scrum Framework consists of:

1. Roles

2. Events

3. Artifacts

4. 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 laissez-faire 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. Definition of Done

2. Retrospective Meeting

3. Sprint Planning Meeting

4. 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. Maximizing the value of the product

2. Return on Investment (ROI)

3. Prioritizing the items in the Product Backlog

4. Grooming(refining) items in the Product Backlog

5. Ultimately accountable for the Product Backlog items

6. 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. Accountable for creating the Increment of a Product

2. Selects the items from the Product Backlog for the Sprint

3. The Development Team is responsible for all estimates

4. 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 Duration Attendees

At the beginning of the Sprint

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

1. Product Owner 2. Scrum Master 3. Development Team 4. Other people to attend in

order to provide technical or domain advice (Optional)

Inputs Outputs

1. Product Backlog 2. Latest Product Increment 3. Projected Capacity of the Development

Team 4. Past Performance of the Development

Team

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 Duration Attendees

Each day

15-minute time-boxed event

1. Development Team 2. Scrum Master

(Optional, but highly desirable)

3. Product Owner (Optional)

4. Other people as observers (Optional)

Inputs Outputs

1. Impediments faced 2. Information about what have

been done since the last Daily Scrum

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 time-box.

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 Attendees

At the end of the Sprint

4 hour time-boxed meeting for one-month Sprints. Proportionately less time is allocated for shorter Sprints.

1. Product Owner 2. Scrum Master 3. Development Team 4. Stakeholders 5. Other people (Optional)

Inputs Outputs

1. Increment of Potentially Shippable Product

2. Product Backlog 3. Metrics (optional)

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 Duration Attendees

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

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.

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

Inputs Outputs

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

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 Duration Attendees

During a Sprint

10% of the Capacity of the Development Team

1. Product Owner 2. Scrum Master

(Optional) 3. Development Team

Inputs Outputs

1. Product Backlog 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 X-axis 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. Product Backlog Task (PBT)

b. User Story

c. Product Backlog Item (PBI)

d. 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.

OLE_LINK1OLE_LINK2