PSM PDF

The Scrum Guide™
The Definitive Guide to Scrum:

The Rules of the Game
November 2017
Developed and sustained by Scrum creators: Ken Schwaber and Jeff Sutherland
Table of Contents
Purpose of the Scrum Guide ............................................................................................................ 3
Definition of Scrum .......................................................................................................................... 3
Uses of Scrum ................................................................................................................................... 4
Scrum Theory ................................................................................................................................... 4
Scrum Values .................................................................................................................................... 5
The Scrum Team ............................................................................................................................... 6
The Product Owner ...................................................................................................................... 6
The Development Team ............................................................................................................... 7
The Scrum Master ........................................................................................................................ 7
Scrum Events .................................................................................................................................... 9
The Sprint ..................................................................................................................................... 9
Sprint Planning ........................................................................................................................... 10
Daily Scrum ................................................................................................................................. 12
Sprint Review ............................................................................................................................. 13
Sprint Retrospective ................................................................................................................... 14
Scrum Artifacts ............................................................................................................................... 14
Product Backlog.......................................................................................................................... 15
Sprint Backlog ............................................................................................................................. 16
Increment ................................................................................................................................... 17
Artifact Transparency ..................................................................................................................... 17
Definition of “Done” ................................................................................................................... 18
End Note ......................................................................................................................................... 19
Acknowledgements ........................................................................................................................ 19
People......................................................................................................................................... 19
History ........................................................................................................................................ 19
©2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share-Alike license of Creative
Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form
at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you
have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.
Page | 2
Purpose of the Scrum Guide
Scrum is a framework for developing, delivering, and sustaining complex products. This Guide
contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and
the rules that bind them together. Ken Schwaber and Jeff Sutherland developed Scrum; the
Scrum Guide is written and provided by them. Together, they stand behind the Scrum Guide.
Definition of Scrum
Scrum (n): A framework within which people can address complex adaptive problems, while
productively and creatively delivering products of the highest possible value.
Scrum is:
• Lightweight
• Simple to understand
• Difficult to master
Scrum is a process framework that has been used to manage work on complex products since
the early 1990s. Scrum is not a process, technique, or definitive method. Rather, it is a
framework within which you can employ various processes and techniques. Scrum makes clear
the relative efficacy of your product management and work techniques so that you can
continuously improve the product, the team, and the working environment.
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and
rules. Each component within the framework serves a specific purpose and is essential to
Scrum’s success and usage.
The rules of Scrum bind together the roles, events, and artifacts, governing the relationships and
interaction between them. The rules of Scrum are described throughout the body of this
document.
Specific tactics for using the Scrum framework vary and are described elsewhere.
Page | 3
Uses of Scrum
Scrum was initially developed for managing and developing products. Starting in the early
1990s, Scrum has been used extensively, worldwide, to:
1. Research and identify viable markets, technologies, and product capabilities;

2. Develop products and enhancements;
3. Release products and enhancements, as frequently as many times per day;
4. Develop and sustain Cloud (online, secure, on-demand) and other operational
environments for product use; and,
5. Sustain and renew products.
Scrum has been used to develop software, hardware, embedded software, networks of
interacting function, autonomous vehicles, schools, government, marketing, managing the
operation of organizations and almost everything we use in our daily lives, as individuals and
societies.
As technology, market, and environmental complexities and their interactions have rapidly
increased, Scrum’s utility in dealing with complexity is proven daily.
Scrum proved especially effective in iterative and incremental knowledge transfer. Scrum is now
widely used for products, services, and the management of the parent organization.
The essence of Scrum is a small team of people. The individual team is highly flexible and
adaptive. These strengths continue operating in single, several, many, and networks of teams
that develop, release, operate and sustain the work and work products of thousands of people.
They collaborate and interoperate through sophisticated development architectures and target
release environments.
When the words “develop” and “development” are used in the Scrum Guide, they refer to
complex work, such as those types identified above.
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.
Three pillars uphold every implementation of empirical process control: transparency,

inspection, and adaptation.
Page | 4
Transparency
Significant aspects of the process must be visible to those responsible for the outcome.
Transparency requires those aspects be defined by a common standard so observers share a
common understanding of what is being seen.
For example
• A common language referring to the process must be shared by all participants; and,
• Those performing the work and those inspecting the resulting increment must share a
common definition of “Done”.
Inspection
Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect
undesirable variances. Their inspection should not be so frequent that inspection gets in the way
of the work. Inspections are most beneficial when diligently performed by skilled inspectors at
the point of work.
Adaptation
If an inspector determines that one or more aspects of a process deviate outside acceptable
limits, and that the resulting product will be unacceptable, the process or the material being
processed must be adjusted. An adjustment must be made as soon as possible to minimize
further deviation.
Scrum prescribes four formal events for inspection and adaptation, as described in the Scrum
Events section of this document:
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective
Scrum Values
When the values of commitment, courage, focus, openness and respect are embodied and lived
by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life
and build trust for everyone. The Scrum Team members learn and explore those values as they
work with the Scrum roles, events, and artifacts.
Successful use of Scrum depends on people becoming more proficient in living these five values.
People personally commit to achieving the goals of the Scrum Team. The Scrum Team members
have courage to do the right thing and work on tough problems. Everyone focuses on the work
of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be
open about all the work and the challenges with performing the work. Scrum Team members
respect each other to be capable, independent people.
Page | 5
The Scrum Team
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.
Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to
accomplish their work, rather than being directed by others outside the team. Cross-functional
teams have all competencies needed to accomplish the work without depending on others not
part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and
productivity. The Scrum Team has proven itself to be increasingly effective for all the earlier
stated uses, and any complex work.
Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for
feedback. Incremental deliveries of “Done” product ensure a potentially useful version of
working product is always available.
The Product Owner

The Product Owner is responsible for maximizing the value of the product resulting from work
of the Development Team. How this is done may vary widely across organizations, Scrum Teams,
and individuals.
The Product Owner is the sole person responsible for managing the Product Backlog. Product
Backlog management includes:
• Clearly expressing Product Backlog items;

• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what
the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level
needed.
The Product Owner may do the above work, or have the Development Team do it. However, the
Product Owner remains accountable.
The Product Owner is one person, not a committee. The Product Owner may represent the
desires of a committee in the Product Backlog, but those wanting to change a Product Backlog
item’s priority must address the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The
Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No
one can force the Development Team to work from a different set of requirements.
Page | 6
The Development Team
The Development Team consists of professionals who do the work of delivering a potentially
releasable Increment of “Done” product at the end of each Sprint. A “Done” increment is
required at the Sprint Review. Only members of the Development Team create the Increment.
Development Teams are structured and empowered by the organization to organize and
manage their own work. The resulting synergy optimizes the Development Team’s overall
efficiency and effectiveness.
Development Teams have the following characteristics:
• They are self-organizing. No one (not even the Scrum Master) tells the Development Team
how to turn Product Backlog into Increments of potentially releasable functionality;
• Development Teams are cross-functional, with all the skills as a team necessary to create a
product Increment;
• Scrum recognizes no titles for Development Team members, regardless of the work being
performed by the person;
• Scrum recognizes no sub-teams in the Development Team, regardless of domains that need
to be addressed like testing, architecture, operations, or business analysis; and,
• Individual Development Team members may have specialized skills and areas of focus, but
accountability belongs to the Development Team as a whole.
Development Team Size

Optimal Development Team size is small enough to remain nimble and large enough to
complete significant work within a Sprint. Fewer than three Development Team members
decrease interaction and results in smaller productivity gains. Smaller Development Teams may
encounter skill constraints during the Sprint, causing the Development Team to be unable to
deliver a potentially releasable Increment. Having more than nine members requires too much
coordination. Large Development Teams generate too much complexity for an empirical process
to be useful. The Product Owner and Scrum Master roles are not included in this count unless
they are also executing the work of the Sprint Backlog.
The Scrum Master

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum
Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules,
and values.
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those
outside the Scrum Team understand which of their interactions with the Scrum Team are helpful
and which aren’t. The Scrum Master helps everyone change these interactions to maximize the
value created by the Scrum Team.
Page | 7
Scrum Master Service to the Product Owner
The Scrum Master serves the Product Owner in several ways, including:
• Ensuring that goals, scope, and product domain are understood by everyone on the Scrum
Team as well as possible;
• Finding techniques for effective Product Backlog management;
• Helping the Scrum Team understand the need for clear and concise Product Backlog items;
• Understanding product planning in an empirical environment;
• Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
• Understanding and practicing agility; and,
• Facilitating Scrum events as requested or needed.
Scrum Master Service to the Development Team

The Scrum Master serves the Development Team in several ways, including:
• Coaching the Development Team in self-organization and cross-functionality;

• Helping the Development Team to create high-value products;
• Removing impediments to the Development Team’s progress;
• Facilitating Scrum events as requested or needed; and,
• Coaching the Development Team in organizational environments in which Scrum is not yet
fully adopted and understood.
Scrum Master Service to the Organization

The Scrum Master serves the organization in several ways, including:
• Leading and coaching the organization in its Scrum adoption;

• Planning Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact Scrum and empirical product
development;
• Causing change that increases the productivity of the Scrum Team; and,
• Working with other Scrum Masters to increase the effectiveness of the application of Scrum
in the organization.
Page | 8
Scrum Events
Prescribed events are used in Scrum to create regularity and to minimize the need for meetings
not defined in Scrum. All events are time-boxed events, such that every event has a maximum
duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The
remaining events may end whenever the purpose of the event is achieved, ensuring an
appropriate amount of time is spent without allowing waste in the process.
Other than the Sprint itself, which is a container for all other events, each event in Scrum is a
formal opportunity to inspect and adapt something. These events are specifically designed to
enable critical transparency and inspection. Failure to include any of these events results in
reduced transparency and is a lost opportunity to inspect and adapt.
The Sprint
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable,
and potentially releasable product Increment is created. Sprints have consistent durations
throughout a development effort. A new Sprint starts immediately after the conclusion of the
previous Sprint.
Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the
Sprint Review, and the Sprint Retrospective.
During the Sprint:
• No changes are made that would endanger the Sprint Goal;

• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the Product Owner and Development
Team as more is learned.
Each Sprint may be considered a project with no more than a one-month horizon. Like projects,
Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design
and flexible plan that will guide building it, the work, and the resultant product increment.
Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of
what is being built may change, complexity may rise, and risk may increase. Sprints enable
predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least
every calendar month. Sprints also limit risk to one calendar month of cost.
Page | 9
Cancelling a Sprint
A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the
authority to cancel the Sprint, although he or she may do so under influence from the
stakeholders, the Development Team, or the Scrum Master.
A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the
company changes direction or if market or technology conditions change. In general, a Sprint
should be cancelled if it no longer makes sense given the circumstances. But, due to the short
duration of Sprints, cancellation rarely makes sense.
When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If
part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete
Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on
them depreciates quickly and must be frequently re-estimated.
Sprint cancellations consume resources, since everyone regroups in another Sprint Planning to
start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very
uncommon.
Sprint Planning
The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by
the collaborative work of the entire Scrum Team.
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter
Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and
that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it
within the time-box.
Sprint Planning answers the following:
• What can be delivered in the Increment resulting from the upcoming Sprint?
• How will the work needed to deliver the Increment be achieved?
Topic One: What can be done this Sprint?

The Development Team works to forecast the functionality that will be developed during the
Sprint. The Product Owner discusses the objective that the Sprint should achieve and the
Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire
Scrum Team collaborates on understanding the work of the Sprint.
The input to this meeting is the Product Backlog, the latest product Increment, projected
capacity of the Development Team during the Sprint, and past performance of the Development
Team. 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.
Page | 10
During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective
that will be met within the Sprint through the implementation of the Product Backlog, and it
provides guidance to the Development Team on why it is building the Increment.
Topic Two: How will the chosen work get done?

Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the
Development Team decides how it will build this functionality into a “Done” product Increment
during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering
them is called the Sprint Backlog.
The Development Team usually starts by designing the system and the work needed to convert
the Product Backlog into a working product Increment. Work may be of varying size, or
estimated effort. However, enough work is planned during Sprint Planning for the Development
Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first
days of the Sprint by the Development Team is decomposed by the end of this meeting, often to
units of one day or less. The Development Team self-organizes to undertake the work in the
Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.
The Product Owner can help to clarify the selected Product Backlog items and make trade-offs.
If the Development Team determines it has too much or too little work, it may renegotiate the
selected Product Backlog items with the Product Owner. The Development Team may also invite
other people to attend to provide technical or domain advice.
By the end of the Sprint Planning, the Development Team should be able to explain to the
Product Owner and Scrum Master how it intends to work as a self-organizing team to
accomplish the Sprint Goal and create the anticipated Increment.
Sprint Goal
The Sprint Goal is an objective set for the Sprint that can be met through the implementation of
Product Backlog. It provides guidance to the Development Team on why it is building the
Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the
Development Team some flexibility regarding the functionality implemented within the Sprint.
The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal.
The Sprint Goal can be any other coherence that causes the Development Team to work
together rather than on separate initiatives.
As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint
Goal, it implements functionality and technology. If the work turns out to be different than the
Development Team expected, they collaborate with the Product Owner to negotiate the scope
of Sprint Backlog within the Sprint.
Page | 11
Daily Scrum
The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is
held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This
optimizes team collaboration and performance by inspecting the work since the last Daily Scrum
and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each
day to reduce complexity.
The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to
inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily
Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every
day, the Development Team should understand how it intends to work together as a self-
organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end
of the Sprint.
The structure of the meeting is set by the Development Team and can be conducted in different
ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use
questions, some will be more discussion based. Here is an example of what might be used:
• What did I do yesterday that helped the Development Team meet the Sprint Goal?
• What will I do today to help the Development Team meet the Sprint Goal?
• Do I see any impediment that prevents me or the Development Team from meeting the
Sprint Goal?
The Development Team or team members often meet immediately after the Daily Scrum for
detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.
The Scrum Master ensures that the Development Team has the meeting, but the Development
Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the
Development Team to keep the Daily Scrum within the 15-minute time-box.
The Daily Scrum is an internal meeting for the Development Team. If others are present, the
Scrum Master ensures that they do not disrupt the meeting.
Daily Scrums improve communications, eliminate other meetings, identify impediments to

development for removal, highlight and promote quick decision-making, and improve the
Development Team’s level of knowledge. This is a key inspect and adapt meeting.
Page | 12
Sprint Review
A 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. Based on that and any changes to the Product Backlog
during the Sprint, attendees collaborate on the next things that could be done to optimize value.
This is an informal meeting, not a status meeting, and the presentation of the Increment is
intended to elicit feedback and foster collaboration.
This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is
usually shorter. The Scrum Master ensures that the event takes place and that attendees
understand its purpose. The Scrum Master teaches everyone involved to keep it within the time-
box.
The Sprint Review includes the following elements:
• Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
• The Product Owner explains what Product Backlog items have 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
target and delivery dates based on progress to date (if needed);
• The entire group collaborates on what to do next, so that the Sprint Review provides
valuable input to subsequent Sprint Planning;
• Review of how the marketplace or potential use of the product might have changed what is
the most valuable thing to do next; and,
• Review of the timeline, budget, potential capabilities, and marketplace for the next
anticipated releases of functionality or capability of the product.
The result of the Sprint Review is a revised Product Backlog that defines the probable Product
Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new
opportunities.
Page | 13
Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan
for improvements to be enacted during the next Sprint.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.
This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is
usually shorter. The Scrum Master ensures that the event takes place and that attendants
understand its purpose.
The Scrum Master ensures that the meeting is positive and productive. The Scrum Master
teaches all to keep it within the time-box. The Scrum Master participates as a peer team
member in the meeting from the accountability over the Scrum process.
The purpose of the Sprint Retrospective is to:
• Inspect how the last Sprint went with regards to people, relationships, process, and tools;
• Identify and order the major items that went well and potential improvements; and,
• Create a plan for implementing improvements to the way the Scrum Team does its work.
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. During each Sprint Retrospective, the Scrum Team plans ways to increase
product quality by improving work processes or adapting the definition of “Done”, if appropriate
and not in conflict with product or organizational standards.
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements
that it will implement in the next Sprint. Implementing these improvements in the next Sprint is
the adaptation to the inspection of the Scrum Team itself. Although improvements may be
implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on
inspection and adaptation.
Scrum Artifacts
Scrum’s artifacts represent work or value to provide transparency and opportunities for
inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize
transparency of key information so that everybody has the same understanding of the artifact.
Page | 14
Product Backlog
The Product Backlog is an ordered list of everything that is known to be needed in the product.
It is the single source of requirements for any changes to be made to the product. The Product
Owner is responsible for the Product Backlog, including its content, availability, and ordering.
A Product Backlog is never complete. The earliest development of it lays out the initially known
and best-understood requirements. 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. If a
product exists, its Product Backlog also exists.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that
constitute the changes to be made to the product in future releases. Product Backlog items have
the attributes of a description, order, estimate, and value. Product Backlog items often include
test descriptions that will prove its completeness when “Done.”
As a product is used and gains value, and the marketplace provides feedback, the Product
Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a
Product Backlog is a living artifact. Changes in business requirements, market conditions, or
technology may cause changes in the Product Backlog.
Multiple Scrum Teams often work together on the same product. One Product Backlog is used
to describe the upcoming work on the product. A Product Backlog attribute that groups items
may then be employed.
Product Backlog refinement 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 refinement,
items are reviewed and revised. The Scrum Team decides how and when refinement is done.
Refinement usually consumes no more than 10% of the capacity of the Development Team.
However, Product Backlog items can be updated at any time by the Product Owner or at the
Product Owner’s discretion.
Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered
ones. More precise estimates are made based on the greater clarity and increased detail; the
lower the order, the less detail. Product Backlog items that will occupy the Development Team
for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the
Sprint time-box. Product Backlog items that can be “Done” by the Development Team within
one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually
acquire this degree of transparency through the above described refining activities.
The Development Team is responsible for all estimates. The Product Owner may influence the
Development Team by helping it understand and select trade-offs, but the people who will
perform the work make the final estimate.
Page | 15
Monitoring Progress Toward Goals
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 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.
Various projective practices upon trending have been used to forecast progress, like burn-
downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace
the importance of empiricism. In complex environments, what will happen is unknown. Only
what has already happened may be used for forward-looking decision-making.
Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for
delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast
by the Development Team about what functionality will be in the next Increment and the work
needed to deliver that functionality into a “Done” Increment.
The Sprint Backlog makes visible all the work that the Development Team identifies as necessary
to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high
priority process improvement identified in the previous Retrospective meeting.
The Sprint Backlog is a plan with enough detail that changes in progress can be understood in
the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and
the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team
works through the plan and learns more about the work needed to achieve the Sprint Goal.
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. 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.
Page | 16
Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed.
The Development Team tracks this total work remaining at least for every Daily Scrum to project
the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the
Sprint, the Development Team can manage its progress.
Increment
The Increment is the sum of all the Product Backlog items completed during a Sprint and the
value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must
be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition
of “Done.” An increment is a body of inspectable, done work that supports empiricism at the
end of the Sprint. The increment is a step toward a vision or goal. The increment must be in
useable condition regardless of whether the Product Owner decides to release it.
Artifact Transparency
Scrum relies on transparency. Decisions to optimize value and control risk are made based on
the perceived state of the artifacts. To the extent that transparency is complete, these decisions
have a sound basis. To the extent that the artifacts are incompletely transparent, these
decisions can be flawed, value may diminish and risk may increase.
The Scrum Master must work with the Product Owner, Development Team, and other involved
parties to understand if the artifacts are completely transparent. There are practices for coping
with incomplete transparency; the Scrum Master must help everyone apply the most
appropriate practices in the absence of complete transparency. A Scrum Master can detect
incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what is
being said, and detecting differences between expected and real results.
The Scrum Master’s job is to work with the Scrum Team and the organization to increase the
transparency of the artifacts. This work usually involves learning, convincing, and change.
Transparency doesn’t occur overnight, but is a path.
Page | 17
Definition of “Done”
When a Product Backlog item or an Increment is described as “Done”, everyone must
understand what “Done” means. Although this may vary significantly per Scrum Team, members
must have a shared understanding of what it means for work to be complete, to ensure
transparency. This is the definition of “Done” for the Scrum Team and is used to assess when
work is complete on the product Increment.
The same definition guides the Development Team in knowing how many Product Backlog items
it can select during a Sprint Planning. The purpose of each Sprint is to deliver Increments of
potentially releasable functionality that adhere to the Scrum Team’s current definition of
“Done.”
Development Teams deliver an Increment of product functionality every Sprint. This Increment
is useable, so a Product Owner may choose to immediately release it. If the definition of "Done"
for an increment is part of the conventions, standards or guidelines of the development
organization, all Scrum Teams must follow it as a minimum.
If "Done" for an increment is not a convention of the development organization, the

Development Team of the Scrum Team must define a definition of “Done” appropriate for the
product. If there are multiple Scrum Teams working on the system or product release, the
Development Teams on all the Scrum Teams must mutually define the definition of “Done.”
Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all
Increments work together.
As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include
more stringent criteria for higher quality. New definitions, as used, may uncover work to be
done in previously “Done” increments. Any one product or system should have a definition of
“Done” that is a standard for any work done on it.
Page | 18
End Note
Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable
and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists
only in its entirety and functions well as a container for other techniques, methodologies, and
practices.
Acknowledgements
People
Of the thousands of people who have contributed to Scrum, we should single out those who
were instrumental at the start: Jeff Sutherland worked with Jeff McKenna and John
Scumniotales, and Ken Schwaber worked with Mike Smith and Chris Martin, and all of them
worked together. Many others contributed in the ensuing years and without their help Scrum
would not be refined as it is today.
History
Ken Schwaber and Jeff Sutherland worked on Scrum until 1995, when they co-presented Scrum
at the OOPSLA Conference in 1995. This presentation essentially documented the learning that
Ken and Jeff gained over the previous few years, and made public the first formal definition of
Scrum.
The history of Scrum is described elsewhere. To honor the first places where it was tried and
refined, we recognize Individual, Inc., Newspage, Fidelity Investments, and IDX (now GE
Medical).
The Scrum Guide documents Scrum as developed, evolved, and sustained for 20-plus years by
Jeff Sutherland and Ken Schwaber. Other sources provide you with patterns, processes, and
insights that complement the Scrum framework. These may increase productivity, value,
creativity, and satisfaction with the results.
Page | 19
Guia do ScrumMR
Um guia definitivo para o Scrum:
As regras do Jogo
Novembro de 2017
Desenvolvido e mantido pelos criadores do Scrum: Ken Schwaber e Jeff

Sutherland
Versão em português do Brasil | Brazilian Portuguese
Índice
O propósito do Guia do Scrum ....................................................................................................... 3
Definição do Scrum ........................................................................................................................ 3
Usos do Scrum ................................................................................................................................ 4
Teoria do Scrum ............................................................................................................................. 4
Valores do Scrum ........................................................................................................................... 5
O Time Scrum ................................................................................................................................. 6
O Product Owner ....................................................................................................................... 6
O Time de Desenvolvimento ...................................................................................................... 7
O Scrum Master ......................................................................................................................... 7
Eventos Scrum ................................................................................................................................ 9
A Sprint ....................................................................................................................................... 9
Planejamento da Sprint............................................................................................................ 10
Reunião Diária .......................................................................................................................... 12
Revisão da Sprint ...................................................................................................................... 13
Retrospectiva da Sprint ............................................................................................................ 13
Artefatos do Scrum ...................................................................................................................... 14
Backlog do Produto .................................................................................................................. 14
Backlog da Sprint ...................................................................................................................... 16
Incremento ............................................................................................................................... 16
Transparência do Artefato ........................................................................................................... 17
Definição de “Pronto” .............................................................................................................. 17
Conclusão ..................................................................................................................................... 18
Agradecimentos ........................................................................................................................... 18
Pessoas ..................................................................................................................................... 18
História ..................................................................................................................................... 18
Tradução .................................................................................................................................. 18
Mudanças entre os Guias Scrum 2016 e 2017............................................................................. 19
©2017 Ken Schwaber e Jeff Sutherland. Oferecido por licensa sobre a Attribution Share-Alike da Creative
Commons, acessível em http://creativecommons.org/licenses/by-sa/4.0/legalcode e também descrita resumidamente
em http://creativecommons.org/licenses/by-sa/4.0/. Utilizando este Guia Scrum você you reconhece e concorda que
leu e concordou com os termos de atribuição relacionados pelos termos da licensa Attribution Share-Alike da
Creative Commons. Página | 2
O propósito do Guia do Scrum
Scrum é um framework para desenvolver, entregar e manter produtos complexos. Este guia
contém a definição do Scrum. Esta definição consiste em papéis, eventos, artefatos e as regras
do Scrum que unem os demais e os mantém integrados. Ken Schwaber e Jeff Sutherland
desenvolveram o Scrum; o Guia do Scrum é escrito e fornecido por eles. Juntos, eles apoiam o
Guia do Scrum.
Definição do Scrum
Scrum (subs): Um framework dentro do qual pessoas podem tratar e resolver problemas
complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais
alto valor possível. Scrum é:
• Leve
• Simples de entender
• Difícil de dominar
Scrum é um framework estrutural que está sendo usado para gerenciar o trabalho em
produtos complexos desde o início de 1990. Scrum não é um processo, técnica ou um método
definitivo. Em vez disso, é um framework dentro do qual você pode empregar vários processos
ou técnicas. O Scrum deixa claro a eficácia relativa de suas práticas de gerenciamento de
produto e técnicas de trabalho, de modo que você possa continuamente melhorar o produto,
o time e o ambiente de trabalho.
O framework Scrum consiste de times Scrum associados a papéis, eventos, artefatos e regras.
Cada componente dentro do framework serve a um propósito específico e é essencial para o
uso e sucesso do Scrum.
As regras do Scrum integram os papéis, eventos e artefatos, administrando as relações e

interações entre eles. As regras do Scrum são descritas ao longo deste documento.
Estratégias específicas para o uso do framework Scrum variam e são descritas em outros
documentos.
Usos do Scrum
O Scrum foi inicialmente desenvolvido para gerenciar e desenvolver produtos. Iniciando no
começo dos anos 90, o Scrum tem sido usado extensivamente, mundialmente, para:
1. Pesquisar e Identificar mercados viáveis, tecnologias e funcionalidades de produtos;

2. Desenvolver produtos e melhorias;
3. Liberar produtos e melhorias frequentes, chegando a várias vezes por dia;
4. Desenvolver e sustentar a Nuvem (online, segura, sob demanda) e outros ambientes
operacionais para uso de produtos; e,
5. Sustentar e renovar produtos.
Scrum tem sido usado para desenvolver software, hardware, software embarcado, redes de
funções interativas, veículos autônomos, escolas, governo, marketing, gerenciar a operação da
organização e quase tudo que usamos em nosso dia-dia nas nossas vidas, como indivíduos e
sociedades.
Como tecnologia, mercado, complexidades ambientais e suas interações tem aumentado

rapidamente, a utilidade do Scrum em lidar com a complexidade é provada diariamente.
Scrum demonstra efetividade especialmente na transferência de conhecimento iterativo e

incremental. Scrum é agora amplamente usado para produtos, serviços e no gerenciamento
da própria empresa.
A essência do Scrum é um pequeno time de pessoas. O time individual é altamente flexível e

adaptativo. Essas forças continuam operando em únicos, muitos, vários, e em redes de times
que desenvolvem, liberam, operam e sustentam o trabalho e trabalham produtos de milhares
de pessoas. Eles colaboram e interoperam através de arquiteturas sofisticadas de
desenvolvimento e ambientes de liberação como objetivo.
Quando as palavras “desenvolver” e “desenvolvimento” são usadas no Guia Scrum, elas se

referem a trabalho complexo, tais como os tipos identificados acima.
Teoria do Scrum
Scrum é fundamentado nas teorias empíricas de controle de processo, ou empirismo. O
empirismo afirma que o conhecimento vem da experiência e de tomada de decisões baseadas
no que é conhecido. O Scrum emprega uma abordagem iterativa e incremental para
aperfeiçoar a previsibilidade e o controle de riscos.
Três pilares apoiam a implementação de controle de processo empírico: transparência,

inspeção e adaptação.
Transparência
Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. A
transparência requer que estes aspectos tenham uma definição padrão comum para que os
observadores compartilharem um mesmo entendimento comum do que está sendo visto.
Por exemplo:
• Uma linguagem comum referindo-se ao processo deve ser compartilhada por todos os
participantes; e,
• Aqueles que realizam o trabalho e aqueles que inspecionam o incremento resultado do
trabalho devem compartilhar uma definição comum de “Pronto” 2.
Inspeção
Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em
direção ao objetivo da Sprint para detectar variações indesejadas. Esta inspeção não deve ser
tão frequente que atrapalhe o objetivo dos trabalhos. As inspeções são mais benéficas quando
realizadas de forma diligente por inspetores especializados no trabalho a se verificar.
Adaptação
Se um inspetor determina que um ou mais aspectos de um processo desviou para fora dos
limites aceitáveis, e que o resultado do produto será inaceitável, o processo ou o material
sendo produzido deve ser ajustado. O ajuste deve ser realizado o mais breve possível para
minimizar mais desvios.
O Scrum prescreve quatro Eventos formais para inspeção e adaptação, como descrito na seção
Eventos do Scrum deste documento.
• Planejamento da Sprint
• Reunião diária
• Revisão da Sprint
• Retrospectiva da Sprint
Valores do Scrum
Quando os valores de comprometimento, coragem, foco, transparência e respeito são
incorporados e vividos pelo Time Scrum, os pilares do Scrum de transparência, inspeção e
adaptação tornam-se vivos e constroem a confiança para todos. Os membros do Time Scrum
aprendem e exploram estes valores à medida que trabalham com os eventos, papéis e
artefatos do Scrum.
O Sucesso no uso do Scrum depende das pessoas se tornarem mais proficientes na vivência
destes cinco valores. As pessoas se comprometem pessoalmente em alcançar os objetivos do
Time Scrum. O Time Scrum precisa ter coragem para fazer a coisa certa e trabalhar em
problemas difíceis. Todos focam no trabalho da Sprint e nos objetivos do Time Scrum. O Time
Scrum e seus Stakeholders concordam em estarem abertos a todo o trabalho e aos desafios
2 Veja definição de “Pronto”, p. 17
com a execução dos trabalhos. Os membros do Time Scrum respeitam uns aos outros para
serem pessoas capazes e independentes.
O Time Scrum
O Time Scrum consiste em um Product Owner, o Time de Desenvolvimento e um Scrum
Master. Times Scrum são auto-organizáveis e multifuncionais. Times auto-organizáveis
escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos por
outros de fora do Time. Times multifuncionais possuem todas as competências necessárias
para completar o trabalho sem depender de outros que não fazem parte da equipe. O modelo
de time no Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade. O
Time Scrum demonstra-se estar aumentando sua efetividade para todos os usos
anteriormente citados, e qualquer trabalho complexo.
Times Scrum entregam produtos de forma iterativa e incremental, maximizando as

oportunidades para feedback. Entregas incrementais de produto “Pronto” garantem que uma
versão potencialmente funcional do produto do trabalho esteja sempre disponível.
O Product Owner
O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto
resultado do trabalho do Time de Desenvolvimento. Como isso é feito pode variar amplamente
através das organizações, Times Scrum e indivíduos.
O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. O

gerenciamento do Backlog do Produto inclui:
• Expressar claramente os itens do Backlog do Produto;

• Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;
• Otimizar o valor do trabalho que o Time de Desenvolvimento realiza;
• Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o
que o Time Scrum vai trabalhar a seguir; e,
• Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível
necessário.
O Product Owner pode fazer o trabalho acima, ou delegar para o Time de Desenvolvimento
fazê-lo. No entanto, o Product Owner continua sendo o responsável pelos trabalhos.
O Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo
de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas
prioridades dos itens de Backlog devem endereçar ao Product Owner.
Para que o Product Owner tenha sucesso, toda a organização deve respeitar as decisões
dele(a). As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do
Produto. Ninguém pode forçar o Time de Desenvolvimento a trabalhar em um diferente
conjunto de requerimentos.
O Time de Desenvolvimento
O Time de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar um
incremento potencialmente liberável do produto “Pronto” ao final de cada Sprint. Um
incremento “Pronto” é requerido na Revisão da Sprint. Somente integrantes do Time de
Desenvolvimento criam incrementos.
Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar

e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia do
Time de Desenvolvimento como um todo.
Os Times de Desenvolvimento tem as seguintes características:
• Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Time de
Desenvolvimento como transformar o Backlog do Produto em incrementos de
funcionalidades potencialmente liberável;
• Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias,
enquanto equipe, para criar o incremento do Produto.
• O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento,
independentemente do trabalho que está sendo realizado pela pessoa;
• O Scrum não reconhece sub-times no Time de Desenvolvimento, independente dos
domínios de conhecimento que precisam ser abordados, tais como teste, arquitetura,
operação ou análise de negócios; e,
• Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades
especializadas e área de especialização, mas a responsabilidade pertence ao Time de
Desenvolvimento como um todo;
Tamanho do Time de Desenvolvimento

O tamanho ideal do Time de Desenvolvimento é pequeno o suficiente para se manter ágil e
grande o suficiente para completar um trabalho significativo dentro da Sprint. Menos de três
integrantes no Time de Desenvolvimento diminuem a interação e resultam em um menor
ganho de produtividade. Times de desenvolvimento menores podem encontrar restrições de
habilidades durante a Sprint, gerando um Time de Desenvolvimento incapaz de entregar um
incremento potencialmente liberável. Havendo mais de nove integrantes é exigida muita
coordenação. Times de Desenvolvimento grandes geram muita complexidade para que um
processo empírico seja útil. Os papéis de Product Owner e de Scrum Master não são incluídos
nesta contagem, a menos que eles também executem o trabalho do Backlog da Sprint.
O Scrum Master
O Scrum Master é responsável por promover e suportar o Scrum como definido no Guia
Scrum. O Scrum Master faz isso ajudando todos a entenderem a teoria, as práticas, as regras e
os valores do Scrum.
O Scrum Master é um servo-líder para o Time Scrum. O Scrum Master ajuda aqueles que estão
fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais
não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor
criado pelo Time Scrum.
O Scrum Master trabalhando para o Product Owner

O Scrum Master serve o Product Owner de várias maneiras, incluindo:
• Garantindo que objetivos, escopo e domínio do produto sejam entendidos o melhor

possível por todos do Time Scrum
• Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;
• Ajudando o Time Scrum a entender as necessidades para ter items de Backlog do Produto
claros e concisos.
• Compreendendo o planejamento do Produto em um ambiente empírico;
• Garantindo que o Product Owner saiba como organizar o Backlog do Produto para maximar
valor;
• Compreender e praticar a agilidade; e,
• Facilitar os eventos Scrum conforme exigidos ou necessários.
O Scrum Master trabalhando para o Time de Desenvolvimento

O Scrum Master serve o Time de Desenvolvimento de várias maneiras, incluindo:
• Treinando o Time de Desenvolvimento em autogerenciamento e interdisciplinaridade;

• Ajudando o Time de Desenvolvimento na criação de produtos de alto valor;
• Removendo impedimentos para o progresso do Time de Desenvolvimento;
• Facilitando os eventos Scrum conforme exigidos ou necessários; e,
• Treinando o Time de Desenvolvimento em ambientes organizacionais nos quais o Scrum
não é totalmente adotado e compreendido.
O Scrum Master trabalhando para a Organização

O Scrum Master serve a Organização de várias maneiras, incluindo:
• Liderando e treinando a organização na adoção do Scrum;

• Planejando implementações Scrum dentro da organização;
• Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o
desenvolvimento de produto empírico;
• Causando mudanças que aumentam a produtividade do Time Scrum; e,
• Trabalhando com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum na
organização.
Eventos Scrum
Eventos prescritos são usados no Scrum para criar uma regularidade e minimizar a necessidade
de reuniões não definidas no Scrum. Todos os eventos são eventos time-boxed, de tal modo
que todo evento tem uma duração máxima. Uma vez que a Sprint começa, sua duração é
fixada e não pode ser reduzida ou aumentada. Os eventos restantes podem terminar sempre
que o propósito do evento é alcançado, garantindo que uma quantidade adequada de tempo
seja gasta não permitindo desperdícios no processo.
Além da Sprint, que é um container para outros eventos, cada evento no Scrum é uma
oportunidade de inspecionar e adaptar alguma coisa. Estes eventos são especificamente
projetados para permitir uma transparência e inspeção criteriosa. Falhas na inclusão de
qualquer um destes eventos resultará na redução da transparência e na perda de
oportunidades para inspecionar e adaptar.
A Sprint
O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um
“Pronto”, incremento de produto potencialmente liberável é criado. Sprints tem durações
consistentes ao longo de todo o esforço de desenvolvimento. Uma nova Sprint inicia
imediatamente após a conclusão da Sprint anterior.
As Sprints contém e consistem de um planejamento da Sprint, reuniões diárias, o trabalho de

desenvolvimento, uma revisão da Sprint e uma retrospectiva da Sprint.
Durante a Sprint:
• Não são feitas mudanças que possam por em perigo o objetivo da Sprint;
• As metas de qualidade não diminuem; e,
• O escopo pode ser clarificado e renegociado entre o Product Owner e o Time de
Desenvolvimento quanto mais for aprendido.
Cada Sprint pode ser considerada um projeto com horizonte não maior que um mês. Como os
projetos, as Sprints são utilizadas para realizar algo. Cada Sprint tem uma meta do que é para
ser construído, um plano previsto e flexível que irá guiar a construção, o trabalho e o produto
resultante do incremento.
Sprints são limitadas a um mês corrido. Quando o horizonte da Sprint é muito longo, a
definição do que será construído pode mudar, a complexidade pode aumentar e o risco pode
crescer. Sprints permitem previsibilidade que garante a inspeção e adaptação do progresso em
direção à meta pelo menos a cada mês corrido. Sprints também limitam o risco ao custo de um
mês corrido.
Cancelamento da Sprint
Uma Sprint pode ser cancelada antes do time-boxed da Sprint terminar. Somente o Product
Owner tem a autoridade para cancelar a Sprint, embora ele (ou ela) possa fazer isso sob
influência das partes interessadas, do Time de Desenvolvimento ou do Scrum Master.
A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto. Isto pode ocorrer se a
organização mudar sua direção ou se as condições do mercado ou das tecnologias mudarem.
Geralmente a Sprint deve ser cancelada se ela não faz mais sentido às dadas circunstâncias. No
entanto, devido a curta duração da Sprint, raramente cancelamentos fazem sentido.
Quando a Sprint é cancelada, qualquer item de Backlog do Produto completado e “Pronto” é

revisado. Se uma parte do trabalho estiver potencialmente liberável, tipicamente o Product
Owner o aceita. Todos os itens de Backlog do Produto incompletos são reestimados e
colocados de volta no Backlog do Produto. O trabalho feito se deprecia rapidamente e deve ser
frequentemente reestimado.
O cancelamento de Sprints consome recursos, já que todos se reagrupam em outro

planejamento da Sprint para iniciar outra Sprint. Cancelamentos de Sprints são
frequentemente traumáticos para o Time Scrum, e são muito incomuns.
Planejamento da Sprint
O trabalho a ser realizado na Sprint é planejado durante o planejamento da Sprint. Este plano
é criado com o trabalho colaborativo de todo o Time Scrum.
O Planejamento da Sprint é um um time-boxed com no máximo oito horas para uma Sprint de
um mês de duração. Para Sprints menores, este evento é usualmente menor. O Scrum Master
garante que o evento ocorra e que os participantes entendam seu propósito. O Scrum Master
ensina o Time Scrum a manter-se dentro dos limites do time-box.
O planejamento da Sprint responde as seguintes questões:
• O que pode ser entregue como resultado do incremento da próxima Sprint?

• Como o trabalho necessário para entregar o incremento será realizado?
Tópico Um: O que pode ser Pronto nesta Sprint?

O Time de Desenvolvimento trabalha para prever as funcionalidades que serão desenvolvidas
durante a Sprint. O Product Owner debate o objetivo que a Sprint deve realizar e os itens de
Backlog do Produto que, se completados na Sprint, atingirão o objetivo da Sprint. Todo o Time
Scrum colabora com o entendimento do trabalho da Sprint.
A entrada desta reunião é o Backlog do Produto, o mais recente incremento do produto, a

capacidade projetada do Time de Desenvolvimento durante a Sprint e o desempenho passado
do Time de Desenvolvimento. O número de itens selecionados do Backlog do Produto para a
Sprint é o único trabalho do Time de Desenvolvimento. Somente o Time de Desenvolvimento
pode avaliar o que pode ser completado ao longo da próxima Sprint.
Durante o Planejamento da Sprint, o Time Scrum também determina a meta da Sprint. A meta
da Sprint é o objetivo que será satisfeito dentro da Sprint através da implementação do
Backlog do Produto, e que fornece a orientação para o Time de Desenvolvimento sobre o
porquê dele estar construindo o incremento.
Tópico Dois: Como o trabalho escolhido será Pronto?

Tendo definido o objetivo da Sprint e selecionado os itens de Backlog do Produto da Sprint, o
Time de Desenvolvimento decide como irá construir essas funcionalidades durante a Sprint e
transformá-las em um incremento de produto “Pronto”. Os itens de Backlog do Produto
selecionados para a Sprint, junto com o plano de entrega destes itens é chamado de Backlog
da Sprint.
O Time de Desenvolvimento frequentemente inicia o desenho do sistema e do trabalho

necessário para converter o Backlog do Produto em um incremento funcional do produto. O
trabalho pode ser de vários tamanhos ou esforços. Contudo, o trabalho suficiente é planejado
durante o planejamento da Sprint pelo Time de Desenvolvimento para prever o que este
acredita que poderá fazer durante a próxima Sprint. O trabalho planejado pelo Time de
Desenvolvimento para os primeiros dias da Sprint é decomposto até o final desta reunião,
frequentemente em unidades de um dia de duração ou menos. O Time de Desenvolvimento se
auto-organiza para realizar todo o trabalho do Backlog da Sprint, tanto durante o
planejamento da Sprint quanto no que for necessário durante a Sprint.
O Product Owner pode ajudar a clarificar os itens de Backlog do Produto selecionados e nas
decisões conflituosas de troca. Se o Time de Desenvolvimento determina que tem excesso ou
falta de trabalho, os itens do Backlog da Sprint podem ser renegociados com o Product Owner.
O Time de Desenvolvimento também pode convidar outras pessoas para participar desta
reunião para fornecer opinião técnica ou de domínios específicos.
No final do planejamento da Sprint, o Time de Desenvolvimento deve ser capaz de explicar ao

Product Owner e ao Scrum Master como pretende trabalhar como equipe auto-organizada
para completar o objetivo da Sprint e criar o incremento previsto.
Meta da Sprint
A meta da Sprint é um objetivo definido para a Sprint que pode ser satisfeito através da
implementação do Backlog do Produto. Este fornece uma direção para o Time de
Desenvolvimento sobre o porquê de estar construindo o incremento. Este é criado durante a
reunião de planejamento da Sprint. O objetivo da Sprint dá ao Time de Desenvolvimento
alguma flexibilidade a respeito da funcionalidade que será completada dentro da Sprint. Os
itens do Backlog do Produto selecionados entregam uma função coerente, que pode ser o
objetivo da Sprint. O objetivo da Sprint pode ser qualquer outro coerente que faça o Time de
Desenvolvimento trabalhar em conjunto em vez de em iniciativas separadas.
Conforme o Time de Desenvolvimento trabalha, eles mantêm o objetivo da Sprint em mente.

A fim de satisfazer o objetivo da Sprint, implementando funcionalidade e tecnologia. Caso o
trabalho acabe por ser diferente do esperado pelo Time de Desenvolvimento, então eles
colaboram com o Product Owner para negociar o escopo do Backlog da Sprint dentro da
Sprint.
Reunião Diária
A Reunião Diária do Scrum é um evento time-boxed de 15 minutos para o Time de
Desenvolvimento. A Reunião Diária é realizada em todos os dias da Sprint. Nela o Time de
Desenvolvimento planeja o trabalho para as próximas 24 horas. Isso otimiza a colaboração e a
performance do time através da inspeção do trabalho desde a última Reunião Diária, e da
previsão do próximo trabalho da Sprint. A Reunião Diária é mantida no mesmo horário e local
todo dia para reduzir a complexidade.
O Time de Desenvolvimento usa a Reunião Diária para inspecionar o progresso em direção ao

objetivo da Sprint e para inspecionar se o progresso tende na direção de completar o trabalho
do Backlog da Sprint. A Reunião Diária aumenta a probabilidade do Time de Desenvolvimento
atingir o objetivo da Sprint. Todos os dias, o Time de Desenvolvimento deve entender como o
mesmo pretende trabalhar em conjunto, como um time auto-organizado, para completar o
objetivo da Sprint e criar o incremento previsto até o final da Sprint.
A estrutura da reunião é definida pelo Time de Desenvolvimento e pode ser conduzida de

diferentes formas desde que estas foquem no progresso em direção à Meta da Sprint. Alguns
Times de Desenvolvimento utilizarão perguntas, outros se basearão em discussões. Aqui segue
um exemplo do que pode ser utilizado:
• O que eu fiz ontem que ajudou o Time de Desenvolvimento a atingir a meta da Sprint?
• O que eu farei hoje para ajudar o Time de Desenvolvimento atingir a meta da Sprint?
• Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atingimento
da meta da Sprint?
O Time de Desenvolvimento ou membros da equipe frequentemente se encontram

imediatamente após a Reunião Diária para discussões detalhadas, ou para adaptar, ou
replanejar, o restante do trabalho da Sprint.
O Scrum Master assegura que o Time de Desenvolvimento tenha a reunião, mas o Time de
Desenvolvimento é responsável por conduzir a Reunião Diária. O Scrum Master ensina o Time
de Desenvolvimento a manter a Reunião Diária dentro do time-box de 15 minutos.
A Reunião Diária é uma reunião interna do Time de Desenvolvimento. Se outros estiverem

presentes, o Scrum Master deve garantir que eles não perturbem a reunião.
Reuniões Diárias melhoram as comunicações, eliminam outras reuniões, identificam e

removem impedimentos para o desenvolvimento, destacam e promovem rápidas tomadas de
decisão, e melhoram o nível de conhecimento do Time de Desenvolvimento. Esta é uma
reunião chave para inspeção e adaptação.
Revisão da Sprint
A Revisão da Sprint é realizada no final da Sprint para inspecionar o incremento e adaptar o
Backlog do Produto se necessário. Durante a Revisão da Sprint o Time Scrum e as partes
interessadas colaboram sobre o que foi feito na Sprint. Com base nisso e em qualquer
mudança no Backlog do Produto durante a Sprint, os participantes colaboram nas próximas
coisas que podem ser feitas para otimizar valor. Esta é uma reunião informal, não uma reunião
de status, e a apresentação do incremento destina-se a motivar e obter feedback e promover a
colaboração.
Esta é uma reunião de no máximo 4 horas de duração para uma Sprint de um mês. Para Sprints
menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e
que os participantes entendam o seu propósito. O Scrum Master ensina todos os envolvidos a
manter a reunião dentro do Time-box.
A Revisão da Sprint inclui os seguintes elementos:
• Os participantes incluem o Time Scrum e os Stakeholders chaves convidados pelo Product

Owner;
• O Product Owner esclarece quais itens do Backlog do Produto foram “Prontos” e quais não
foram “Prontos”;
• O Time de Desenvolvimento discute o que foi bem durante a Sprint, quais problemas
ocorreram dentro da Sprint, e como estes problemas foram resolvidos;
• O Time de Desenvolvimento demonstra o trabalho que está “Pronto” e responde as
questões sobre o incremento;
• O Product Owner discute o Backlog do Produto tal como está. Ele (ou ela) projeta os
prováveis alvos e datas de entrega baseado no progresso até a data (se necessário);
• O grupo todo colabora sobre o que fazer a seguir, e é assim que a Revisão da Sprint fornece
valiosas entradas para o Planejamento da Sprint subsequente;
• Revisão de como o mercado ou o uso potencial do produto pode ter mudado e o que é a
coisa mais importante a se fazer a seguir; e,
• Revisão da linha do tempo, orçamento, potenciais capacidades, e mercado para a próxima
versão esperada de funcionalidade ou de capacidade do produto.
O resultado da Revisão da Sprint é um Backlog do Produto revisado que define os prováveis

Itens de Backlog do Produto para a próxima Sprint. O Backlog do Produto pode também ser
ajustado completamente para atender novas oportunidades.
Retrospectiva da Sprint
A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e
criar um plano para melhorias a serem aplicadas na próxima Sprint.
A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes do planejamento da

próxima Sprint. Esta é uma reunião de no máximo três horas para uma Sprint de um mês. Para
Sprint menores, este evento é usualmente menor. O Scrum Master garante que o evento
ocorra e que os participantes entendam seu propósito.
O Scrum Master garante que o evento seja positivo e produtivo. O Scrum Master ensina todos
a manter o evento dentro do time-box. O Scrum Master participa da reunião como um
membro auxiliar do time devido a sua responsabilidade pelo processo Scrum.
O propósito da Retrospectiva da Sprint é:
• Inspecionar como a última Sprint foi em relação às pessoas, aos relacionamentos, aos
processos e às ferramentas;
• Identificar e ordenar os principais itens que foram bem e as potenciais melhorias; e,
• Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho;
O Scrum Master encoraja o Time Scrum a melhorar, dentro do processo do framework do

Scrum, seu processo de desenvolvimento e suas práticas para torná-lo mais efetivo e agradável
para a próxima Sprint. Durante cada Retrospectiva da Sprint, o Time Scrum planeja formas de
aumentar a qualidade do produto melhorando o processo de trabalho ou adaptando a
definição de “Pronto”, se apropriado e sem entrar em conflito com os padrões do produto ou
organização.
Ao final da Retrospectiva da Sprint, o Time Scrum deverá ter identificado melhorias que serão
implementadas na próxima Sprint. A implementação destas melhorias na próxima Sprint é a
forma de adaptação à inspeção que o Time Scrum faz a si próprio. Apesar de que melhorias
podem ser implementadas a qualquer momento, a Retrospectiva da Sprint fornece uma
oportunidade formal focada em inspeção e adaptação.
Artefatos do Scrum
Os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de
transparência e oportunidades para inspeção e adaptação. Os artefatos definidos para o Scrum
são especificamente projetados para maximizar a transparência das informações chave de
modo que todos tenham o mesmo entendimento dos artefatos.
Backlog do Produto
O Backlog do Produto é uma lista ordenada de tudo que é conhecido ser necessário no
produto. É a única origem dos requisitos para qualquer mudança a ser feita no produto. O
Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo,
disponibilidade e ordenação.
Um Backlog do Produto nunca está completo. Os primeiros desenvolvimentos estabelecem os

requisitos inicialmente conhecidos e melhor entendidos. O Backlog do Produto evolui tanto
quanto o produto e o ambiente no qual ele será utilizado evoluem. O Backlog do Produto é
dinâmico; mudando constantemente para identificar o que o produto necessita para ser mais
apropriado, competitivo e útil. Se um produto existe, seu Backlog do Produto também existe.
O Backlog do Produto lista todas as características, funções, requisitos, melhorias e correções

que formam as mudanças que devem ser feitas no produto nas futuras versões. Os itens do
Backlog do Produto possuem os atributos de descrição, ordem, estimativa e valor. Os itens do
Backlog geralmente incluem descrições de testes que comprovarão sua completude quando
“Prontos”.
Enquanto um produto é usado e ganha valor, e o mercado fornece feedback, o Backlog do

Produto torna-se uma lista maior e mais completa. Requisitos nunca param de mudar, então o
Backlog do Produto é um artefato vivo. Mudanças nos requisitos de negócio, condições de
mercado ou tecnologia podem causar mudanças no Backlog do Produto.
Múltiplos Times Scrum frequentemente trabalham juntos no mesmo produto. Um Backlog do

Produto é usado para descrever o trabalho previsto para o produto. Um atributo do Backlog do
Produto que agrupe itens pode ser então aplicado.
O refinamento do Backlog do Produto é a ação de adicionar detalhes, estimativas e ordem aos

itens no Backlog do Produto. Este é um processo contínuo no qual o Product Owner e o Time
de Desenvolvimento colaboram nos detalhes dos itens do Backlog do Produto. Durante o
refinamento do Backlog do Produto, os itens são inspecionados e revisados. O Time de Scrum
decide como e quando o refinamento está “Pronto”. Este refinamento usualmente não
consome mais de 10% da capacidade do Time de Desenvolvimento. Contudo, os itens do
Backlog do Produto podem ser atualizados a qualquer momento pelo Product Owner ou a
critério do Product Owner.
Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e
mais detalhados que os itens de ordem mais baixa. Estimativas mais precisas são feitas
baseadas em maior clareza e maior detalhamento; Quanto menor a ordem na lista, menos
detalhes. Os itens do Backlog do Produto que irão ocupar o Time de Desenvolvimento na
próxima Sprint são mais refinados, de modo que todos os itens possam ser “Prontos” dentro
do time-boxed da Sprint. Os itens do Backlog do Produto que podem ser “Prontos” pelo Time
de Desenvolvimento dentro de uma Sprint são considerados “Preparados” para seleção no
Planejamento da Sprint. Itens do Backlog do Produto geralmente adquirem este grau de
transparência através das atividades de refinamento descritas acima.
O Time de Desenvolvimento é responsável por todas as estimativas. O Product Owner deve

influenciar o Time de Desenvolvimento, ajudando no entendimento e nas decisões
conflituosas de troca, mas as pessoas que irão realizar o trabalho fazem a estimativa final.
Monitorando o Progresso a Caminho dos Objetivos

Em qualquer ponto do tempo, o total do trabalho restante para alcançar o objetivo pode ser
somado. O Product Owner acompanha o total do trabalho restante pelo menos a cada Revisão
da Sprint. O Product Owner compara este valor com o trabalho restante nas Revisões das
Sprints anteriores, para avaliar o progresso na direção de completar o trabalho previsto pelo
tempo desejado para alcançar o objetivo. Esta informação deve ser transparente para todas as
partes interessadas.
Várias práticas para prever tendências foram usadas para prever o progresso, tais como burn-
downs, burn-ups, ou fluxos cumulativos. Estas tem se provado úteis. Contudo, não substituem
a importância do empirismo. Em ambientes complexos, o que acontecerá é desconhecido.
Somente o que já acorreu pode ser usado para uma tomada de decisão a respeito do que virá.
Backlog da Sprint
O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint,
juntamente com o plano para entregar o incremento do produto e atingir o objetivo da Sprint.
O Backlog da Sprint é a previsão do Time de Desenvolvimento sobre qual funcionalidade estará
no próximo incremento e sobre o trabalho necessário para entregar essa funcionalidade em
um incremento “Pronto”.
O Backlog da Sprint torna visível todo o trabalho que o Time de Desenvolvimento identifica
como necessário para atingir o objetivo da Sprint. Para garantir melhoria contínua, é incluído
no mínimo um item de prioridade alta sobre melhoria do processo identificado na última
Reunião de Retrospectiva.
O Backlog da Sprint é um plano com detalhes suficientes que as mudanças no progresso sejam
entendidas durante a Reunião Diária. O Time de Desenvolvimento modifica o Backlog da Sprint
ao longo de toda a Sprint, e o Backlog da Sprint vai surgindo durante a Sprint. Este surgimento
ocorre quando o Time de Desenvolvimento trabalha segundo o plano e aprende mais sobre o
trabalho necessário para atingir o objetivo da Sprint.
Sempre que um novo trabalho é necessário, o Time de Desenvolvimento adiciona este ao

Backlog da Sprint. Conforme o trabalho é realizado ou completado, a estimativa do trabalho
restante é atualizada. Quando elementos do plano são considerados desnecessários, eles são
removidos. Somente o Time de Desenvolvimento pode alterar o Backlog da Sprint durante a
Sprint. O Backlog da Sprint é altamente visível, uma imagem em tempo real do trabalho que o
Time de Desenvolvimento planeja completar durante a Sprint, e que pertence exclusivamente
ao Time de Desenvolvimento.
Monitorando o Progresso da Sprint

Em qualquer ponto do tempo na Sprint, o total do trabalho remanescente dos itens do Backlog
da Sprint pode ser somado. O Time de Desenvolvimento monitora o total do trabalho restante
pelo menos a cada Reunião Diária para projetar a probabilidade de alcançar o objetivo da
Sprint. Ao acompanhar o trabalho restante ao longo de toda a Sprint, o Time de
Desenvolvimento pode gerenciar o seu progresso.
Incremento
O incremento é a soma de todos os itens do Backlog do Produto completados durante a Sprint
e o valor dos incrementos de todas as Sprints anteriores. Ao final da Sprint um novo
incremento deve estar “Pronto”, o que significa que deve estar na condição de ser utilizado e
atender a definição de “Pronto” do Time Scrum. Um incremento é uma parte principal
inspecionável de trabalho pronto que suporta empirismo no final da sprint. O incremento é um
passo na direção de uma visão ou de um objetivo. O incremento deve estar na condição de ser
utilizado independente do Product Owner decidir por liberá-lo ou não.
Transparência do Artefato
Scrum invoca transparência. Decisões para otimizar o valor e o controle de riscos são feitos
com base na percepção existente do estado dos artefatos. Na medida em que a transparência
é plena, estas decisões tem uma base sólida. Na medida em que os artefatos não são
completamente transparentes, estas decisões podem ser falhas, valores podem diminuir e
riscos podem aumentar.
O Scrum Master deve trabalhar com o Product Owner, Time de Desenvolvimento, e outras
partes envolvidas para entender se os artefatos estão plenamente transparentes. Há práticas
para lidar com transparência incompleta, o Scrum Master deve ajudar todos a aplicar a mais
apropriada prática na falta de uma transparência plena. O Scrum Master pode detectar
transparência incompleta pela inspeção dos artefatos, percebendo padrões, ouvindo
atentamente o que está sendo dito, e detectando diferenças entre o esperado e os resultados
reais.
O trabalho do Scrum Master é trabalhar com o Time Scrum e com a organização para
aumentar a transparência dos artefatos. Este trabalho geralmente envolve aprendizagem,
convencimento e mudança. Transparência não ocorre de um dia para o outro, mas é um
caminho.
Definição de “Pronto”
Quando um item do Backlog do Produto ou um incremento é descrito como “Pronto”, todos
devem entender o que o “Pronto” significa. Embora, isso possa variar por Time Scrum, os
integrantes devem ter um entendimento compartilhado do que significa o trabalho estar
completo, assegurando a transparência. Esta é a “Definição de Pronto” para o Time Scrum e é
usado para assegurar quando o trabalho esta completado no incremento do produto.
A mesma definição orienta o Time de Desenvolvimento no conhecimento de quantos itens do

Backlog do Produto podem ser selecionados durante o Planejamento da Sprint. O propósito de
cada Sprint é entregar incrementos de funcionalidades potencialmente liberáveis que aderem
à definição atual de “Pronto” do Time Scrum.
O Time de Desenvolvimento entrega um incremento de funcionalidade do produto a cada

Sprint. Este incremento é utilizável, então o Product Owner pode escolher por liberá-lo
imediatamente. Se a definição de “Pronto” para um incremento é parte das convenções,
padrões ou diretrizes de desenvolvimento da organização, todos os Times Scrum devem segui-
la como um mínimo.
Se “Pronto” para um incremento não é uma convenção de desenvolvimento da organização, o

Time de Desenvolvimento do Time Scrum deve definir uma definição de “pronto” apropriada
para o produto. Se há múltiplos Times Scrum trabalhando no sistema ou versão do produto, os
Times de Desenvolvimento de todos os Times Scrum devem mutuamente definir uma
definição de “Pronto”.
Cada incremento é adicionado a todos os incrementos anteriores e completamente testado,
garantindo que todos os incrementos funcionam juntos.
Como um Time Scrum maduro, é esperado que a sua definição de “Pronto” seja expandida
para incluir critérios mais rigorosos de alta qualidade. Novas definições, quando usadas,
podem descobrir trabalho a ser feito em incrementos “Prontos” anteriormente. Qualquer
produto ou sistema deve ter uma definição de “Pronto” que é um padrão para qualquer
trabalho feito sobre ele.
Conclusão
O Scrum é livre e oferecido neste guia. Papéis, eventos, artefatos e regras do Scrum são
imutáveis e embora seja possível implementar somente partes do Scrum, o resultado não é
Scrum. Scrum existe somente na sua totalidade e funciona bem como um container para
outras técnicas, metodologias e práticas.
Agradecimentos
Pessoas
Das milhares de pessoas que tem contribuído com o Scrum, nós devemos destacar aquelas que
foram fundamentais no início. Jeff Sutherland trabalhou com Jeff McKenna e John
Scumniotales, e Ken Schwaber trabalhou com Mike Smith e Chris Martin, e todos eles
trabalharam juntos. Muitos outros contribuíram nos anos subsequentes e sem a ajuda deles o
Scrum não teria sido refinado tanto quanto está hoje.
História
Ken Schwaber e Jeff Sutherland trabalharam no Scrum até 1995, quando fizeram uma co-
apresentação do Scrum na Conferência OOPSLA de 1995. Esta apresentação essencialmente
documentou o aprendizado que Ken e Jeff ganharam ao longo dos anos anteriores, e tornou
pública a primeira definição formal do Scrum.
A história do Scrum é descrita em outros lugares. Para homenagear os primeiros lugares onde
ele foi experimentado e refinado, nós reconhecemos a Individual, Inc., Newspage, Fidelity
Investments, e IDX (atual GE Medical).
O Guia do Scrum documenta o Scrum conforme desenvolvido, evoluído e sustentado por mais
de 20 anos por Jeff Sutherland e Ken Schwaber. Outras fontes fornecem padrões, processos, e
percepções que complementam o Framework Scrum. Estas podem aumentar a produtividade,
valor, criatividade e satisfação com os resultados.
Tradução
Este guia foi traduzido da versão original em inglês, fornecida pelos desenvolvedores
reconhecidos acima. Os colaboradores desta tradução incluem Fábio Cruz e Eduardo Rodrigues
Sucena.
Mudanças entre os Guias Scrum 2016 e 2017
1. Incluído na seção de Usos do Scrum:

O Scrum foi inicialmente desenvolvido para gerenciar e desenvolver produtos. Iniciando
no começo dos anos 90, o Scrum tem sido usado extensivamente, mundialmente, para:
1. Pesquisar e Identificar mercados viáveis, tecnologias e funcionalidades de

produtos;
2. Desenvolver produtos e melhorias;
3. Liberar produtos e melhorias frequentes, chegando a várias vezes por dia;
4. Desenvolver e sustentar a Nuvem (online, segura, sob demanda) e outros
ambientes operacionais para uso de produtos; e,
5. Sustentar e renovar produtos.
Scrum tem sido usado para desenvolver software, hardware, software embarcado, redes
de funções interativas, veículos autônomos, escolas, governo, marketing, gerenciar a
operação da organização e quase tudo que usamos em nosso dia-dia nas nossas vidas,
como indivíduos e sociedades.
Como tecnologia, mercado, complexidades ambientais e suas interações tem aumentado

rapidamente, a utilidade do Scrum em lidar com a complexidade é provada diariamente.
Scrum demonstra efetividade especialmente na transferência de conhecimento iterativo e

incremental. Scrum é agora amplamente usado para produtos, serviços e no
gerenciamento da própria empresa.
A essência do Scrum é um pequeno time de pessoas. O time individual é altamente

flexível e adaptativo. Essas forças continuam operando em únicos, muitos, vários, e em
redes de times que desenvolvem, liberam, operam e sustentam o trabalho e trabalham
produtos de milhares de pessoas. Eles colaboram e interoperam através de arquiteturas
sofisticadas de desenvolvimento e ambientes de liberação como objetivo.
Quando as palavras “desenvolver” e “desenvolvimento” são usadas no Guia Scrum, elas

se referem a trabalho complexo, tais como os tipos identificados acima.
2. Alteração da redação na seção O Scrum Master para fornecer melhor

clareza do papel. O texto agora compreende:
O Scrum Master é responsável por promover e suportar o Scrum como definido no Guia
Scrum. O Scrum Master faz isso ajudando todos a entenderem a teoria, as práticas, as
regras e os valores do Scrum.
O Scrum Master é um servo-líder para o Time Scrum. O Scrum Master ajuda aqueles que
estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis
e quais não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar
o valor criado pelo Time Scrum.
3. Incluído na seção O Scrum Master trabalhando para o Product Owner:

Garantindo que objetivos, escopo e domínio do produto sejam entendidos o melhor
possível por todos do Time Scrum
4. Atualizado o primeiro parágrafo da seção Reunião Diária para ler:

A Reunião Diária do Scrum é um evento time-boxed de 15 minutos para o Time de
Desenvolvimento. A Reunião Diária é realizada em todos os dias da Sprint. Nela o Time de
Desenvolvimento planeja o trabalho para as próximas 24 horas. Isso otimiza a
colaboração e a performance do time através da inspeção do trabalho desde a última
Reunião Diária, e da previsão do próximo trabalho da Sprint. A Reunião Diária é mantida
no mesmo horário e local todo dia para reduzir a complexidade
5. Atualizada a seção Reunião Diária para fornecer clareza sobre os objetivos

da Reunião de Diária incluindo este texto:
A estrutura da reunião é definida pelo Time de Desenvolvimento e pode ser conduzida de
diferentes formas desde que estas foquem no progresso em direção à Meta da Sprint.
Alguns Times de Desenvolvimento utilizarão perguntas, outros se basearão em
discussões. Aqui segue um exemplo do que pode ser utilizado:
• O que eu fiz ontem que ajudou o Time de Desenvolvimento a atingir a meta da

Sprint?
• O que eu farei hoje para ajudar o Time de Desenvolvimento atingir a meta da
Sprint?
• Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no
atingimento da meta da Sprint?
6. Incluído clareza em torno do Time Boxes

Uso das palavras ”no máximo” para remover quaisquer questionamento sobre os eventos
terem uma duração específica certa, e reforçando ao invés disso, que estes são os tempos
máximos permitidos.
7. Incluído na seção Backlog da Sprint:

Para garantir melhoria contínua, é incluído no mínimo um item de prioridade alta sobre
melhoria do processo identificado na última Reunião de Retrospectiva.
8. Incluído clareza na seção Incremento:

Um incremento é uma parte principal inspecionável de trabalho pronto que suporta
empirismo no final da sprint. O incremento é um passo na direção de uma visão ou de um
objetivo.
Ambiente de ensino virtual Log off
Menu
Simulado
Curso e-learning Fundamentos do Scrum - Preparatório para o exame PSM I (novo curso
atualizado) >Simulado Scrum Master 1 - 80 questões em inglês
PRATICAR NOVO SIMULADO CONSULTAR MEU HISTÓRICO ENCERRAR
Se u re sultado ne ste Simulado :
Total de questões:80
Questões que você respondeu:80

Tipo de questões:Múltipla escolha com uma única resposta correta.
Respostas corretas para ser aprovado:68(85%)
Respostas que você acertou:75(93.75%)

Tempo para completar o teste:60 min
Tempo que você usou:

38:07
Fe e dback final:
Parabéns! Você foi bem nesse simulado.
Corre ção das suas re spostas:
Na tabela abaixo a cor laranja indica que você errou a questão e cor verde indica que você acertou.
Clique sobre o número da questão para rolar a página até ela.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80
De talhame nto da corre ção das suas re spostas

As seguintes marcações foram utilizadas nesta correção:

- As perguntas que contêm a figura significa que você acertou a questão.
- As perguntas que contêm a figura significa que você errou a questão, selecionando uma ou
mais opções de resposta incorretas.
- As opções de resposta corretas foram marcadas em cor verde e as opções incorretas selecionadas
por você foram marcadas em cor laranja.
Algumas questões podem apresentar justificativ a para a opção correta logo abaixo. Se após ler a
justificativa ainda houver dúvida, então utilize o fórum de discussão para enviar a sua dúvida para o
tutor. No fórum especifique exatamente o que você não entendeu da questão e também qual é o
código de referência da questão para que o tutor possa localizar a questão que você ficou em dúvida.
O código de referência aparece no final da pergunta e está entre colchetes.
Não pe rmitimos a cópia de conte údo das que stõe s. Se o simulado for em inglês e você precisa
de tradução, utilize o navegador Chrome que tem o tradutor embutido. No Chrome, para traduzir esta
página pressione o botão direito do mouse e escolha no menu contextual "traduzir para o português"
1) Who should make sure everyone does his or her tasks for the Sprint Backlog? [Código de
referência: 3825]
A) The Product Owner

B) The Development Team
C) The project manager
D) The Scrum Master
E) All of the above
JUSTIFICATIVA:
As tarefas do backlog da sprint pertecem à equipe de desenvolvimento. Como ela é auto-gerenciável,
cabe a ela mesma controlar as tarefas que precisam ser feitas.
2) The length of a Sprint should be: [Código de referência: 3826]
A) Short enough to keep the business risk acceptable to the Product Owner.
B) Short enough to be able to synchronize the development work with other business events.
C) No more than one month.
D) All of these answers are correct.
JUSTIFICATIVA:
Todas estas alternativas são considerações apropriadas para determinar a duração da Sprint.
3) Which of the following is NOT a Product Owner´s responsibility? [Código de referência: 3827]
A) Running the Daily Scrum meeting

B) Working with stakeholders to determine and detail product features
C) Gathering requirements for Product Backlog items
D) I ti k tS i tR i
D) Inspecting work at Sprint Review
JUSTIFICATIVA:
O product owner não é responsável pela condução da reunião diária, e sim a equipe de
desenvolvimento. O scrum master deve assegurar que esta reunião aconteça.
O product owner é responsável pela inspeção e aceitação do trabalho durante a revisão da sprint,
por reunir os requisitos para os itens do backlog do produto e por trabalhar em conjunto com as
partes interessadas para determinar características e detalhes do produto.
4) How should items in the Product Backlog be ordered? [Código de referência: 3828]
A) Alphabetically first and then by list order in the Product Backlog

B) Grouped by business features first and then chronologically by date of original business
request
C) Prioritized by business importance first: the items that result in biggest ROI must be priorized
first
D) Chronologically by date of original business request first and then by list order in the Product
Backlog
JUSTIFICATIVA:
Convém que os itens do backlog do produto sejam priorizados por ordem de valor ao negócio. Os
mais importantes devem estar no topo da lista e os menos importantes no fim da lista. Há outras
formas de priorizar além da importância, mas a importância tem um peso maior entre as opções
disponíveis nesta questão.
5) Which of the following is a role in the Scrum framework? [Código de referência: 3829]
A) Database admin
B) Development team
C) QA tester
D) Senior developer
JUSTIFICATIVA:
No scrum há apenas três papéis: o product owner, a equipe de desenvolvimento e o scrum master. O
scrum não reconhece títulos para os integrantes da equipe de desenvolvimento que não seja o de
esenvolvedor, independentemente do trabalho realizado pela pessoa.
6) When might a Sprint be abnormally terminated? [Código de referência: 3830]
A) When it becomes clear that not everything will be finished by the end of the Sprint.
B) When the sales department has an important new opportunity.
C) When the Development Team feels that the work is too hard.
D) When the Sprint Goal becomes obsolete.
JUSTIFICATIVA:
Uma Sprint pode ser cancelada antes do time-box da Sprint terminar. Uma Sprint seria cancelada se a
Meta da Sprint se tornar obsoleta. Isto pode ocorrer se a empresa mudar a direção ou se as
di õ d d t l i d
condições do mercado ou tecnologia mudarem.
7) When multiple teams work together on the same product, each team should maintain a
separate Product Backlog.
[Código de referência: 3831]
A) True
B) False
JUSTIFICATIVA:
Cada produto tem um único Backlog do Produto, independente de quantas equipes forem usadas
para desenvolver no mesmo produto. Qualquer outra configuração pode dificultar a Equipe de
Desenvolvimento para determinar sobre o que irá trabalhar.
8) Why does Scrum prevent Product Owners from changing Product Backlog items that are being
worked on during the Sprint? [Código de referência: 3833]
A) The Development Team cannot meet their Sprint commitment to complete work if requirements
are changing
B) A Sprint cycle is not enough time for senior management to review and approve changes
C) This forces Product Owners to focus on what is really important for the team to develop
D) The Development Team must be able to limit the Product Owner authority
JUSTIFICATIVA:
A equipe de desenvolvimento pode não cumprir o seu compromisso com a sprint caso os requisitos
fiquem mudando o tempo todo. No início da sprint, a equipe de desenvolvimento concordou e se
comprometeu com o product owner sobre quais itens (ou requisitos) seria capaz de entregar ao final
da sprint, e definiu a meta da sprint.
9) Which of the following is not an oficial Scrum artifact? [Código de referência: 3834]
A) User stories
B) Sprint Backlog
C) Product backlog
D) Software increment
JUSTIFICATIVA:
Histórias de usuário não é um artefato padrão do framework scrum definido no scrum guide, apesar
de largamente utilizado pelas equipes que adotam o scrum. Todos os demais fazem parte do
framework scrum.
10) When do Development Team members become the exclusive owner of a Sprint Backlog item?
A) Never. All Sprint Backlog Items are "owned" by the entire Development Team, even though each
one may be done by an individual Development Team member.
B) During the Daily Scrum.
C) At the Sprint planning meeting.
D) Whenever a team member can accommodate more work.
JUSTIFICATIVA:
O backlog da Sprint e todos os itens são coletivamente de propriedade da Equipe de
desenvolvimento. Nenhum membro individual pode requerer a propriedade de um item porque isto
bloquearia a comunicação e e colaboração.
11) Which of the following statements best explains what the term Sprint means in Scrum? [Código
de referência: 3836]
A) A Sprint is a specific amount of days for a team to test and resolve any issues prior to product
release or shipment
B) A Sprint is a specific amount of days for a team to work at a sustainable pace to finish select
work
C) A Sprint is an agreed upon period of time for team members to select individual items from the
Product Backlog to work on
D) A Sprint is a specific amount of days for a team to work as many hours as needed to finish
assigned work
JUSTIFICATIVA:
A sprint é uma quantidade específica de dias para a equipe trabalhar em um ritmo sustentável para
terminar o trabalho (itens do backlog do produto que foram selecionados).
Por que as demais alternativas são incorretas:
A) Durante a sprint é feito TODO o trabalho necessário para transformar requisitos em software
funcionando, e não somente testes e resolução de problemas.
C) A sprint é o momento de realizar todo o trabalho necessário para atingir o objetivo proposto e não
ficar só selecionando itens do backlog do produto.
D) Um dos princípios do desenvolvimento ágil é o conceito de sustentabilidade e não o de esgotar a

equipe. Forçar a equipe a fazer horas extras demasiadas pode causar descontentamentos e
desmotivar a equipe.
12) A Product Owner is entitled to postpone the start of a new Sprint after the conclusion of a
previous Sprint for the following reason: [Código de referência: 3837]
A) The Product Owner has not identified a Sprint Goal.

B) The QA department needs more time to make the previous Increment "Done".
C) The stakeholders are not happy with the value produced in the previous Sprint.
D) There is no acceptable reason. A new Sprint starts immediately after the conclusion of the
previous Sprint.
E) Not enough Product Backlog items are "Ready".
JUSTIFICATIVA:
Uma nova sprint inicia imediatamente após a conclusão da sprint anterior.
13) Which of the following is not a Scrum cycle activity? [Código de referência: 3838]
A) Sprint retrospective
B) Daily scrum
C) Weekly inspection
D) Sprint planning
JUSTIFICATIVA:
Inspeção semanal não é uma atividade válida do ciclo scrum. A inspeção pode ser diária por meio das
reuniões diárias. Todas as outras opções são eventos oficiais.
14) Which of the following statements is true about Product Backlog items? [Código de referência:
3839]
A) Undefined or poorly defined Product Backlog items should be placed on the Product Backlog
with low priority
B) All Product Backlog items are the result of a(n) analysis, requirements and/or design phase(s)
C) Undefined or poorly defined Product Backlog items should be kept out from the Product
Backlog until sufficient detail is known
D) Every Product Backlog item, whether low priority or high priority, should possess sufficient detail
for the team to complete in a Sprint
JUSTIFICATIVA:
Dentre as respostas disponíveis, a que melhor se encaixa é a opção A: itens indefinidos ou mal
definidos devem ser colocados no backlog do produto com baixa prioridade.
Recomenda-se que os itens do backlog de maior prioridade tenham boa definição e detalhes
suficientes, pois estes são os que entrarão nas próximas sprints. No scrum, todos os itens do backlog
do produto devem ser colocados no backlog do produto, mesmo os itens com menos detalhes. Itens
com menos detalhes normalmente são itens de baixa prioridade. Conforme mais detalhes são
conhecidos, eles tendem a receber uma prioridade mais alta. Os itens com mais alta prioridade devem
ser refinados a tal ponto que a equipe de desenvolvimento consiga transformá-los em incremento de
software potencialmente utilizável durante as sprints.
Se você escolheu a opção B, saiba que ela não é a melhor resposta porque não existe fase de
desenho dentro da abordagem Scrum. Isto porque requisitos/itens podem surgir a todo momento
durante todo o projeto, não existe fase específica para levantamento de requisitos.
15) Which of the following is required by Scrum? [Código de referência: 3840]
A) Release Planning
B) Release Retrospective
C) Sprint Burndown chart
D) Members must stand up at the Daily Scrum
E) Sprint Review
F) All of the above
JUSTIFICATIVA:
Das opções, somente a revisão da sprint é um evento obrigatório no scrum.
16) Under what circumstances should separate Product Backlogs be maintained? [Código de
referência: 3841]
A) There are several Product Owners for one product: each Product Owner should have their own
Product Backlog
B) There are multiple teams working on independent products: each unique combination of team
and product should have an independent Product Backlog
C) There are multiple product features being developed by the same team
D) There are multiple teams working on the components of the same product: each team should
have an independent Product Backlog
JUSTIFICATIVA:
Das opções disponíveis, a única situação onde faz sentido manter backlogs de produtos separados
está descrita na segunda opção: quando há múltiplas equipes e múltiplos produtos independentes,
cada combinação única de equipe e produto deve ter um backlog de produto.
17) Who determines whether the Development Team has been assigned enough work in a
Sprint? [Código de referência: 3842]
A) The Development Team

B) The Product Owner
C) The Product Owner and the Scrum Master
D) The Scrum Master
JUSTIFICATIVA:
Somente a equipe de desenvolvimento pode se comprometer com a quantidade de itens que é capaz
de entregar durante uma sprint. Ninguém mais pode dizer à equipe quantos itens ela deve entregar.
Os demais papéis podem ajudar ou influenciar a equipe de desenvolvimento a entender melhor o
trabalho a ser feito e ajustar questões de produtividade e tempo de trabalho. Lembre-se: a equipe de
desenvolvimento é auto-organizada e autogerenciada.
18) Which of the following is not a Product Owner´s responsibility? [Código de referência: 3843]
A) Maintaining the Product Backlog with current information

B) Working with stakeholders to determine and detail product features
C) Assigning tasks to team members
D) Prioritizing the Product Backlog
JUSTIFICATIVA:
O product owner não é responsável pela atribuição de tarefas aos membros da equipe de
desenvolvimento. A própria equipe de desenvolvimento se organiza e define quem fará determinada
atividade (normalmente cada membro da equipe escolhe quais atividades fará). As demais atividades
são de responsabilidade do product owner.
19) Which of the following activities do not occur at the end of the Sprint? (choose 3 answers)
19) Which of the following activities do not occur at the end of the Sprint? (choose 3 answers)
A) Software development
B) Release deployment
C) Sprint Review meeting
D) Quality assurance testing
JUSTIFICATIVA:
A reunião de revisão da sprint é realizada no final de uma sprint. Assim, para uma sprint de 30 dias, a
reunião de revisão de sprint é realizada no trigésimo dia.
Não se engane! Atividades de teste, garantia da qualidade, implantação e desenvolvimento do

software são atividades que devem ser realizadas durante uma sprint, por meio de tarefas do backlog
da sprint. No final de uma sprint não ocorrem mais atividades de desenvolvimento - o final deve ser
reservado para as reuniões de revisão e de retrospectiva da sprint.
20) What does the Scrum Development Team attempt to develop every Sprint? [Código de
referência: 3845]
A) A product that is ready for customer delivery

B) A completed Sprint Backlog
C) A product that is ready for QA and/or QC testing
D) A product increment that is potentially-ready for customer delivery
JUSTIFICATIVA:
A equipe de desenvolvimento deve entregar ao final de uma sprint um incremento de produto
“pronto”, potencialmente utilizável e possível de ser entregue ao cliente.
21) Which two (2) things does the Development Team do during the first Sprint?
A) Develop a plan for the rest of the release.

B) Deliver an increment of releasable software.
C) Develop and deliver at least one piece of functionality.
D) Create the complete Product Backlog to be developed in subsequent Sprints.
E) Determine the complete architecture and infrastructure for the product.
JUSTIFICATIVA:
O coração do Scrum é uma Sprint, um time-box de um mês ou menos durante o qual um incremento
de produto "pronto', usável e potencialmente liberável é criado. Isto se aplica a cada Sprint.
22) The Sprint Planning meeting is comprised of how many sections? [Código de referência:
3847]
A) 4
B) 3
C) 2
D) 1
JUSTIFICATIVA:
A reunião de planejamento da sprint tem duas sessões. Durante a primeira parte, a equipe de
desenvolvimento e o product owner discutem os itens do backlog mais prioritários. A equipe se
compromete com o dono do produto a fazer o seu melhor para completar os itens do backlog
selecionados e estabelece a meta da sprint. Na segunda parte, a equipe de desenvolvimento planeja
as tarefas necessárias, faz as estimativas e cria o backlog da sprint.
23) Please select which of the following statements are true:

(choose 3 answers) [Código de referência: 3848]
A) The Product Owner itemizes which Product Backlog items are done and which Product Backlog
items are not done during Sprint Review
B) The Product Owner demonstrates potentially-shippable product features and/or components
during the Sprint Review
C) The Scrum Master provides a report of what happened during the Sprint
D) The Development Team demonstrates potentially-shippable product features and/or
components during the Sprint Review
E) Feedback from stakeholders during the Sprint Review may result in additional Product Backlog
items
JUSTIFICATIVA:
Opções corretas que ocorrem durante uma reunião de revisão da sprint:
- O feedback das partes interessadas durante a revisão da sprint pode resultar em itens adicionais
para o backlog do produto, porque a partir desta revisão podem surgir novas necessidades.
- A equipe de desenvolvimento deve demonstrar o incremento de software pronto e potencialmente

utilizável durante a revisão da sprint.
- O product owner relaciona/confere quais itens do backlog do produto estão prontos e quais não
estão prontos.
As outras duas opções são incorretas, porque:

- Quem demonstra o produto na reunião de revisão da Sprint é o time de desenvolvimento.
- O time de desenvolvimento é autogerenciado e o Scrum Master não vai fornecer relatório do que
aconteceu durante a Sprint. No máximo o time de desenvolvimento vai discutir isso na reunião de
retrospectiva, mas não em forma de relatório.
24) Who is responsible for managing the progress of work during a Sprint? [Código de referência:
3850]
A) The most junior member of the Team

C) The Development Team
D) The Scrum Master
JUSTIFICATIVA:
A Equipe de Desenvolvimento usa a Reunião Diária para inspecionar o progresso em direção à Meta
da Sprint e para inspecionar como o progresso está indo em direção a completar o trabalho no
Backlog da Sprint.
25) From the activities given, which is the latest step in sequence of the Scrum framework?
A) Daily scrum
B) Sprint retrospective
C) Sprint Review
D) Sprint planning
JUSTIFICATIVA:
O último passo que ocorre em uma sprint é a reunião de retrospectiva da sprint.
26) Which of the following is not a Scrum Master´s responsibility? [Código de referência: 3852]
A) Establish priorities together with the Product Owner for Product Backlog items
B) Preventing senior management from shifting team priorities
C) Empowering the team
D) Socializing scrum throughout the organization
JUSTIFICATIVA:
Fique atento ao enunciado da questão. A questão pergunta: qual dos seguintes NÃO é uma
responsabilidade do Scrum Master. Muitos erram essa questão porque não traduzem o enunciado
corretamente.
O Scrum Master NÃO é o responsável em conjunto com o Product Owner por priorizar os itens do
backlog do produto. Ele pode ajudar o Product Owner a encontrar técnicas mais eficientes para fazer
a priorização, mas quem define se um item é mais prioritário ou não é somente o Product Owner. Por
isso, a resposta correta é a opção A.
Interferências da gerência sênior diretamente sobre a equipe podem atrapalhar o desenvolvimento,

portanto, o Scrum Master pode conversar com a gerência sênior para explicar sobre isto e orientar
sobre a melhor forma de trabalho em conjunto com o Product Owner. Por isso isso, a opção B é uma
declaração que está relacionada a uma responsabilidade do Scrum Master.
O Scrum Master é responsável também por ensinar a equipe a ser autogerenciável (empowering) e
também é o mentor das práticas Scrum na organização (socializing scrum).
27) Which of the following is reflected in a Sprint burndown chart? [Código de referência: 3853]
A) Team members names

B) Number of Product Backlog items completed
C) N b f k i i
C) Number of tasks remaining
D) Work hours remaining
JUSTIFICATIVA:
O objetivo principal do gráfico burndown é ilustrar o trabalho restante durante uma sprint. O gráfico
reflete, para cada dia de trabalho concluído na sprint, uma estimativa de quanto trabalho ainda falta
fazer até que todas as tarefas do backlog da sprint estejam concluídas. O trabalho restante pode ser
mostrado em forma de pontos ou em horas.
28) How many hours per day should a person on a Scrum Team work? [Código de referência:
3854]
A) A sustainable pace, usually from 7-8 hours per day

B) An "ideal day" measuring only when he or she is productive
C) However many hours are needed to get the work done
D) 14 hours
JUSTIFICATIVA:
O scrum tem como filosofia cria um ambiente de trabalho agradável para a equipe. Portanto, a melhor
opção é A.
29) According to Scrum, the amount of time for a team to plan Sprint activities is expressed in
what unit of time? [Código de referência: 3855]
A) Weeks
B) Days
C) Hours
D) Minutes
JUSTIFICATIVA:
De acordo com o scrum, o tempo de planejamento da sprint é expresso em horas. A reunião de
planejamento da sprint tem time-box de oito horas para uma sprint de um mês de duração. Para
sprints menores, este evento deve ser proporcionalmente menor: por
exemplo, uma sprint de duas semanas terá uma reunião de planejamento de sprint de quatro horas.
30) You are the Scrum Master and your Development Team of 6 members has completed six
Sprints with the following information:
Sprint 1: 10 points
Sprint 2: 11 points
Sprint 3: 15 points
Sprint 4: 14 points
Sprint 5: 15 points
Sprint 6: 10 points
The remaining story points for product development totals 42. What is the approximate number of
Sprints required to complete the product development? [Código de referência: 3856]
A) 6
B) 5
C) 4
D) 3
JUSTIFICATIVA:
Primeiro você deve calcular a velocidade (produtividade) da equipe de desenvolvimento. Para isso,
some a quantidade de pontos entregues em cada sprint e divida pela quantidade de sprints.
Velocidade = (10 + 11 + 15 + 14 + 15 + 10)/6 = 12.5.
A equipe de desenvolvimento entrega em média, 12,5 pontos por sprint.
Depois, você determina quantas sprints são necessárias para entregar os itens restantes, estimados
em 42 pontos. Para isso, divida a quantidade restante de pontos pela produtividade da equipe e você
terá a quantidade de sprints restantes.
Sprints = 42/12.5 = 3.36.
Como levará pouco mais de 3 sprints, a resposta mais correta é 4 sprints.
31) Under what circumstances should the Product Backlog be reprioritized? [Código de
referência: 3857]
A) The Scrum Master should reprioritize the Product Backlog only at the end of a new Sprint
B) The Scrum Master should reprioritize the Product Backlog only at the beginning of a new Sprint
C) The team should reprioritize the Product Backlog only at the end of a new Sprint
D) The Product Owner should reprioritize the Product Backlog whenever new information is
learned
JUSTIFICATIVA:
O product owner pode mudar a priorização do backlog do produto sempre que houver necessidade,
especialmente se novas informações são aprendidas. É esperado que o backlog do produto mude
conforme a dinâmica dos negócios ou as necessidades dos clientes/usuários. É esperado que
somente os itens que estejam dentro de uma sprint atual não mudem, para não afetar a meta da
sprint.
32) How could the team and other stakeholders know if a Product Backlog item is done? [Código
A) They should ask to the member`s Development Team

B) They should compare what was done, against the definition of done established by the Scrum
Team
C) Ask the Product Owner
D) Ask to the manager
JUSTIFICATIVA:
A equipe de desenvolvimento define o que é “pronto” com a anuência do product owner. Uma vez
estabelecida a definição de "pronto", esta deve ser comunicada para todas as partes interessadas
(stakeholders) do projeto.
Se uma das partes interessadas não souber qual é esta definição, ele pode perguntar para o product
owner ou para a equipe de desenvolvimento.
Entretanto, a questão não pergunta como obter a definição de pronto e sim como saber se um item
do backlog está pronto. Portanto, espera-se que todos saibam qual é a definição de pronto para
então fazer a comparação com o que foi entregue.
33) What is the primary objective of the Daily Scrum? [Código de referência: 3859]
A) To share with the team what each member has completed in the Sprint, what each member will
work on next, and to report progress roadblocks
B) To give a status report to the Product Owner on what each member has completed in the
Sprint, what each member will work on next, and to report progress roadblocks
C) To discuss work details with the team since every team member must attend the meeting
D) To give a status report to the Scrum Master on what each member has completed in the Sprint,
what each member will work on next, and to report progress roadblocks
JUSTIFICATIVA:
Durante a reunião cada integrante da equipe de desenvolvimento esclarece:
O que foi completado desde a última reunião?
O que será feito até a próxima reunião?
Quais os obstáculos que estão no caminho?
34) Which statement best describes what it means for an activity to be time-boxed? [Código de
referência: 3860]
A) The activity must take place on a particular date

B) The activity must start at a particular time
C) There is a maximum time limit for the activity
D) There is a recommended amount of time for the activity
JUSTIFICATIVA:
No scrum, o termo time-box significa que uma atividade ou evento tem um tempo máximo para acabar.
São exemplos de eventos time-boxed: sprint planning, sprint review e reunião diária, entre outros.
35) Which statement below best describes the primary objective of the Sprint Review? [Código de
referência: 3861]
A) The primary objective of the Sprint Review is to demonstrate the Sprint´s work for senior
management
B) The primary objective of the Sprint Review is to demonstrate the Sprint´s work and to receive
feedback from the Product Owner(s) on the work completed in the Sprint
C) The primary objective of the Sprint Review is to demonstrate the Sprint´s work and to receive
feedback from the Scrum Master on the work completed in the Sprint
D) The primary objective of the Sprint Review is to demonstrate the Sprint´s work and to
recommend ways to work better in the Sprint
JUSTIFICATIVA:
Essa reunião serve para apresentar o produto desenvolvido para o product owner, e para que a
Essa reunião serve para apresentar o produto desenvolvido para o product owner, e para que a
equipe receba feedback sobre o produto e também receba aceitação quanto aos itens desenvolvidos.
Após a apresentação das funcionalidades pela equipe de desenvolvimento, o product owner deve
fornecer feedback para a equipe: o que gostou, o que não gostou, se está de acordo com o que os
usuários querem e o que precisa melhorar na próxima sprint em relação ao produto entregue.
Uma reunião de sprint review sem feedback e aceitação do product owner não é verdadeiramente
uma reunião de revisão de sprint.
36) One of the benefits from Scrum is that the Development Team doesn´t have to
write detailed specifications anymore. [Código de referência: 3862]
A) True
B) False
JUSTIFICATIVA:
Um dos mitos sobre Scrum é que ele impede de escrever especificações detalhadas.
Na realidade, o Product Owner e a equipe de desenvolvimento podem decidir quanto de
detalhe é necessário e isso irá variar de um item de backlog para o outro, dependendo da
discernimento e maturidade da equipe, entre outros fatores. Itens de baixa prioridade têm menos
detalhes, enquanto os de alta prioridade e tendem a ter mais detalhes.
37) You are the Scrum Master. The Sprint will complete in two days. Each day of the Sprint is
equivalent to 8 hours. The team has just enough time to complete all tasks in the remaining 16 hours
with the exception of three tasks. Of these three tasks, two tasks (a total of 6 hours) are required to
complete one Product Backlog item and one task (an estimate of 2 hours) is required to complete
another Product Backlog item. How should the Development Team handle the remaining three tasks?
A) The Development Team should negotiate with the Product Owner on the definition of "Done"
B) The Development Team should work the extra 8 hours to complete their commitment to the
Product Owner
C) The Development Team should place the two Product Backlog items back into the Product
Backlog
D) The Development Team should keep the three tasks on the Sprint Backlog for the next Sprint
and complete those tasks first
JUSTIFICATIVA:
A equipe de desenvolvimento deve colocar os dois itens que não foram concluídos de volta no
backlog do produto. Todo trabalho que não foi acabado na sprint deve obrigatoriamente voltar para o
backlog do produto. O product owner deve determinar qual a prioridade destes itens inacabados em
relação aos novos itens priorizados.
Dentre as opções, a melhor resposta é devolver os dois itens maiores para o backlog do produto.
Fica implícito escolhendo esta resposta que o outro item que só tem 2 horas de duração estimada
seria feita em hora extra. Considerando que a equipe deve trabalhar em um ritmo sustentável, 1 hora
extra por dia não seria tão difícil.
38) Which statement below best describes the primary objective of the Sprint Retrospective?
38) Which statement below best describes the primary objective of the Sprint Retrospective?
A) The primary objective of the Sprint Retrospective is to identify what went wrong or hindered the
Sprint
B) The primary objective of the Sprint Retrospective is to provide feedback to the Product
Owner(s)
C) The primary objective of the Sprint Retrospective is to recommend ways to work better in the
Sprint
JUSTIFICATIVA:
O principal objetivo da reunião de retrospectiva da sprint é identificar oportunidades de melhoria para
a equipe executar melhor as futuras sprints. A equipe deve refletir e discutir “o que correu bem” e “o
que deu errado” na sprint com a única finalidade de propor recomendações para melhorar a equipe,
as entregas e/ou as práticas da equipe.
A opção A embora parecida com a opção C só trata de identificar problemas e não de propor
soluções.
39) Which of the following is not reflected in a Sprint burndown chart? [Código de referência:
3865]
A) Total days in Sprint

B) Number of tasks remaining
C) Day of Sprint
D) Work hours remaining
JUSTIFICATIVA:
O número de tarefas restantes não é ilustrado em um gráfico burndown da sprint. O objetivo principal
do gráfico burndown da sprint é ilustrar o trabalho restante durante uma sprint. O gráfico reflete, para
cada dia finalizado na Sprint, uma estimativa de quanto trabalho resta até que as tarefas do backlog
da sprint sejam concluídas.
40) What artifact shows actual versus planned progress? [Código de referência: 3866]
A) User stories
B) Burndown chart
C) Task breakdown
JUSTIFICATIVA:
O gráfico burndown exibe o trabalho planejado em relação ao trabalho realizado. O gráfico burndown
mostra claramente o trabalho esperado e o trabalho restante.
41) Wich of the following is NOT part of the Sprint? [Código de referência: 3867]
A) The product is released to customers after each Sprint

B) The principal goal for a Sprint is to produce release-quality increments in functionality
C) Releases usually incorporate the result of multiple Sprints
D) Occur at times dictated by customer and business needs
JUSTIFICATIVA:
Após uma sprint, a equipe de desenvolvimento entrega um incremento de software pronto e
potencialmente utilizável e que PODE ser implantando (shippable).
Ainda que após a sprint o software possa ser implantado e distribuído aos clientes, isso nem sempre
é feito porque para alguns clientes e tipos de negócio uma atualização de software no ambiente de
produção muito frequente (por exemplo: 2 vezes por mês se considerarmos sprints com duração de 2
semanas) pode gerar riscos para a organização.
Atualizar um software em produção sempre gera riscos, especialmente para grandes organizações.
Quem decide se o incremento gerado na sprint será liberado em uma nova versão para os clientes é
o product owner.
42) What is the maximum amount of time a Sprint Retrospective should take? [Código de
referência: 3868]
A) 1 hour
B) 1 and half hour
C) 3 hours, for a 30 days Sprint
JUSTIFICATIVA:
Esta é uma reunião time-boxed de três horas para uma sprint de um mês. Proporcionalmente um
tempo menor é alocado para sprints menores.
43) What happens when all commited itens (requirements) are not completed at the end of the
A) The Sprint duration is extended

B) The tasks are determined to be unnecessary
C) They return to the Product Backlog
D) None of the above
JUSTIFICATIVA:
Os itens do backlog do produto que foram selecionados para a aprint e que ao final dela não estão
finalizados de acordo com a definição de "pronto" devem voltar para o backlog do produto. O product
owner deve priorizar novamente estes itens, juntamente com os itens que já estavam no backlog do
produto. Se forem novamente priorizados, podem entrar na próxima sprint e a equipe de
desenvolvimento então conclui os trabalhos. Considere que uma sprint é time-boxed, portanto não
pode ultrapassar a duração determinada.
44) A multinational company, which has five major products, is using Scrum for product
development. Which statements are the two best alternatives for how many Product Owners should
exist? [Código de referência: 3870]
exist? [Código de referência: 3870]
A) One and only one: the Product Owner may not delegate to others for specific value,
capabilities, and functionality within the product
B) One specific Product Owner is responsible for each product, and he/she may delegate to
others for specific value, capabilities, and functionality within the product
C) One specific Product Owner is responsible for all five products, and he/she may delegate to
others for specific value, capabilities, and functionality within each product
D) As many as needed to communicate expectations and requirements to the Development Teams
JUSTIFICATIVA:
Para cada backlog de produto deve existir somente uma pessoa que assuma o papel de product
owner. A mesma pessoa pode ser product owner de mais de um produto: não há problema nisto se
ela conseguir desempenhar bem suas responsabilidades. Além disto, o scrum guide diz que o product
owner pode realizar suas responsabilidades ou delega-las para a equipe de desenvolvimento - mas
neste caso o product owner continua sendo o responsável pelo trabalho, ou seja, ele é o responsável
final.
45) Is Scrum Master a management position?

A) Yes
B) No
JUSTIFICATIVA:
Uma grande dificuldade para a maioria dos candidatos é a falta de conhecimento sobre o idioma
inglês. Muitos não traduzem corretamente as questões e tem entendimento errado. Esta é uma
questão que geralmente alguns traduzem "management" como "gerente" e está errado". A tradução
correta desta questão é:
"O Scrum Master é uma posição gerencial?"
A resposta é SIM, porém é uma posição de gerenciamento de PROCESSO e não de pessoas. O

Scrum Master gerencia o processo Scrum. O Scrum Master não exerce chefia sobre o time de
desenvolvimento ou sobre o
dono do produto.
46) Who is on the Scrum Team? (choose 3 answers)

A) Project manager
B) Project owner
C) Product owner
D) Development team
E) Manager
F) CEO
G) Scrum master
JUSTIFICATIVA:
A equipe scrum é formada por três papéis: equipe de desenvolvimento, scrum master e product
owner
owner.
47) What is the recommended size for a Development Team? [Código de referência: 3873]
A) 6, +3 or -3
B) 9
C) 6
D) 7, +2 or -2
JUSTIFICATIVA:
O tamanho adequado de uma equipe de desenvolvimento é que ela seja pequena o suficiente para
ser ágil e grande o suficiente para completar o trabalho que deve ser feito. Tipicamente uma equipe
de scrum tem entre 6 e 3 integrantes. Desta forma, pode variar de 3 a 9 participantes (o scrum master
e o product owner não entram nesta contagem).
48) Who is required to attend the Daily Scrum? [Código de referência: 3874]
A) The Scrum Master

C) The Development Team and the Product Owner
D) The Development Team and the Scrum Master
JUSTIFICATIVA:
Apenas as pessoas que fazem o trabalho descrita no Backlog da Sprint precisam participar da
reunião Diária do Scrum. Se o Scrum Master ou Product Owner também estão na equipe de
desenvolvimento, então eles terão de estar também na Reunião Diária. Caso contrário, o Scrum
Master tem que simplesmente garantir que a Equipe de Desenvolvimento saiba como conduzir uma
Reunião Diária. Nada impede que qualquer compareça nessa reunião como ouvinte, afinal o Scrum
prega a transparência. Entretanto, somente membros da Equipe de Desenvolvendo participam
ativamente.
49) On a new Scrum Team, the Development Team tells the Scrum Master that it doesn´t feel the
need for retrospectives. which answer is correct?
A) Discuss with the Product Owner

B) Start doing retrospectives
C) None of the above
JUSTIFICATIVA:
Esta é uma pegadinha. Veja que se trata de uma equipe nova. Se for nova, provavelmente ainda não
começaram a fazer todas as práticas do scrum, e se estão querendo deixar de fazer algo é porque
não estão vendo valor na prática. Logo, começar a fazer a reunião de retrospectiva é a melhor
maneira de entender o valor que isso traz para a equipe. E realizar a reunião de retrospectiva não é
opcional no scrum: é obrigatório.
50) The Product Backlog is mainteined by: [Código de referência: 3876]

A) The Scrum Master
C) The Product Owner
D) The Product Owner and the Scrum Master
JUSTIFICATIVA:
O product owner é responsável pelo backlog do produto, incluindo seu conteúdo, disponibilidade e
ordenação.
51) What is Scrum? [Código de referência: 3877]
A) A framework within which people can address complex adaptive problems, while productively
and creatively delivering products of the highest possible value
B) It`s not na agile framework
C) Scrum is a complete process to develop software
JUSTIFICATIVA:
Scrum é um framework no qual pessoas podem tratar e resolver problemas complexos enquanto
produtiva e criativamente entregam produtos com o mais alto valor possível.
52) The Product Backlog is ordered by: [Código de referência: 3878]
A) Size, where small items are at the top and large items are at the bottom.
B) Risk, where safer items are at the top, and riskier items are at the bottom.
C) Least valuable items at the top to most valuable at the bottom.
D) Importance, where the most important items are at the top at all times.
E) Whatever is deemed most appropriate by the Product Owner.
JUSTIFICATIVA:
O dono do produto decide o que faz mais sentido para otimizar o valor do trabalho que está sendo
feito pelo time de desenvolvimento.
53) Who has the authority to cancel a Sprint? [Código de referência: 3879]
A) The team members

B) The Scrum Master
D) The project manager
JUSTIFICATIVA:
Somente o produtc owner tem autoridade para cancelar uma sprint. Ele faz isso quando a sprint não
faz mais sentido (normalmente porque o objetivo da sprint não faz mais sentido).
54) Who defines the Sprint Backlog scope? [Código de referência: 3880]
B) The Development Team in agreement with the Product Owner
C) The Scrum Master
D) The stakeholders
JUSTIFICATIVA:
Na parte 1 da reunião de planejamento da sprint, a equipe de desenvolvimento prevê as
funcionalidades que serão desenvolvidas durante a sprint. O product owner apresenta os itens de
backlog do produto ordenados para a equipe de desenvolvimento, e toda a equipe scrum colabora
com o entendimento do trabalho da sprint. Durante a sprint, caso o trabalho acabe por ser diferente
do esperado pela equipe de desenvolvimento, esta negocia com o product owner o escopo do
backlog da sprint dentro da sprint.
55) What is the major difference between Product Backlog and Sprint Backlog? [Código de
referência: 3881]
A) The Product Backlog is equal to the Sprint Backlog

B) The Product Backlog is a subset of the Sprint Backlog
C) The Sprint Backlog is a subset of the Product Backlog
D) The Sprint Backlog is owned by the Product Owner
JUSTIFICATIVA:
O backlog da sprint é formado por itens do backlog do produto que foram selecionados, além das
atividades necessárias para transformar esses itens em incremento de software. Cada item
selecionado do backlog do produto é quebrado em tarefas menores. Desta forma, as respectivas

tarefas sempre serão itens menores do item selecionado do backlog do produto. Assim, o backlog da
sprint é um subconjunto do backlog do produto.
56) As the Sprint Planning progresses, the workload has grown beyond the Development Team's
capacity. Which action makes most sense for the Development Team? [Código de referência: 3882]
A) Work overtime for the Sprint

B) Collaborate with the Product Owner and potentially remove or change items
C) Cancel the Sprint
D) Start the Sprint and recruit additional team members
JUSTIFICATIVA:
Quando a equipe de desenvolvimento identifica que se comprometeu com uma quantidade de itens
maior que sua capacidade de produção ou que terá tempo disponível para produzir mais itens do que
os selecionados para a sprint, ela chama o product owner e eles trabalham em conjunto para
adicionar ou remover itens. Os itens que são adicionados ou removidos não podem comprometer a
realização da meta da sprint: se isso acontecer, a sprint pode ser cancelada.
57) How should multiple Scrum Teams deliver a done, potentially shippable increment in a Sprint
for a project? [Código de referência: 3883]
A) Each Sprint, all Scrum Teams have a done increment that integrates with all of the other done
i t f ll th S T th i iti ti th f ll f i t i th i t
increments from all other Scrum Teams on the initiative; the sum of all of increments is the increment
for that initiative or project
B) Each Scrum Team provides a unique done increment that includes the team´s added
functionality
C) Functionality not integrated with the work of other Scrum Teams may be delivered as
unintegrated increments; this demonstrates the value created by the Scrum Teams unable to
completely integrate their increments
D) Each Scrum Team delivers done increments of its own area of responsibility; these increments
are integrated into a whole product during stabilization prior to release
JUSTIFICATIVA:
Se houver mais de uma equipe scrum no mesmo projeto, é importante que exista integração entre os
incrementos gerados pelas diferentes equipes.
58) What happens when the Sprint is cancelled? [Código de referência: 3884]
A) The Scrum Team disbands immediately

B) The complete Sprint Backlog is put back to the Product Backlog
C) The completed Sprint Backlog items are evaluated for a release and incomplete items are
discarded
D) The completed Sprint Backlog items are evaluated for a release and incomplete items are put
back in the Product Backlog
JUSTIFICATIVA:
Quando a sprint é cancelada, qualquer item de backlog do produto completado e “pronto” é revisado.
Se uma parte do trabalho estiver potencialmente utilizável, tipicamente o product owner o aceita.
Todos os itens de backlog do produto incompletos são reavaliados e colocados de volta no backlog
do produto. O trabalho feito deprecia-se rapidamente e deve ser frequentemente reavaliado.
59) What is the release burndown? [Código de referência: 3885]
A) A graph indicating what has been completed by the Scrum Team

B) A measure of the remaining Product Backlog across the time of a release plan
C) What has been completed by the Scrum Team to date
D) The work remaining to be completed by the Product Owner
JUSTIFICATIVA:
O gráfico de release burndown pode ser visto como uma medida do Backlog do Produto
remanescente ao longo do tempo em um plano de release.
O eixo horizontal de um Release Burndown Chart mostra as Sprints; o eixo vertical mostra a
quantidade de trabalho que ainda precisa ser feita no início de cada Sprint. O trabalho que ainda
resta pode ser mostrado na unidade preferencial da equipe: pontos de histórias, dias ideais, e assim
por diante. Então, de certa forma, o que está sendo representado no eixo vertical é o Backlog do
Produto remanescente em forma de pontos de história ou outra medida.
60) Choose two responsibilities of a self-organizing Development Team. [Código de referência:

3886]
A) Report daily progress to stakeholders

A) Report daily progress to stakeholders
B) Increase velocity
C) Pull Product Backlog items for the Sprint
D) Do the work planned in the Sprint Backlog
E) Reorder the Product Backlog
JUSTIFICATIVA:
Espera-se que uma equipe de desenvolvimento auto-organizada tenha autonomia dentro dos seus
limites de atuação. Neste caso, cabe a ela melhorar continuamente sua velocidade e fazer o trabalho
planejado no backlog da sprint.
Deixar que a equipe de desenvolvimento reporte o progresso diário para os stakeholders é um

esforço que não agrega valor na visão ágil.
Puxar itens do backlog para a sprint sem colaboração com o product owner não é indicado.
Importante que o PO esteja presente durante a reunião de planejamento da Sprint para que a equipe
selecione os itens que vão ser desenvolvidos na Sprint atual.
A reordenação do backlog do produto é de responsabilidade do product owner.
61) More than one Scrum Team is working on a single project or release. How should the Product
Backlog be arranged? [Código de referência: 3887]
A) A separate Product Backlog is constructed for each Scrum Team; all of the increments are
integrated at the end in an integration Sprint
B) All Scrum Teams work from a common Product Backlog and integrate their work every Sprint
C) Only one Scrum Team should work on a scrum project
D) Scrum Teams should have their separate Product Backlogs
JUSTIFICATIVA:
Múltiplas equipes scrum trabalhando para a produção de um único produto devem ter apenas um
backlog do produto e devem produzir uma única versão integrada do produto.
62) When many Scrum Teams are working on a project, what best describes the definition of
"done"? [Código de referência: 3888]
A) All teams must use the same definition

B) Each team defines and uses its own
C) Each team uses its own but must make it clear to all other teams
D) It depends
JUSTIFICATIVA:
Todas as equipes scrum do mesmo projeto devem usar a mesma definição de "pronto" para facilitar a
integração dos incrementos.
63) When many Scrum Teams are working on the same product, should all of their increments be
integrated every Sprint? [Código de referência: 3889]
A) No, that is far too hard
B) No, each Scrum Team stands alone
C) Yes, but only the scrum`s teams whose work has dependencies
D) Yes, otherwise Product Owners may not be able to inspect what is done accurately
JUSTIFICATIVA:
Se vários Times Scrum estão trabalhando para entregar um único produto, é absolutamente
necessário integrar o trabalho concluído por cada time em suas respectivas sprints para que o
product owner possa avaliar o trabalho feito com precisão.
64) What is the primary responsibility of the Scrum Master? [Código de referência: 3890]
A) To prioritize the Product Backlog

B) To remove any impediments the Development Team encounters during their work
C) To work with the Product Owner to develop the Product Backlog
D) To manage the Development Team
JUSTIFICATIVA:
O PRINCIPAL papel do scrum master é o de remover qualquer impedimento encontrado pela equipe
de desenvolvimento e que afete o seu trabalho.
65) Which three of the following are true about Scrum? [Código de referência: 3891]
A) Scrum is like traditional processes but with self-organization to replace project managers
B) Scrum is based on empirical process control theory
C) Scrum is a methodology, where you can pick and choose which parts of scrum you think will
work for your environment
D) Scrum is a framework for developing and maintaining complex products
E) Each component of scrum serves a specific purpose, and is essential to scrum´s success
JUSTIFICATIVA:
O scrum não é metodologia e as equipes auto-organizadas não substituem completamente o trabalho
dos típicos gerentes de projetos, pois há atividades de gestão que continuam sendo desempenhadas
pelo scrum master e pelo product owner.
66) Who is the Sprint Backlog owned by? [Código de referência: 3892]
A) The Scrum Master

D) The Scrum Master and the Development Team
JUSTIFICATIVA:
A equipe de desenvolvimento é a dona do backlog da sprint. Somente a equipe de desenvolvimento
pode alterar o backlog da sprint.
67) Which objectives are covered as part of the Sprint Planning? [Código de referência: 3893]
A) Understanding what functionality the Product Owner desires within the next Sprint and figuring
out how to do it
B) Updating the scope of the release with all Sprints, end dates, and costs
C) Reviewing current functionality that binds the software solution
D) Recalculating empirical velocity, adjusting team capacity accordingly, and projecting end dates
JUSTIFICATIVA:
O planejamento da sprint tem duas partes. Na parte 1 é feito o entendimento de "o quê" o product
owner deseja. Na parte 2 é discutido "como" entregar os itens que foram selecionados.
68) The Development Team should have all the skills needed to: [Código de referência: 3894]
A) Complete the project as estimated when the date and cost are committed to the Product Owner
B) Turn the Product Backlog it selects into an increment of potentially shippable product
functionality
C) Do all of the development work, but not the types of testing that require specialized testing,
tools, and environments
JUSTIFICATIVA:
A equipe de desenvolvimento é responsável por realizar todas as atividades necessárias para
entregar o incremento de software ao final de uma sprint. A equipe de desenvolvimento deve ser
formada por uma equipe multifuncional. Isso significa que os membros da equipe deverão possuir
habilidades suficientes para desenvolver, testar, criar/desenhar interfaces gráficas, etc. - ou seja,
tudo que é preciso para entregar o software funcionando. A equipe não pode depender de alguém
externo para realizar as atividades necessárias durante a Sprint: ela deve ser capaz e ter habilidades
para fazer tudo que precisa ser feito.
69) Who determines when it is appropriate to update the Sprint Backlog during a Sprint?
A) The project manager

B) The Scrum Team
D) The Product Owner
JUSTIFICATIVA:
O Scrum Guide é bem claro: somente a equipe de desenvolvimento pode alterar o Backlog da Sprint
durante a Sprint. PO pode negociar junto a equipe de desenvolvimento alteração de algum item
selecionado desde que não afete o objetivo da Sprint, mas ele não pode modificar tarefas ou
qualquer detalhe do Backlog da Sprint. Dentro do Backlog da Sprint o PO não mete a mão!!!! Este
backlog é de propriedade da equipe de desenvolvimento. Lembrar que o backlog da sprint é o plano
de trabalho da equipe de desenvolvimento, contém as tarefas e todos os detalhes para cumprir os
itens selecionados para Sprint. Somente a equipe pode dizer como ela vai cumprir os itens
selecionados. PO não interfere neste planejamento.
70) Which of these may a Development Team deliver at the end of a Sprint?
) y p p
A) A single document, if that is what the Product Owner asked for

B) An increment of software with minor known bugs in it
C) Failing unit tests, to identify acceptance tests for the next Sprint
D) An increment of working software that is "Done"
JUSTIFICATIVA:
Após uma sprint, a equipe de desenvolvimento deve entregar ao product owner e às partes
interessadas algum software funcionando de acordo com a definição de "pronto" acordada. Ao final
da sprint, a equipe de desenvolvimento entrega na verdade um incremento de software pronto e
potencialmente utilizável (software rodando). Ela não precisa entregar todo o software pronto, até
porque isso seria praticamente impossível, mas o incremento, ou seja, a nova parte do software
integrada com as outras partes já prontas deve ser funcional.
71) Which three activities will a Product Owner likely engage in during a Sprint? [Código de
referência: 3897]
A) Run the Daily Scrum

B) Answer questions from the Development Team about items in the current Sprint
C) Update the Sprint burndown chart
D) Work with the stakeholders
E) Prioritize the Development team`s activities
F) Provide feedback
JUSTIFICATIVA:
Durante a sprint, o dono do produto provavelmente:
- Responderá a questões da equipe de desenvolvimento sobre itens da sprint atual
- Trabalhará junto aos stakeholders (clientes, usuários, mercado) para identificar novas
funcionalidades, coletar feedback, analisar necessidades dos usuários, etc. para então
adicionar/alterar/priorizar as funcionalidades do backlog do produto (se necessário)
- Fornecerá feedback, especialmente para a equipe de desenvolvimento, durante a revisão da sprint
O product owner não participa e não é o responsável pela reunião diária. Também não atualiza o
gráfico burndown da sprint e muito menos prioriza as atividades da equipe de desenvolvimento. Ele
prioriza os itens do backlog do produto, mas a equipe de desenvolvimento é auto-organizada e ela
própria define suas tarefas e prioridades.
72) Development team members volunteer to own a Sprint Backlog item:

A) During the Daily Scrum

B) Whenever a team member can accommodate more work
C) N ll S i t B kl It " d" b th ti D l tT th h
C) Never; all Sprint Backlog Items are "owned" by the entire Development Team, even though
each one may be done by an individual team member
D) At the Sprint Planning meeting
JUSTIFICATIVA:
Essa é uma pergunta pegadinha. Veja que a pergunta afirma que cada membro da equipe de
desenvolvimento voluntariamente escolhe de quais tarefas será o "dono". Para o scrum, todos os
membros da equipe de desenvolvimento são responsáveis por todas as tarefas, ainda que cada
tarefa possa ser feita individualmente por um membro.
73) Which two are properties of the Daily Scrum? [Código de referência: 3899]
A) It is fifteen minutes or less in duration

B) It is facilitated by the team lead
C) It consists of the Scrum Master asking the team members the three questions
D) Its location and time should remain constant
JUSTIFICATIVA:
A reunião diária é um evento time-boxed de 15 minutos (ou menos) que deve ocorrer todos os dias
durante uma sprint, exceto nos dias da reunião de planejamento da sprint e de revisão e retrospectiva
da sprint. Nesses dias, a equipe planejará a próxima sprint ou entregará as funcionalidades ao
product owner. O tempo máximo de duração é de 15 minutos, não importando se a duração da sprint
é de 2, 3 ou 4 semanas. Esta reunião geralmente acontece em pé (afinal, são somente 15 minutos) e

de preferência no mesmo local e mesmo horário para reduzir a complexidade.
74) What is the primary way a Scrum Master keeps a Development Team working at its highest
level of productivity? [Código de referência: 3900]
A) By ensuring the meetings start and end at the proper time

B) By facilitating Development Team decisions and removing impediments
C) By preventing changes to the backlog once the Sprint begins
D) By keeping high value features high in the Product Backlog
JUSTIFICATIVA:
O scrum master é um servo-líder para a equipe de desenvolvimento. Dentre todas as suas
atribuições, remover impedimentos e facilitar (agir como um consultor) as decisões da equipe de
desenvolvimento geram os melhores resultados para manter a equipe com alta produtividade, pois
fazem com que a equipe se concentre apenas no trabalho que agrega valor para o produto.
75) What are the two primary ways a Scrum Master keeps a Development Team working at its
highest level of productivity? [Código de referência: 3901]
A) By removing impediments that hinder the Development Team

B) By facilitating Development Team decisions
C) By starting and ending the meetings at the proper time
D) By keeping high value features high in the Product Backlog
JUSTIFICATIVA:
Um Scrum Master é um lider-servo para a Equipe de Desenvolvimento. Facilitar e remover
impedimentos ajuda a equipe para alcançar a melhor produtividade possível.
76) Which of the following might the Scrum Team discuss during a Sprint Retrospective? [Código
A) Methods of communication
B) The way the Scrum Team does Sprint Planning
C) Skills needed to improve the Development Team`s ability to deliver
D) Its definition of done
E) All of the above
JUSTIFICATIVA:
A reunião de retrospectiva da sprint é a reunião de lições aprendidas, realizada logo após a reunião
de revisão da sprint. Esta reunião é MAIS sobre o PROCESSO e MENOS sobre o PRODUTO.
Todas as opções listadas são itens que podem ser discutidos durante a retrospectiva da sprint, pois
são relacionados ao processo e à maneira pela qual a equipe desenvolve o produto
77) Which three questions are answered by all Development Team members at the Daily Scrum?
A) What work am I going to do today?

B) Why were you late?
C) What impediments are in the way of my accomplishing my work?
D) What work did I do yesterday?
E) How is the Sprint proceeding?
JUSTIFICATIVA:
Durante a reunião, cada membro do time deve responder a três perguntas básicas:
- O que eu fiz desde a última reunião?
- O que vou fazer até a próxima reunião?
- Há alguma coisa impedindo o meu trabalho?
78) When is the Sprint Backlog created?

A) At the beginning of the project

B) Prior to the Sprint Planning meeting
C) During the Sprint
D) During the Sprint Planning meeting
JUSTIFICATIVA:
A segunda parte da reunião de planejamento da sprint se inicia logo após o término da primeira O
A segunda parte da reunião de planejamento da sprint se inicia logo após o término da primeira. O
desafio é discutir como implementar os itens selecionados. Os itens selecionados do backlog do
produto mais as tarefas necessárias para transformá-los em software “pronto” e potencialmente
utilizável são chamados de backlog da sprint. O backlog da sprint é o resultado da segunda parte da
reunião de planejamento da sprint.
79) The Sprint Goal is selected before the Sprint Backlog is created. [Código de referência: 3905]
A) True
B) False
JUSTIFICATIVA:
A primeira parte da reunião de planejamento da sprint é onde a equipe analisa e avalia os itens do
backlog do produto, seleciona os itens que acredita ter condições de entregar na sprint e define uma
meta para a sprint. Então, ao final da parte 1, a equipe tem duas coisas importantes: os itens que vai
desenvolver e a meta da sprint.
80) Who should know the most about the progress toward a business objective or a release, and
be able to explain the alternatives most clearly? [Código de referência: 3906]

B) The Scrum Master
D) The Development Team
JUSTIFICATIVA:
O product owner é responsável pela macro gerência do projeto de desenvolvimento. É responsável
também por fazer o planejamento das liberações e decidir quando faz sentido liberar ou não uma
versão do software. Se alguém dentro ou fora da empresa quiser saber como está o andamento geral
do projeto de desenvolvimento, deve procurar o product owner.
Evite a pirataria
Para que continuemos desenvolvendo novos cursos com preços acessíveis, contamos com a sua colaboração. O conteúdo dos
nossos cursos não pode ser redistribuído de qualquer forma ou por qualquer meio. Somente o aluno devidamente inscrito nos
cursos poderá fazer uso dos nossos materiais. Se você identificar que alguém está usando indevidamente o conteúdo dos
nossos cursos, ou distribuindo-o ilegalmente, por favor avise-nos imediatamente através do e-mail contato@tiexames.com.br.
Leia a licença de uso de uso dos nossos conteúdos
SOBRE NÓS
Depoimentos de alunos
Blog
Quem somos
Perguntas frequentes
Fale conosco
O QUE OFERECEMOS
Cursos e-learning
Cursos ao vivo
Informações sobre exames
ACESSO ALUNO
Login ambiente de ensino
Termos de uso
Política de privacidade
$perc_questoes_certa
Menu
Simulado

Tipo de questões:Múltipla escolha podendo mais de opção a ser marcada como correta.


22:36
Fe e dback final:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80


1) Upon what type of process control is Scrum based? [Código de referência: 4047]
A) Hybrid
B) Defined
C) Complex
D) Empirical
JUSTIFICATIVA:
Scrum não é um processo previsível. É um processo empírico, ou seja, usa a experiência da equipe e
da experimentação para resolver os problemas e as situações do dia a dia.
2) What is the maximum time that Scrum recommends the team spend in the Daily Scrum?
A) Fifteen minutes
B) Thirty minutes
C) One hour
D) Four hours
E) As long as it takes
JUSTIFICATIVA:
A reunião diária do scrum é um evento com tempo limitado a 15 minutos, para que a equipe de
desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24 horas.
3) Which topics should be discussed in the Sprint Review? [Código de referência: 4049]
A) The process
B) Coding practices
C) All of the above
)
D) Sprint results
JUSTIFICATIVA:
A revisão da sprint é executada no final da sprint para inspecionar o incremento (resultados da sprint)
e adaptar o backlog do produto se necessário. As demais opções de resposta desta pergunta são
tratadas na reunião de retrospectiva da sprint.
4) What is the time-box for the Sprint Retrospective of a Sprint with one month of duration?
A) As long as required
B) 1 hour
C) 2 hours
D) 3 hours
JUSTIFICATIVA:
A retrospectiva da sprint ocorre depois da revisão da sprint e antes da reunião de planejamento da
próxima sprint. Esta é uma reunião com tempo limitado a 3 horas para uma sprint de um mês.
Proporcionalmente um tempo menor é alocado para sprints menores.
5) Who must conform to the definition of done? [Código de referência: 4051]

C) The Scrum Team
D) The QA department
JUSTIFICATIVA:
Quando o item do backlog do produto ou um incremento é descrito como “pronto”, todos devem
entender o que “pronto” significa. Embora isso varie significativamente em cada equipe scrum, os
integrantes devem ter um entendimento compartilhado do que significa o trabalho estar completo,
assegurando a transparência. Esta é a “definição de pronto” para a equipe scrum e é usada para
assegurar que o trabalho está completado no incremento do produto. Lembre que a equipe scrum
inclui o scrum master, o product owner e a equipe de desenvolvimento.
6) Which statement is an incorrect assessment of the Product Owner? [Código de referência:

4052]
A) The Product Owner plays a dual role: Product Owner and Scrum Master
B) The Product Owner is the only person responsible for the Product Backlog
C) The Product Owner prioritizes the Product Backlog
D) The Product Owner is one person and not a committee
JUSTIFICATIVA:
O product owner não deveria ser o scrum master devido a conflito de interesses. O ideal é que sejam
pessoas distintas para cada papel
pessoas distintas para cada papel.
7) When should the Product Owner ship or implement a Sprint increment? [Código de referência:
4053]
A) At the end of every Sprint

B) When the team feels it is done with every Sprint
C) Whenever the increment is free of defects
D) When it makes sense
JUSTIFICATIVA:
O incremento do produto deve ser usável e potencialmente liberável ao final de cada sprint, mas isto
não significa que ele sempre tenha que ser liberado. O product owner tem a opção de implementar
um incremento do produto após o término de cada sprint, se assim o desejar. Neste caso, o
incremento deve estar pronto para isso. Então a melhor opção de resposta é quando a liberação do
incremento fizer sentido.
8) When does Scrum Team membership change? [Código de referência: 4054]
A) Every Sprint, to promote team learning

B) As needed, while taking into account short term reduction in productivity
C) Never, because it reduces productivity
D) Whenever management tells the Scrum Team
JUSTIFICATIVA:
A equipe scrum precisa ter o conjunto correto de indivíduos com um conjunto de habilidades diversas
para atender às necessidades do produto. Mudanças na composição da equipe devem ser evitadas
para minimizar o impacto para a entrega da sprint. Entretanto, isto não impede que haja a
necessidade de troca de membros, por conta de membros que decidiram sair da empresa ou que
foram trocados de equipes.
9) As the Sprint Planning meeting progresses, the workload is getting to be greater than the
Development Team´s capacity. Which two actions make the most sense to do? [Código de referência:
4055]
A) Start the Sprint and recruit additional Development Team members

B) Ask the Development Team to work overtime for this Sprint and promise that it won´t happen
again
D) The Development Team ensures that the Product Owner is aware, starts the Sprint and
monitors progress
E) Remove or change selected Product Backlog items
JUSTIFICATIVA:
Nesta situação, poderia-se remover ou trocar itens com prioridade menor em acordo com o product
owner. Também seria aceito que a equipe informasse ao product owner que ela acha que não
conseguirá fazer todos os itens e ir monitorando o progresso ao longo da sprint.
Não faz sentido:
- Cancelar a Sprint (o melhor é ajustar o que pode ser feito)
- Pedir para que a equipe faça horas extras (o scrum é totalmente contra isto)
- Recrutar mais membros para a Sprint (isto atrapalharia o ritmo de desenvolvimento)
10) Multiple Scrum Teams working on the same product or system all select work from same
Product Backlog. [Código de referência: 4056]
A) True
B) False
JUSTIFICATIVA:
Quando várias equipes estão trabalhando no mesmo produto vão usar o mesmo Backlog de Produto
para selecionar o trabalho (itens).
11) Which of the below are main Scrum roles in a Scrum Team? [Código de referência: 4057]
A) Product owner and customers

B) Development team, Product Owner, and Scrum Master
C) Scrum master, customers, Product Owners, stakeholders, and developers
D) Team, users, and competitors
JUSTIFICATIVA:
Os principais papéis do scrum em uma equipe scrum são product owner, equipe de desenvolvimento
e scrum master.
12) What is the best term to define the function of the Scrum Master? [Código de referência:
4058]
A) Customer
B) Developer
C) Servant leader
D) Stakeholder
JUSTIFICATIVA:
O scrum master é melhor descrito como um servo-líder, pois a sua principal função é a de servir à
equipe scrum removendo impedimentos e garantindo a adesão a diretrizes e procedimentos ágeis.
13) When is a Sprint over? [Código de referência: 4059]
A) When all Sprint Backlog items meet their definition of "Done"

B) When all the tasks are completed
C) When the Product Owner says it is done
D) When the time-box expires
JUSTIFICATIVA:
A sprint termina quando o limite de tempo (time-box) expira. A sprint é um evento com tempo limitado
A sprint termina quando o limite de tempo (time box) expira. A sprint é um evento com tempo limitado
e deve ser encerrada quando o tempo terminar.
14) What part of the Sprint Backlog is used for the Sprint burndown chart? [Código de referência:
4060]
A) The percentage of work completed by each team member

B) The number of Product Backlog items completed by all the team members
C) The actual time spent on each task by each team member
D) The remaining time required to complete each task by each team member
JUSTIFICATIVA:
No gráfico burndown da sprint tem que ser representado o esforço total da Sprint que pode se em
pontos de história ou em horas. Nada impede de considerar as horas das tarefas, já que no Backlog
da Sprint os itens selecionados são decompostos em tarefas. O que está em jogo na questão não é
"cada tarefa" e nem "cada membro" e sim o tempo para completar todas as tarefas ou itens
selecionados. Se você tem o tempo requerido para completar cada tarefa que vai ser executada por
cada membro, então você tem o tempo total. Então, não há nada de errado nesta questão. Ela está
desta forma justamente para confundir o candidato.
15) The Sprint Goal is a result of the Sprint Planning, as is the Sprint Backlog. [Código de
referência: 4061]
A) True
B) False
JUSTIFICATIVA:
Durante a parte 1 da reunião de planejamento da Sprint, a equipe de desenvolvimento prevê os itens
de backlog do produto que irá entregar na sprint e a equipe scrum determina a meta da sprint. Na
parte 2, os itens de backlog do produto selecionados para a sprint e seus planos de entrega formam
o backlog da sprint.
16) When a Development Team determines that it will not be able to finish the complete forecast,
who has to be present when reviewing and adjusting the Sprint work selected? [Código de referência:
4062]
A) The Product Owner and the Development Team

C) The Scrum Master, project manager and Development Team
D) The Product Owner and all stakeholders
JUSTIFICATIVA:
Como vai envolver a remoção de um item do Backlog da Sprint, é importante a presença do Dono do
Produto a fim de confirmar que o que está sendo removido tem menos prioridade ou não vai
comprometer a meta da Sprint.
17) When should the Sprint Retrospective be held? [Código de referência: 4063]
A) At the end of the last Sprint in a project or release
B) At the beginning of each Sprint
C) Only when the Scrum Team determines it needs one
D) At the end of each Sprint
JUSTIFICATIVA:
A retrospectiva da sprint deve ocorrer no final de cada sprint para rever aspectos relacionadas a
pessoas, processos, relacionamentos e ferramentas, a fim de coletar lições aprendidas e fazer
melhorias para as sprints futuras.
18) Assuming a 2-week Sprint, what is the time-box for the Sprint Review? [Código de referência:
4064]
A) 2 hours at the end of every Sprint

B) 15 minutes
C) However long is needed
D) 4 hours
JUSTIFICATIVA:
Esta é uma reunião com tempo limitado a 4 horas de duração para uma sprint de um mês.
Proporcionalmente um tempo menor é alocado para sprints menores. Por exemplo, uma sprint de
duas semanas tem reuniões de revisão de duas horas.
19) Which statement best describes the Sprint Review? [Código de referência: 4065]
A) It is used to build team spirit

B) It is a time allocated to judge the validity of the project
C) It gives stakeholders an opportunity to inspect the product increments and progress to date,
and to provide feedback
D) It is a review of the team´s activities during the Sprint
JUSTIFICATIVA:
A reunião de revisão da sprint é executada no final da sprint para inspecionar o incremento e adaptar
o backlog do produto se necessário. Durante esta reunião, a equipe scrum e as partes interessadas
colaboram sobre o que foi feito na sprint. Com base nisso e em qualquer mudança no backlog do
produto durante a sprint, os participantes colaboram nos próximos itens que precisam estar prontos.
Esta é uma reunião informal e a apresentação do incremento destina-se a motivar e obter
comentários e promover a colaboração.
20) Who is ultimate responsible for the Product Backlog item estimates? [Código de referência:
4066]
A) The Scrum Master

C) The stakeholders
JUSTIFICATIVA:
A equipe de desenvolvimento é responsável por todas as estimativas. O product owner pode
influenciar a equipe, ajudando no entendimento e nas decisões conflituosas de troca, mas os
desenvolvedores que irão realizar o trabalho são responsáveis pelas estimativas.
21) What is a Development Team responsible for? (Choose 2 answers.)

A) Selecting the Product Owner

B) Resolving internal team conflicts
C) Organizing the work required to meet the Sprint Goal
D) Reporting productivity
JUSTIFICATIVA:
Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e
gerenciar seu próprio trabalho. Eles devem ser incentivados a resolver por conta própria seus
conflitos internos.
Reportar a produtividade não é uma responsabilidade, uma vez que isto ocorre naturalmente por
conta da transparência. Não é necessário gerar relatórios para isto.
22) The Scrum Master observes the Product Owner struggling with ordering the Product Backlog.
What would you consider an appropriate action for the Scrum Master to take? [Código de referência:
4068]
A) Present the Product Owner with an ordered Product Backlog to use

B) Offer the Product Owner help in understanding that the goal of ordering the Product Backlog is
to maximize value.
C) Suggest that the Development Team does the ordering to be sure that it is a feasible ordering
of work
D) Suggest the Product Owner extend the Sprint, so he can have more time to order the Product
Backlog
E) Encourage the Product Owner to work with the Development Team to see which items
technically are fastest to implement
JUSTIFICATIVA:
O scrum master (SM) serve ao product owner (PO) de várias maneiras, incluindo na busca de
técnicas para o gerenciamento efetivo do backlog do produto. O PO é a única pessoa responsável
por gerenciar o backlog do produto. O gerenciamento do backlog do produto inclui ordenar seus itens
para melhor realizar metas e missões. Neste sentido, o SM pode apenas ajudar o PO orientando
como se faz a ordenação. Não cabe ao SM:
- Apresentar a ordenação pronta para o PO
- Pedir para que equipe de desenvolvimento faça esta ordenação (ela pode no máximo ajudar)
- Sugerir a extensão da Sprint (ela é um evento time-boxed que deve ser cumprido rigorosamente)
- Pedir que se faça antes o que for mais fácil tecnicamente (deve-se fazer o que gerar mais valor para
o negócio)
23) Who must do all the work to make sure Product Backlog items conform to the definition of
“ ? C f
“done?” [Código de referência: 4069]
A) The Scrum Master

D) The Scrum Team
JUSTIFICATIVA:
Esta questão se refere a garantir (verificar) que todo o trabalho foi feito para atender à definição de
"pronto". Se fosse só realizar o trabalho para entregar um incremento atendendo à definição de
"pronto", caberia exclusivamente à equipe de desenvolvimento.
É durante a reunião de revisão da sprint que a equipe scrum e as partes interessadas colaboram
sobre o que foi feito na sprint, verificando o que está "pronto".
24) When is it most appropriate for a Development Team to change the definition of “Done”?
A) Prior to starting a new Sprint

B) Prior to starting a new project
C) During Sprint Planning
D) During the Sprint Retrospective
JUSTIFICATIVA:
Durante cada Retrospectiva da Sprint, o Time Scrum planeja formas de
aumentar a qualidade do produto, adaptando a definição de “Pronto”quando apropriado. A reunião
de Retrospectiva é o melhor momento para fazer esta adaptação.
25) What´s the Scrum Team definition of "done"? [Código de referência: 4071]
A) Whatever the Scrum Master wants it to be

B) Whatever the Product Owner wants it to be
C) Whatever the stakeholders want it to be
D) Whatever the Scrum Team defines "Done" to be
JUSTIFICATIVA:
É extremamente importante que a equipe scrum estabeleça a definição de "pronto" a fim de definir o
que entregar a cada sprint.
26) A Scrum Team is only allowed to meet with stakeholders during the Sprint Review. [Código de
referência: 4072]
A) True
B) False
JUSTIFICATIVA:
O scrum guide estabelece que a equipe de desenvolvimento pode convidar outras pessoas para
participar da reunião de planejamento da sprint de forma a obter opinião técnica ou de domínios
específicos. Então a sprint review não é a única reunião em que partes interessadas externas podem
participar.
27) A Sprint can be canceled by whom? [Código de referência: 4073]
A) The Scrum Master

B) The Sprint team
C) The management
JUSTIFICATIVA:
Somente product owner tem autoridade para cancelar a sprint, embora ele possa fazer isso sob
influência das partes interessadas, da equipe de desenvolvimento ou do scrum master.
28) For a one month Sprint, how much time should be dedicated for the Sprint Planning activity?
A) 8 hours
B) Whatever time is needed
C) 1 month
D) 4 hours
JUSTIFICATIVA:
A reunião de planejamento da sprint é limitada a 8 horas de duração para uma sprint de um mês.
Para sprints menores, este evento deve ser proporcionalmente menor. Por exemplo: uma sprint de
duas semanas terá uma reunião de planejamento de 4 horas.
29) A properly functioning Scrum Team will have at least one release Sprint and may well have
several. [Código de referência: 4075]
A) True
B) False
JUSTIFICATIVA:
Qualquer adjetivo em frente a palavra "Sprint" é inválido. Pois no Scrum não existem Sprints de
Testes, de Estabilização, de Arquitetura, de Liberação, etc. Todas as Sprints são normais.
No scrum, dizemos que no final cada sprint as equipes precisam ter produzido um "incremento de
produto potencialmente entregável." No entanto, "potencialmente entregável" e "entregável" não são
a mesma coisa. A definição de "pronto" para uma sprint pode não ser a mesma definição de "pronto"
para uma liberação. Alguns projetos grandes ou complexos vão exigir o uso de uma sprint de release
(de liberação) no final de um ciclo de release (por exemplo: 6 sprints normais e depois 1 ou 2 sprints
de release). Projetos menores talvez não precisem de sprints de release.
Nas sprints de release ocorre a preparação do sistema para que ele possa ser liberado em
produção/vendas. Esta preparação inclui preparar a help desk para suporte ao produto, terminar a
documentação para o usuário, elaborar material de treinamento e treinar os usuários, entre outras
ç p , ,
atividades. Apesar de sprints de release não serem consideradas eventos oficiais dentro do
framework scrum, todas estas atividades abordadas anteriormente precisam ser realizadas para que
o software possa ser liberado em produção e nem sempre há tempo para acomodá-las dentro das
sprints normais. Sendo assim, apesar de sprints de release não serem descritas no framework, elas
podem ser usadas. No entanto, não se pode afirmar que uma ou mais sprints de release sejam
necessárias para que se tenha um bom funcionamento da equipe scrum. Sendo assim, a afirmação
desta questão é falsa.
30) In the Sprint Planning meeting, the Product Owner and the Development Team were unable to
reach a clear understanding about the highest order of Product Backlog items. Because of this, the
Development Team couldn´t figure out how much functionality it could forecast for the upcoming
Sprint. They were able to agree on a Sprint Goal, however. Which of the following two actions should
the Scrum Master support? [Código de referência: 4076]
A) Ask everyone to take as much time as needed to analyze the Product Backlog first, and then
reconvene another Sprint Planning meeting
B) Forecast the most likely Product Backlog to meet the goal and create a Sprint Backlog based
on a likely initial design and plan; once the time-box for the Sprint Planning meeting is over, start the
Sprint and continue to analyze, decompose, and create additional functionality during the Sprint
C) Discuss in the upcoming Sprint Retrospective why this happened and what changes will make it
less likely to happen again
D) Cancel the Sprint, send the entire team to an advanced scrum training and then start a new
Sprint
E) Continue the Sprint Planning meeting past its time-box until an adequate number of Product
Backlog items are well enough understood for the Development Team to make a complete forecast;
then start the Sprint
JUSTIFICATIVA:
A ideia do evento time-boxed é que a equipe foque no problema e tente solucionar o que for possível
dentro do limite de tempo. Então neste caso a equipe deve considerar o que for mais provável no
backlog do produto e criar um backlog de sprint com base no plano e no desenho iniciais. É
importante considerar que em nenhum lugar do scrum guide é estabelecido que o backlog da sprint
ficará congelado: este backlog pode mudar, tanto para incluir mais detalhes para desenvolver o que
foi selecionado inicialmente na reunião de planejamento da sprint como para incluir novos itens do
backlog do produto se sobrar tempo durante a sprint. O próprio scrum guide diz que o escopo da
sprint pode ser renegociado entre o product owner e a equipe de desenvolvimento.
E por fim, como foi uma falha no processo, isto deve ser discutido na reunião da retrospectiva da
sprint para então estudar a causa e propor correções.
31) When is a Product Backlog item considered complete? [Código de referência: 4077]
A) When all defined tasks are complete

B) When QA reports that it passes all acceptance criteria
C) When it adheres to the definition of "Done"
D) At the end of the Sprint
JUSTIFICATIVA:
O backlog de produto é considerado concluído quando todos os itens foram concluídos e atendem à
definição de "pronto".
definição de pronto .
32) Which statement is an incorrect assessment of the Development Team? [Código de

referência: 4078]
A) It is self-organizing
B) It is responsible for the Sprint Backlog
C) It is cross-functional
D) It is made up of fifteen members of various set of skills
JUSTIFICATIVA:
O tamanho ideal de uma equipe de desenvolvimento é quando ela é pequena o suficiente para ser
ágil e grande o suficiente para completar o trabalho que deve ser feito. Tipicamente, uma equipe
pode variar entre 3 a 9 participantes (o scrum master e o product owner não entram nesta contagem).
Portanto, está errado afirmar que a equipe de desenvolvimento é formada por 15 membros.
33) What does it mean for a Development Team to be cross-functional? [Código de referência:
4079]
A) The Development Team is a virtual team drawing from separate teams of business analysts,
architects, developers, and testers
B) The Development Team includes cross-skilled individuals who are able to contribute to do what
is necessary to deliver an increment of software
C) Developers on the Development Team work closely with business analysts, architects,
developers, and testers who are not on the team
D) The Development Team includes not only developers but also business analysts, architects,
developers, and testers
JUSTIFICATIVA:
Isto significa que os membros da equipe deverão possuir habilidades suficientes para desenvolver,
testar, criar e desenhar interfaces gráficas, ou seja, tudo que é que realmente necessário para
entregar um incremento de software funcionando.
34) What is the recommended size for a Development Team within the Scrum Team? [Código de
referência: 4080]
A) 6 plus or minus 3
B) 3 plus or minus 1
C) 15 plus or minus 3
D) 9 plus or minus 2
JUSTIFICATIVA:
Tipicamente, uma equipe de desenvolvimento tem entre 3 e 6 pessoas, ou seja, pode variar de 3 a 9
participantes (o scrum master e o product owner não entram nesta contagem).
35) Which statement best describes the Sprint Backlog as an outcome of the Sprint Planning?
A) E ht ki ti t di h
A) Each task is estimated in hours
B) It is the Development Team´s plan for the Sprint
C) It is ordered by the Product Owner
D) It is a complete list of all work to be done in a Sprint
E) Every item has a designated owner
JUSTIFICATIVA:
Durante a reunião de planejamento da sprint, os itens de backlog do produto são selecionados para a
sprint e um plano inicial de entrega destes itens é criado. Isto forma o que é chamado de backlog da
sprint.
Uma vez criado o backlog da sprint, este pertencerá exclusivamente à equipe de desenvolvimento.
Somente ela poderá planejar o desenvolvimento dos itens selecionados.
É preciso considerar que nem sempre o backlog da sprint sairá totalmente detalhado da reunião de
planejamento da sprint. Este backlog pode ser modificado durante a sprint.
36) The maximum duration of the Sprint is highly recommended to be: [Código de referência:
4082]
A) 5 days
B) 10 days
C) 15 days
D) Less than a month
JUSTIFICATIVA:
A sprint é uma iteração de tempo limitada a 30 dias.
37) As the Sprint Planning progresses, the workload has grown beyond the team´s capacity.
Which action makes most sense for the team? [Código de referência: 4083]
A) Work overtime for the Sprint

B) Collaborate with the Product Owner and potentially remove or change items
D) Start the Sprint and recruit additional team members
JUSTIFICATIVA:
Sempre que um item precisa ser alterado ou removido da sprint, isto tem que ser feito em um
processo colaborativo entre a equipe de desenvolvimento e o product owner.
Só a equipe de desenvolvimento pode saber o quanto ela será capaz de entregar, e tudo que é
alterado na sprint pode impactar a meta da sprint -cque é um acordo feito com o product owner.
Além disto, existem itens que podem ser mais prioritários que outros e a prioridade é definida pelo
product owner.
Cancelar uma sprint não faz muito sentido nesta situação. Trabalhar em horas extras não é algo
Ca ce a u a sp t ão a u to se t do esta s tuação aba a e o as e t as ão é a go
defendido pelo scrum. E recrutar membros para uma sprint é pode atrapalhar o ritmo da equipe.
38) What does it mean to say that an event is timeiboxed? [Código de referência: 4084]
A) The event must take at least a minimum amount of time

B) The event must happen by a given time
C) The event must happen at a set time
D) The event can take no more than a maximum amount of time
JUSTIFICATIVA:
No Scrum, um evento time-boxed significa que ele NÃO pode demorar mais de uma quantidade
limitada de tempo. Muitos candidatos erram esta questão porque não souberam traduzir corretamente
"The event can take no more". "No more" significa "não mais". O evento time-boxed deve ocorrer
dentro do limite dele. Ele até pode terminar antes, mas não pode demorar mais que o máximo
permitido.
39) What is the role of management in Scrum? [Código de referência: 4085]
A) Monitor the Development Team´s productivity.

B) Continually monitor staffing levels of the Development Team.
C) Support the Product Owner with insights and information into high value product and system
capabilities. Support the Scrum Master to cause organizational change that fosters empiricism, self-
organization, bottom-up intelligence, and intelligent release of software.
D) To identify and remove people that aren’t working hard enough
JUSTIFICATIVA:
O papel principal da gerência é trabalhar com o product owner para definir a visão e a estratégia para
orientar a direção geral do negócio.
Como dito na opção certa: a gerência deve apoiar o scrum master na remoção de impedimentos da
equipe de desenvolvimento.
As demais opções são incorretas porque maximizar e otimizar a produtividade da equipe de

desenvolvimento em relação ao ROI é um papel do product owner. A gerência não vai monitorar
qualquer atividade da equipe de desenvolvimento. A gerência não é responsável pelo pessoal da
equipe de desenvolvimento: o product owner é responsável e deve estar ciente do pessoal exigido
pela equipe de desenvolvimento para maximizar sua produtividade.
Lembre-se que parte do antigo papel de gerente de projetos é assumida parcialmente pelo product
owner. A equipe de desenvolvimento é autogerenciável de forma que a decisão de remover alguém
da equipe deve ser uma decisão da própria equipe de desenvolvimento.
40) Using Scrum ensures that adding more resources to a project proportionally increases the
value delivered. [Código de referência: 4086]
A) True
B) False
JUSTIFICATIVA:
Adicionar mais pessoas à equipe ou adicionar mais equipes ao projeto não vai aumentar o valor
daquilo que está sendo entregue. Apenas a velocidade de entrega pode será ser aumentada.
41) When a Development Team determines that it has over-committed itself for a Sprint, who has
to be present when reviewing and adjusting the Sprint work selected? [Código de referência: 4087]
A) The Scrum Master, the project manager, and the Development Team
C) The Product Owner and the Development Team
D) The Product Owner and all stakeholders
JUSTIFICATIVA:
O product owner é o dono do backlog do produto e a equipe de desenvolvimento é a dona do backlog
da sprint. Itens do backlog do produto e itens do backlog da sprint estão ligados entre si: um item de
backlog do produto é transformado em incremento em forma de um ou mais itens do backlog da
sprint.
Se a equipe de desenvolvimento assumiu um compromisso durante a reunião de planejamento da

sprint para entregar uma série de itens do backlog do produto e durante a sprint entende que a
estimativa está errada e não pode entregar os incrementos esperados, então ela precisa negociar
com o product owner sobre como ajustar ou remover itens da sprint.
Ajustar também pode significar a redução do escopo de um item do backlog do produto. Tenha em
mente que a qualidade dentro do scrum nunca é negociada. Então, um item pode ter seu escopo
reduzido, mas nunca a sua qualidade. Por esta razão, ao rever ou ajustar o trabalho da sprint, tanto o
product owner quanto a equipe de desenvolvimento devem estar presentes.
Quanto às outras alternativas: gerente de projeto não é um papel no scrum. A equipe de

desenvolvimento é autogerida e decide como transformar um item de backlog do produto em um
incremento de trabalho. A definição dos itens do backlog do produto que serão transformados em um
incremento de trabalho é uma decisão do product owner, que representa a si mesmo e a todas as
partes interessadas como a única autoridade sobre o backlog do produto.
42) Who is responsible for updating the work estimates during a Sprint? [Código de referência:
4088]
A) The Scrum Master

D) The most junior member of the team
JUSTIFICATIVA:
A equipe de desenvolvimento é responsável pela atualização das estimativas de trabalho durante a
sprint inteira. A equipe de desenvolvimento também fica encarregada de atualizar o backlog da sprint,
que contém estimativas de trabalho e a lista de tarefas a serem executadas durante a sprint.
43) How much work must a Development Team do to a Product Backlog item it selects for a
43) How much work must a Development Team do to a Product Backlog item it selects for a
A) As much as it has told the Product Owner will be done for every Product Backlog item it selects
in conformance with the definition of done
B) As much as it can fit into the Sprint. Any remaining work will be transferred to a subsequent
Sprint.
C) Analysis, design, programming, testing and documentation
D) The best it can do given that it is usually impossible for QA to finish all of the testing that is
needed to prove shippability
JUSTIFICATIVA:
Existe um compromisso da equipe de desenvolvimento a cada Sprint de entregar um incremento
potencialmente utilizável de acordo com a definição de "pronto". A equipe de desenvolvimento não
pode selecionar os itens do backlog do produto aleatoriamente: isto deve ser feito em acordo com o
product owner.
As outras opções não são corretas pois:

- Nem toda sprint gera algum tipo de documentação
- Não existe área de QA (Quality Assurance) no scrum
- Não pode ser simplesmente o que puder ser acomodado na sprint, pois o que for desenvolvido deve
estar de acordo com a definição de "pronto"
44) The CEO asks the Development Team to add a “very important” item to the current Sprint.
What should the Development Team do? [Código de referência: 4090]
A) Add the item to the current Sprint and drop an item of equal size
B) Add the item to the next Sprint
C) Inform the Product Owner so he/she can work with the CEO
D) Add the item to the current Sprint without any adjustments
JUSTIFICATIVA:
O scrum guide estabelece que o product owner pode representar o desejo de um comitê no backlog
do produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de backlog do
produto devem convencer o product owner. A escolha do que vai para o backlog da sprint atual é algo
feito de forma colaborativa envolvendo a equipe de desenvolvimento e o product owner. Então, neste
caso, o CEO deve convencer o product owner sobre a adição de um item na sprint.
45) A product Increment must be released to production at the end of each Sprint. [Código de
referência: 4091]
A) False
B) True
JUSTIFICATIVA:
O incremento precisa ser entregue potencialmente utilizável, mas não necessariamente deve ser
liberado em produção no final de cada sprint. Esta é uma decisão que cabe somente ao dono do
produto.
46) Which two things does the Development Team not do during the first Sprint? [Código de
referência: 4092]
A) Develop a plan for the rest of the project

B) Nail down the complete architecture and infrastructure
C) Develop and deliver at least one piece of functionality
D) Deliver an increment of potentially shippable functionality
JUSTIFICATIVA:
O escopo de uma sprint é entregar um ou mais incrementos de funcionalidade de acordo com a
definição de "pronto". A equipe de desenvolvimento nunca irá desenvolver um plano para todo o
projeto. A equipe de desenvolvimento trabalha para detalhar os itens do backlog do produto que
devem ser entregues até o final da sprint. O plano da equipe de desenvolvimento está limitado à
sprint atual ou futura e está sujeito a alterações. E a equipe de desenvolvimento implanta apenas a
arquitetura e a infraestrutura necessárias para cumprir a meta da sprint – nem mais, nem menos.
47) What three techniques should the Scrum Master use when the Scrum Team gets caught in an
internal disagreement about which development techniques to apply? [Código de referência: 4093]
A) Ask an external technical specialist to make the decision

B) Use coaching techniques like open questions and active listening
C) Involve the complete team
D) Consult with team members individually, carefully listening
E) Send every team member to the company´s HR department to express their concerns
JUSTIFICATIVA:
Um desentendimento interno na equipe que não puder ser resolvido completamente pela própria
equipe de desenvolvimento se transforma em impedimento, e em todo impedimento o scrum master
precisar ser envolvido. Ele é um servo-líder, não pode tomar decisões pela equipe para não interferir
no seu autogerenciamento. Neste sentido, cabe a ele ouvir atentamente a posição de cada membro e
envolver a equipe toda para chegar a um acordo.
48) The time-box for the complete Sprint Planning meeting is: [Código de referência: 4094]
A) 8 hours for a monthly Sprint, proportionately less for shorter Sprints

B) 4 hours
C) Monthly
D) Whenever it is done
JUSTIFICATIVA:
A reunião de planejamento da sprint é dividida em duas partes de quatro horas cada, para uma Sprint
de um mês. Se a duração da sprint está definida para ser menor que um mês, a reunião de
planejamento de sprint terá seu tempo reduzido proporcionalmente. Por exemplo, para uma sprint de
duas semanas o limite é de 4 horas e para uma sprint de uma semana é de 2 horas.
49) It is important that the product increment be released to production or shipped to customers
at the end of each Sprint. [Código de referência: 4095]
A) True
B) False
JUSTIFICATIVA:
O scrum diz que no final da sprint a equipe de desenvolvimento vai entregar incrementos de
funcionalidades potencialmente utilizáveis em conformidade com a definição de "pronto" acordada
entre a equipe scrum e as partes interessadas. Não é necessário que esses incrementos sejam
enviados ou liberados para a produção ou enviados para o cliente. A decisão de liberar para a
produção é do product owner.
50) The length of a Sprint should be: [Código de referência: 4096]
A) Short enough to keep the business risk acceptable to the Product Owner.
B) Short enough to be able to synchronize the development work with other business events.
C) No more than one month.
D) All of these answers are correct.
JUSTIFICATIVA:
Todas estas alternativas são considerações apropriadas para determinar a duração da Sprint.
51) Scrum does not have a role called “Project Manager.” [Código de referência: 4097]
A) True
B) False
JUSTIFICATIVA:
Dentro do framework scrum não existe nenhum papel chamado de "gerente de projeto". Um dos
conceitos-chave do scrum é que a equipe de desenvolvimento é auto-organizada e autogerida para
alcançar as metas do projeto que entregam incrementos de funcionalidade no final de cada sprint.
Tenha em mente que o scrum master não irá gerenciar a equipe de desenvolvimento em relação a
este caminho. Parte do trabalho que fazia um típico gerente de projetos no modelo tradicional passa
agora a ser assumido pelo product owner.
52) Who has the last say on the order of the Product Backlog? [Código de referência: 4098]
A) The CEO
C) The stakeholders
E) The Scrum Master
JUSTIFICATIVA:
ordenação. O product owner pode fazer todo o trabalho de gerenciamento do backlog do produto ou
pode delegar para a equipe de desenvolvimento. No entanto, o product owner continua sendo o
responsável pelo trabalho. Então, a última palavra na ordenação dos itens sempre será dele.
A) Safer items at the top to riskier items at the bottom

B) Least valuable items at the top to most valuable at the bottom
C) Small items at the top to large items at the bottom
D) Items are randomly arranged
E) Whatever is deemed most appropriate by the Product Owner
JUSTIFICATIVA:
O product owner é a única autoridade sobre o backlog do produto. Seu papel é o de otimizar o
retorno sobre o investimento (ROI) e o custo total de propriedade (TCO) do trabalho que a equipe de
desenvolvimento faz. Por isso, ele vai organizar os itens no backlog do produto respeitando os
objetivos de valor para o negócio e levando em conta os itens de maior risco que poderiam atrapalhar
o projeto ou drasticamente impactar o ROI.
54) What are two good ways for the Development Team to make non-functional requirements
visible? [Código de referência: 4100]
A) Add them to the definition of "Done" so the work is taken care of every Sprint.
B) Put them on a separate list on the Scrum board, available for all to see.
C) Add them to the Product Backlog and keep the Product Owner posted on the expected effort.
D) Run the integration and regression tests before the end of the Sprint, and capture the open
work for the Sprint Backlog of the next Sprint.
JUSTIFICATIVA:
Desempenho, assim como segurança, escalabilidade e manutenção, são requisitos não funcionais.
Normalmente os requisitos não funcionais são adicionados à definição de "Pronto" porque se aplicam
a todos os requisitos funcionais.
Para alguns requisitos não funcionais, como o desempenho, é possível criar itens não técnicos e
independentes no Backlog do Produto. Isto é feito geralmente quando se fazem melhorias nas
funcionalidades já prontas.
55) Which statement best describes a Product Owner’s responsibility? [Código de referência:
4101]
A) Managing the project and ensuring that the work meets the commitments to the stakeholders
B) Optimizing the value of the work the Development Team does
C) Keeping stakeholders at bay
D) Directing the Development Team
JUSTIFICATIVA:
Ao priorizar os itens do backlog do produto, o product owner otimizará o retorno sobre o investimento
(ROI) e custo total de propriedade (TCO) do trabalho que a equipe de desenvolvimento faz.
Gerenciar o projeto não seria a principal responsabilidade do product owner, apesar de ele assumir
parte deste gerenciamento pois a equipe de desenvolvimento é autogerenciável e também tem
parte deste gerenciamento, pois a equipe de desenvolvimento é autogerenciável e também tem
responsabilidade neste gerenciamento, assim como o scrum master.
56) Who is on the Scrum Team? [Código de referência: 4102]
A) The Scrum Master

D) The Project Manager
E) None of the above
JUSTIFICATIVA:
O scrum master, o product owner e a equipe de desenvolvimento formam a equipe scrum.
57) Which of the below are roles on a Scrum Team? (Choose 3 answers) [Código de referência:
4103]
A) Product Owner
B) Scrum Master
C) Customers
D) Users
E) Development team
JUSTIFICATIVA:
Clientes e usuários estão envolvidos no projeto, mas eles não são considerados parte da equipe
scrum. O product owner vai representá-los como membro da equipe scrum. Portanto, todos os outros
são papéis que formam a equipe scrum.
58) A Scrum Master is keeping a list of open impediments, but it is growing and he/she has been
able to resolve only a small portion of them. Which three techniques would be most helpful in this
situation? [Código de referência: 4104]
A) Arrange a triage meeting with all other project managers

B) Alert management to the impediments and their impact
C) Consult with the Development Team
D) Tell the Product Owner that scrum isn’t working
E) Prioritize the list and work on them in order
F) Discuss the absence of management support with the Development Team
JUSTIFICATIVA:
A transparência é um dos conceitos básicos do scrum. Alertar a gerência sobre os impedimentos e
seu impacto pode ajudar a determinar uma solução possível e a agir antes que seja tarde demais. É
importante considerar que uma equipe de desenvolvimento não opera do vácuo: no departamento em
que ela atua pode existir um gerente funcional e muitos impedimentos podem estar relacionados a
ele, como por exemplo, liberar equipamentos para a equipe trabalhar.
Consultar a equipe de desenvolvimento se encaixa no conceito de inspeção e adaptação. Conversar

com a equipe de desenvolvimento sobre impedimentos atuais pode levar à descoberta de uma causa
com a equipe de desenvolvimento sobre impedimentos atuais pode levar à descoberta de uma causa
raiz, se existir.
Priorizar a lista de impedimentos pode ser uma boa estratégia para tentar resolvê-los com base em
seu impacto ao longo do projeto. Manter uma lista transparente de prioridades de impedimentos para
a equipe de desenvolvimento e outras entidades envolvidas pode ajudar a resolvê-los o mais rápido
possível.
59) The reason the Scrum Master is at the Daily Scrum is: [Código de referência: 4105]
A) To write down any changes to the Sprint Backlog, including adding new items, and tracking
progress on the burndown
B) To make sure everyone answers the three questions in order of seniority
C) He or she does not have to be there; he or she only has to ensure the Development Team has
a Daily Scrum
D) So he or she knows what to report to management
JUSTIFICATIVA:
A presença do scrum master nesta reunião não é obrigatória. O scrum diário é mantido e gerido pela
equipe de desenvolvimento. O papel do scrum master é certificar-se de que o scrum diário acontece
como todos os outros eventos do scrum. O scrum master pode estar no scrum diário e em muitas
situações é recomendado que ele esteja, mas isto não é obrigatório.
60) Scrum Master is a “management” position. [Código de referência: 4106]
A) True
B) False
JUSTIFICATIVA:
Esta é uma das questões mais discutidas. O scrum master é um líder-servo e como parte da definição
de líder-servo ele é um gerente que está em uma posição de gerenciamento. O papel do scrum
master é o de gerir o processo de scrum. O scrum master nunca gerencia a equipe de
desenvolvimento que é, por definição, uma equipe autogerenciada. O scrum master precisa estar em
uma posição de gestão porque ele precisa de poder e influência para remover os impedimentos.
61) Which statement best describes the Sprint Review? [Código de referência: 4107]
A) It is when the Scrum Team and stakeholders inspect the outcome of the Sprint and figure out
what to do in the upcoming Sprint
B) It is a demo at the end of the Sprint for everyone in the organization to provide feedback on the
work done
C) It is a review of the team’s activities during the Sprint
D) It is used to congratulate the sevelopment team if it did what it committed to doing, or to punish
the Development Team if it failed to meet its commitments
JUSTIFICATIVA:
Durante a reunião de revisão da sprint, a equipe scrum e os interessados inspecionam o resultado da
sprint em termos de incrementos de funcionalidades e identificam o que fazer na próxima sprint com a
ajuda do product owner e com base no feedback dos stakeholders.
As outras opções estão erradas porque a revisão da sprint não se limita a ser uma "demo". Com
certeza alguns dos incrementos entregues no final do sprint serão demonstrados pela equipe de
desenvolvimento, mas isso é apenas parte da meta da reunião de revisão da sprint.
Durante a revisão da sprint, as atividades da equipe da reunião não serão revisadas: o que é
analisado são os resultados da sprint em termos de incrementos de funcionalidade.
Nenhuma congratulação ou punição acontece na reunião de revisão da sprint.
62) The maximum length of the Sprint Review (its time-box) is: [Código de referência: 4108]
A) 1 day
B) 4 hours for a monthly Sprint; proportionally less for shorter Sprints
C) 2 hours
D) As long as needed
JUSTIFICATIVA:
O tempo máximo correto para uma revisão de sprint para uma sprint mensal é de 4 horas. Se a
duração da sprint selecionada é menos de um mês, então uma reunião mais curta para revisão da
sprint pode ser realizada.
63) Who is required to attend the Daily Scrum? [Código de referência: 4109]
A) The Development Team.

B) The Development Team and Product Owner.
C) The Scrum Team.
D) The Development Team and Scrum Master.
E) The Scrum Master and Product Owner.
JUSTIFICATIVA:
Apenas as pessoas que fazem o trabalho descrita no Backlog da Sprint precisam participar da
Reunião Diária. Nada impede que qualquer compareça nessa reunião como ouvinte, afinal o Scrum
prega a transparência. Entretando, somente membros da Equipe de Desenvolvendo participam
ativamente.
64) Why is the Daily Scrum held at the same time and same place? [Código de referência: 4110]
A) Rooms are hard to book and this lets it be booked in advance

B) The consistency reduces complexity and overhead
C) The place can be named
D) The Product Owner demands it
JUSTIFICATIVA:
Ter o scrum diário realizado no mesmo horário e no mesmo local elimina decisões e coordenação o
Ter o scrum diário realizado no mesmo horário e no mesmo local elimina decisões e coordenação, o
que também remove a complexidade e a sobrecarga deste evento, consequentemente melhorando a
experiência de desenvolvimento e sincronização da equipe.
Mudar constantemente a data e o horário do scrum diário pode induzir frustração nas pessoas,
impedindo-as de organizar de forma eficaz seu tempo e suas atividades.
65) Which statement best describes Scrum? [Código de referência: 4111]
A) A cookbook that defines best practices for software development

B) A defined and predictive process that conforms to the principles of scientific management
C) A complete methodology that defines how to develop software
D) A framework within which complex products in complex environments are developed
JUSTIFICATIVA:
O objetivo final do scrum é ser uma estrutura (framework) dentro da qual pessoas podem tratar e
resolver problemas complexos, enquanto produtiva e criativamente entregam produtos com o mais
alto valor possível.
66) Which of the following is NOT a time-box in Scrum? (choose 4 answers) [Código de
referência: 4112]
A) Release retrospective
B) Release testing
C) Sprint retrospective
D) Sprint planning meeting
E) Sprint 0
F) Sprint testing
G) Daily scrum
JUSTIFICATIVA:
Retrospectiva de liberação (release retrospective), teste de liberação (release testing), sprint 0 e
teste de sprint (sprint testing) não são eventos oficiais descritos no scrum como tendo limites de
tempo. Isto não significa que estes eventos não possam existir, mas que eles não são padronizados
em relação à duração no scrum guide.
Não existe a definição de sprint 0 no scrum guide: toda sprint no scrum gera incremento de software
funcional. Há algumas empresas que usam a primeira sprint com o intuito de fazer planejamento e
definições de infraestrutura e arquitetura para as próximas sprints, e isto é conhecido no mercado
como sprint 0. Isto existe na prática, mas não é definido no scrum guide.
67) How is management external to the Scrum Team involved in the Daily Scrum? [Código de
referência: 4113]
A) Management gives an update at the start of each Daily Scrum

B) The Product Owner represents their opinions
C) The Development Team self-manages and is the only management required at the Daily Scrum
C) e e e op e t ea se a ages a d s t e o y a age e t equ ed at t e a y Sc u
D) The Scrum Master speaks on their behalf
JUSTIFICATIVA:
O scrum master aplica a regra de que apenas os membros da equipe de desenvolvimento devem
participar do scrum diário. O scrum diário não é uma reunião de status: é apenas para as pessoas
que transformam os itens do backlog do produto em um incremento.
Não há necessidade de qualquer gerência externa na reunião diária. O trabalho que terá de ser feito
e como será feito é algo que diz respeito à equipe de desenvolvimento. E se houver qualquer
problema na sprint que impeça que o seu objetivo seja alcançado, isso irá aparecer no scrum diário e
deve ser relatado imediatamente após a reunião ao product owner. Assim, esta reunião é apenas
para a equipe de desenvolvimento, mas pode levar a insights que são relevantes para a gestão
externa.
68) Which answer best describes the topics covered in the Sprint Planning meeting? [Código de
referência: 4114]
A) What to do and who will do it

B) What went wrong in the last Sprint and what to do differently this Sprint
C) Who is on the team and what team member roles will be
D) What to do and how to do it
E) How conditions have changed and how the Product Backlog should evolve
JUSTIFICATIVA:
A reunião de planejamento da sprint consiste em duas partes, cada uma tendo limite de metade do
tempo da duração da reunião. As duas partes respondem às seguintes questões, respectivamente:
1) O que será entregue como resultado do incremento da próxima sprint?
2) Como o trabalho necessário para entregar o incremento será realizado?
69) When multiple teams are working together, each team should maintain a separate Product
Backlog. [Código de referência: 4115]
A) True
B) False
JUSTIFICATIVA:
Se a empresa tiver 20 desenvolvedores trabalhando no mesmo produto, por exemplo, e montar várias
equipes scrum que trabalham no mesmo backlog do produto, elas não podem perder a integração.
Para cada produto deve existir um único backlog de produto, independente da quantidade de equipes
que serão usadas no projeto. Qualquer outra configuração fará com que a equipe de
desenvolvimento tenha dificuldade em determinar em que ela irá trabalhar.
70) When many Development Teams are working on a single product, what best describes the
definition of "Done?" [Código de referência: 4116]
A) Each Development Team defines and uses its own; the various differences are discussed and
reconciled during the stabilization phase
g p
B) All Development Teams must have a definition of "Done" that when their work integrates results
in a definition of "Done" that is potentially releasable
C) Each Development Team uses its own but must make it clear to all other teams if there are
differences
D) It depends
JUSTIFICATIVA:
O Scrum requer que um Incremento seja liberável. Este é um incremento de produto. Quando muitos
times estão trabalhando em um único produto é esperado que eles entreguem um incremento
integrado e liberável. Portanto, é ideal que eles escrevam mutuamente uma definição de "pronto".
71) Sprint burndown charts are an efficient tracking tool because they show: [Código de
referência: 4117]
A) How many Product Backlog items remain

B) An estimate of the total work remaining for the Sprint.
C) How many hours have been worked by each Development Team member
D) How much effort has gone into a Sprint
JUSTIFICATIVA:
O gráfico burndown da sprint sempre apresenta os valores restantes de trabalho da sprint.
72) Which three purposes does the definition of “Done” serve? (Choose 3 answers.)
A) Create a shared understanding of when work is complete.

B) Guide the Development Team on how many Product Backlog items to select for the Sprint.
C) Increase transparency.
D) Describe the work that must be done before the Sprint is allowed to end.
E) Describe the purpose, objective, and time-box of each Scrum event.
JUSTIFICATIVA:
Quando o item do Backlog do Produto ou um incremento é descrito como “Pronto”, todos
devem entender o que o “Pronto” significa. Embora, isso varie significativamente de um extremo ao
outro para cada Time Scrum, os integrantes devem ter um entendimento compartilhado do que
significa o trabalho estar completo, assegurando a transparência. Esta é a “Definição de Pronto” para
o Time Scrum e é usado para assegurar quando o trabalho esta completado no incremento do
produto.
Esta definição não descreve todo o trabalho que precisa ser feito antes data Sprint terminar. Este
trabalho está contido nas histórias de usuário selecionadas, além de estar na definição de pronto. Por
isso, a opção D não é adequada como resposta.
73) What are the benefits to the Scrum Development Team of self-organization? (choose 3
answers) [Código de referência: 4119]
A) Management can blame people more easily

B) Increased commitment
)
C) Increased creativity
D) Increased feeling of accountability
JUSTIFICATIVA:
A auto-organização estimula a criatividade, o comprometimento e o sentimento de responsabilidade.
74) Who owns the Sprint Backlog? [Código de referência: 4120]

B) The Scrum Master
C) The Scrum Team
JUSTIFICATIVA:
O backlog da sprint é uma imagem em tempo real do trabalho que a equipe de desenvolvimento
planeja completar durante a Sprint, e pertence exclusivamente a ela.
75) A new developer has joined an existing Scrum Team. He/she is having continuing conflicts
with existing members and is making the environment hostile. If necessary, who is responsible for
removing the new team member, and why? [Código de referência: 4121]
A) The Development Team is responsible because it is a self-managing team, although it may

have to be advised by the Scrum Master
B) The manager to whom he/she reports is responsible because he/she has authority for hiring
and firing
C) The Scrum Master is responsible because he/she needs to remove impediments
D) The Product Owner is responsible because he/she controls the return on investment of the
work
JUSTIFICATIVA:
Pelo fato da equipe ser autogerenciada, a própria equipe pode chegar sozinha na conclusão que um
membro está atrapalhando e pedir para que este seja removido ou substituído na equipe. Somente a
equipe pode saber quem está atrapalhando e chegar a conclusão que remover determinada pessoa
será melhor para o desempenho da equipe. Entretanto, a equipe não tem autoridade suficiente para
a substituição/remoção do membro, neste caso isto vira um impedimento no qual o Scrum Master
precisará auxiliar a equipe. O Scrum Master pode conversar com o gerente de desenvolvimento para
realocar o membro que está criando conflito para outra equipe ou outro trabalho.
O Scrum Master não pode chegar a conclusão sozinho de remoção de um membro de equipe, porque
ele não faz a gestão de equipe. O Product Owner também não interfere na estrutura da equipe. O
gerente funcional não é descrito no Scrum Guide como um papel, embora ele possa existir nas
organizações e ser ele quem vai ajudar na remoção após a decisão da equipe.
76) What is the tactic a Scrum Master should use to divide a group of 100 people into multiple
Development Teams? [Código de referência: 4122]
A) Create teams based on their skills across multiple layers (such as database, UI, etc.).
B) A k h P d O i h l
B) Ask the Product Owner to assign the people to teams.
C) Ask the developers to divide themselves into teams.
JUSTIFICATIVA:
Separar equipes com base em camadas técnicas (uma para front-end, uma para banco de dados,
uma para back-end, etc.) não é uma boa opção porque estas equipes individualmente não
conseguem integrar um incremento de software potencialmente liberável para os usuários.
O dono do produto pode não ter competência técnica necessária para dividir as equipes. E isso vai
contra o conceito de auto-organização do scrum.
Deixar que os desenvolvedores se organizem em equipes é a melhor alternativa dentre as respostas

disponíveis.
77) The Scrum Master should not allow the Product Owner to go to the Sprint Planning meeting
without having already devised the Sprint Goal. [Código de referência: 4123]
A) True
B) False
JUSTIFICATIVA:
Após a equipe de desenvolvimento prever os itens de backlog do produto que irá entregar na sprint,
a equipe scrum determina a meta da sprint. A meta da sprint é um objetivo que será conhecido dentro
da sprint através da implementação do backlog do produto, fornecendo orientação da razão de a
equipe de desenvolvimento trabalhar no incremento. Portanto, a meta da sprint é definida DURANTE
a reunião de planejamento da sprint envolvendo a equipe de desenvolvimento e o product owner.
78) Scrum is a methodology that tells in detail how to build software incrementally. [Código de
referência: 4124]
A) True
B) False
JUSTIFICATIVA:
O scrum não é um processo ou uma técnica para construir produtos: é um framework dentro do qual
se podem empregar vários processos ou técnicas. Só o fato de citar metodologia já está errado, pois
toda metodologia tende a fornecer um passo-a-passo bem definido e não tem muita margem para
adaptação.
79) Which best describes the Product Backlog? [Código de referência: 4125]
A) It is baselined to follow change management processes

B) It provides just enough information to enable a Scrum Team to start the design phase of a
product
C) It contains all foreseeable tasks and requirements from which the Scrum Team can develop and
maintain a complete project plan
D) It is allowed to grow and change as more is learned about the product and its customers
JUSTIFICATIVA:
O product backlog é a lista-mestra de todas as funcionalidades desejadas para o produto. Quando
um projeto é iniciado, não há como identificar todas as tarefas ou necessidades. Normalmente
quando um projeto começa identificamos tudo que é óbvio - o que é quase sempre mais que
suficiente para uma primeira sprint. O product backlog muda na medida em que mais se aprende
sobre o produto e seus clientes. Por isto que a resposta correta é a "It is allowed to grow and change
as more is learned about the product and its customers".
A letra A é incorreta porque o backlog do produto não é um baseline de escopo. E também não existe
um processo de gerenciamento de mudanças no Scrum.
A letra B é incorreta porque não existe uma fase de design formalmente definida no Scrum. Isto
caracterizaria o upfron design (detalhamento antecipado), que é combatido pelos métodos ágeis.
A letra C é incorreta porque não existe tarefas dentro do backlog do produto. Tarefas são derivadas a
partir do backlog do produto e inseridas no backlog da sprint. Além disto não existe um "completo
plano de projeto" no scrum.
80) Which of the following is the Development Team not responsible for? [Código de referência:
4126]
A) Monitoring and optimizing the work required to meet the Sprint goal at least daily
B) Resolving internal conflicts
C) Selecting the Product Owner
D) Monitoring and increasing productivity
E) Planning how to meet a Sprint goal
JUSTIFICATIVA:
A equipe de desenvolvimento não tem autoridade para escolher o dono do produto. A gerência, o
patrocinador e o cliente podem ter influência na seleção do dono do produto.
Evite a pirataria
SOBRE NÓS
Blog
Quem somos
Fale conosco
O QUE OFERECEMOS
Cursos e-learning
Cursos ao vivo
ACESSO ALUNO
Termos de uso
Menu
Simulado

Respostas que você acertou:72(90%)


26:00
Fe e dback final:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80


1) The primary reason one might choose a four-week Sprint is when the work is too large for a
two-week Sprint and cannot be decomposed further. [Código de referência: 5194]
A) True
B) False
JUSTIFICATIVA:
O fato de que um trabalho é muito grande e não pode ser decomposto não é algo que possa ser
considerado como razão PRIMÁRIA para escolher sprints com duração de 4 semanas. Há outras
razões que podem ser mais plausíveis, como por exemplo:
- O projeto pode ser de longa duração e os stakeholders estão dispostos a aceitar o risco de 1 mês
para validação das entregas
- A equipe domina a tecnologia que vai ser empregada e não há alto risco
- A estrutura da equipe tende a não mudar com frequência
- A organização já tem um ritmo estabelecido para liberações que é de 1 mês, e mudar para 1 ou 2
semanas pode quebrar este ritmo
- Dependendo da natureza/complexidade do produto, em menos de 1 mês pode não ser possível
liberar um "produto" potencialmente utilizável
Geralmente a escolha da duração da sprint está muito atrelada ao nível de risco. O que não dá para
afirmar é que não poder quebrar o trabalho é sempre uma razão primária: por isso a afirmativa deve
ser considerada falsa.
2) During the Sprint, the Scrum Master's role is to:

A) Facilitate inspection and adaptation opportunities as requested or needed

B) Assign tasks within the Scrum Team
C) Ensure the Product Owner attends all scrum events
D) Escalate team conflicts to functional line managers
E) Remove impediments
F) Monitor the progress of the Development Team
JUSTIFICATIVA:
Lembre que o scrum master é um líder servo, apoia a equipe, ajuda a remover impedimentos e é um
defensor do scrum, observando se a equipe está seguindo suas regras. Desta forma, seria errado o
scrum master atribuir tarefas à equipe já que ela deve ser auto-organizada. O product owner não
precisa participar de todos os eventos. O scrum master procura ajudar a resolver alguns conflitos de
equipe e não simplesmente os escalar para a gerência funcional.
3) The Development Team should not be interrupted during the Sprint. The Sprint Goal should
remain intact. These are conditions that foster creativity, quality and productivity. Based on this, which
of the following is FALSE? [Código de referência: 5196]
A) As a decomposition of the selected Product Backlog Items, the Sprint Backlog changes and
may grow as the work emerges
B) The Sprint Backlog and its contents are fully formulated in the Sprint Planning meeting and do
not change during the Sprint
C) The Development Team may work with the Product Owner to remove or add work if it finds it
has more or less capacity than it expected
D) The Product Owner can help clarify or optimize the Sprint when asked by the Development
Team
JUSTIFICATIVA:
Atente ao enunciado desta questão: ela está perguntando qual das afirmativas é falsa. É falso afirmar
que que o conteúdo do backlog da sprint é completamente formulado na reunião de planejamento da
sprint. É falso, porque ao longo de uma sprint os itens que foram selecionados podem ser
decompostos em tarefas, nem tudo precisa ser descomposto e planejado na reunião da sprint. É
importante que na reunião de planejamento da sprint exista pelo menos um planejamento inicial para
o trabalho dos primeiros dias.
É verdadeiro afirmar que conforme é feito a decomposição dos itens selecionados o backlog da sprint
pode crescer (ele vai conter mais tarefas). É verdadeiro afirmar que o time de desenvolvimento pode
trabalhar com o dono do produto para remover ou adicionar mais itens caso falte ou sobre tempo. E
também é verdadeiro afinar que o dono do produto pode esclarecer a sprint (no sentido de tirar
dúvidas sobre os itens) quando o time de desenvolvimento solicitar ajuda.
4) The Product Owner remains distant. He/she has handed over the required Product Backlog for
the Sprint but is not collaborating with the Development Team during the Sprint. What are valuable
actions for a Scrum Master?
A) Coach the Product Owner in the values of scrum and incremental delivery
B) Bring up the problem in the Sprint Retrospective
C) Stop the Sprint, send the Product Owner to a course and restart
D) Nominate a proxy Product Owner
JUSTIFICATIVA:
O scrum master (SM) é responsável por garantir que o scrum seja entendido e aplicado. O scrum
master faz isso para garantir que a equipe adere à teoria, às práticas e às regras do scrum. Desta
forma, o SM pode ensinar o product owner a aderir às práticas do scrum. Como a retrospectiva da
sprint tem como propósito inspecionar como a última sprint foi em relação a pessoas, relações,
processos e ferramentas, pode-se aproveitar esta reunião para discutir sobre a ausência do product
owner e como corrigir isto.
5) How much of the Sprint Backlog must be defined during the Sprint Planning meeting? [Código
A) Enough so the Development Team can create its best forecast of what it can do, and to start
the first several days of the Sprint
B) Just enough tasks for the Scrum Master to be confident in the Development Team`s
understanding of the Sprint
C) All of the potential work: the Sprint Planning meeting isn`t over until 100% of the work is
identified and estimated
D) Just enough to understand design and architectural implications
JUSTIFICATIVA:
O scrum guide declara que na reunião de planejamento da sprint, trabalho suficiente é planejado pela
equipe de desenvolvimento de acordo com o que ela acredita que poderá fazer durante a próxima
sprint. Além disto, o guia estabelece que a equipe de desenvolvimento modifica o backlog da sprint ao
longo de toda a sprint de acordo com o andamento do trabalho. Então, nem tudo precisa ser
detalhado na reunião de planejamento da sprint.
A) It is a task list where every Development Team member has signed up for all the tasks that
he/she intends to do in the Sprint
B) It is a decomposition of Product Backlog items such that enough work is decomposed for at
least the first days of the Sprint
C) It must be ordered by the Product Owner
D) It is an exhaustive list of all tasks for the Sprint, and tasks must be estimated in hours
E) It is a list of the user stories estimated in story points, and a list of corresponding tasks that are
estimated in hours
JUSTIFICATIVA:
O backlog da sprint é um conjunto de itens do backlog do produto selecionados para a sprint,
juntamente com o plano de entrega do incremento do produto e o alcance do objetivo da sprint. O
backlog da sprint pode ser composto de tarefas que foram identificadas a partir dos itens do backlog
do produto que precisam ser desenvolvidos.
7) Which two behaviors demonstrate that a team is self-organizing? [Código de referência: 5200]
A) Development team members collaboratively select their own work during the Sprint
B) The Development Team creates their own Sprint Backlog, reflecting all work that is part of the
definition of "Done"
C) The Scrum Master is no longer needed
D) The Development Team members work within the boundaries of their functional description and
nicely hand off work from analyst to developer to tester to integration
E) The Development Team invites external people to the Sprint Planning to ask them how to turn
Product Backlog items into an Increment via a complete and detailed Sprint Backlog
JUSTIFICATIVA:
O backlog da sprint é altamente visível: é uma imagem em tempo real do trabalho que a equipe de
desenvolvimento planeja completar durante a sprint, e pertence exclusivamente a ela. Sendo assim, a
equipe deve ter capacidade de criar e gerenciar o backlog da sprint. E durante a sprint os membros
da equipe de desenvolvimento podem de forma colaborativa escolher em quais tarefas irão trabalhar.
8) The Sprint Goal is a result of Sprint Planning, as is the Sprint Backlog. [Código de referência:
5201]
A) True
B) False
JUSTIFICATIVA:
Ao final da Reunião de Planejamento da Sprint, espera-se ter uma meta de sprint estabelecida e um
backlog de sprint inicial.
9) The IT manager asks a Development Team for a status report describing the progress
throughout the Sprint. The Development Team asks the Scrum Master for advice. The Scrum Master
should: [Código de referência: 5202]
A) Ask the Product Owner to send the manager the report.

B) Tell the Development Team to figure it out themselves.
C) Talk to the IT manager and explain that progress in Scrum comes from inspecting an Increment
at the Sprint Review.
D) Create and deliver the report to the manager herself.
E) Tell the Development Team to fit the report into the Sprint Backlog.
JUSTIFICATIVA:
Se os radiadores de informação, como Quadro Kanban e Gráfico Burndown estivessem disponíveis, o
gerente de TI poderia obter o status da Sprint olhando diretamente neles.
Durante a Sprint Review, a equipe de desenvolvimento demonstra o Incremento e o dono do produto

apresenta as informações de desempenho.
10) Development team membership should change: [Código de referência: 5203]
A) Never, because it reduces productivity

B) As needed, while taking into account a short term reduction in productivity
C) Every Sprint to promote shared learning
D) As needed, with no special allowance for changes in productivity.
JUSTIFICATIVA:
O scrum guide não faz nenhuma proibição em relação a isto. Entretanto, sabemos que mudanças de
membros da equipe podem levar à redução de produtividade.
11) Who has the last say on the order of the Product Backlog? [Código de referência: 5204]

B) The CEO
C) The Scrum Master
E) The stakeholders
JUSTIFICATIVA:
ordenação. Portanto, a última palavra é a dele.
12) Which answer best describes the topics covered in Sprint Planning? [Código de referência:
5205]
A) Who is on the team and what team member roles will be

B) How conditions have changed and how the Product Backlog should evolve
C) What can be done and how to do it
D) What went wrong in the last Sprint and what to do differently in this Sprint
E) What to do and who will do it
JUSTIFICATIVA:
As duas partes da reunião de planejamento da sprint respondem às seguintes questões,
respectivamente:
- O que será entregue como resultado do incremento da próxima sprint?
- Como o trabalho necessário para entregar o incremento será realizado?
13) Which of the following is the Development Team NOT responsible for? [Código de referência:
5206]
A) Selecting the Product Owner

B) Planning how to meet a Sprint goal
C) Monitoring and increasing productivity
D) Monitoring and optimizing the work required to meet the Sprint goal at least daily
E) Resolving internal conflicts
JUSTIFICATIVA:
O product owner poder ser apontado pela equipe scrum, pelo cliente ou pela gerência sênior. Não
existe uma formalização no scrum guide sobre quem deve designar o product owner.
14) How do you know that a Development Team is cross-functional? [Código de referência: 5207]
A) There are no conflicts within the Development Team.
B) A few of the Development Team members pair program and do Test Driven Development.
C) Development Team has all the skills to create a releasable increment by the end of every
Sprint.
D) Every member of the Development Team is able to perform every task.
JUSTIFICATIVA:
O Scrum Guide declara que:
"Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias,
enquanto equipe, para criar o incremento do Produto.
Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades
especializadas e área de especialização, mas a responsabilidade pertence ao Time de
Desenvolvimento como um todo. "
Portanto, a opção C é melhor que a opção D. A opção D conflita que o que é afirmado no Scrum
guide.
15) What are some consequences if a Development Team does not have a consistent definition
of "Done" from Sprint to Sprint? [Código de referência: 5208]
A) The Development Team may not know how many Product Backlog items it can do in a Sprint
B) The Product Owner may not know what he/she is inspecting at the Sprint Review
C) The Product Owner may be unable to gauge the progress toward his/her goals
D) The Development Team may not know what work is entailed in completing selected Product
Backlog items
E) All of the above
JUSTIFICATIVA:
Quando um item do backlog do produto ou um incremento é descrito como “pronto”, todos devem
entender o que “pronto” significa. Embora isso varie significativamente de um extremo ao outro para
cada equipe scrum, os integrantes devem ter um entendimento
compartilhado do que significa o trabalho estar completo, assegurando a transparência.
Sem a definição de "pronto" a equipe de desenvolvimento não conseguirá prever o que entregará no
final da sprint, o product owner não saberá identificar o que ficou "pronto" na revisão da sprint e a
equipe de desenvolvimento não saberá identificar as atividades necessárias para completar os itens
do backlog do produto.
16) Which Scrum Value is affected by a lack of trust in the Scrum Team? (Choose one answer)
A) Focus
B) Commitment
C) Courage
D) Openness
E) Respect
F) All of the above
JUSTIFICATIVA:
Os 5 valores do Valores Scrum são: Foco, Abertura, Respeito, Compromisso e Coragem. É
necessário usar os cinco Valores Scrum para criar a confiança para todos.
Sua probabilidade de implementar o Scrum com sucesso no mundo real (onde todos nós vivemos e
respiramos) aumenta exponencialmente quando você (e a equipe e sua organização inteira)
realmente envolver suas cabeças em torno desses cinco Scrum Valores.
17) Who creates a Product Backlog Item's estimate? [Código de referência: 5210]
A) The Development Team after clarifying requirements with the Product Owner
B) The Product Owner with input from the Development Team
C) The Scrum Master
D) The most senior people in the organization, including architects and subject matter experts
E) The Development Team alone
JUSTIFICATIVA:
A equipe de desenvolvimento é responsável por todas as estimativas. O product owner deve
influenciar a equipe, ajudando no entendimento e nas decisões conflituosas - mas as pessoas que
irão realizar o trabalho fazem a estimativa final.
18) Why does a Development Team need a Sprint Goal? [Código de referência: 5211]
A) Sprint goals are not valuable because everything is known from the Product Backlog
B) The Development Team is more focused through a common yet specific goal
C) A Sprint goal ensures that all of the Product Backlog items selected for the Sprint are
implemented
D) A Sprint goal gives only purpose to Sprint 0
JUSTIFICATIVA:
Como parte do planejamento da sprint, a equipe deve decidir sobre metas da sprint - o que vai definir
o sucesso ou fracasso da sprint. O principal objetivo da meta da sprint é fornecer um foco em algo
além de completar todas as histórias de usuário/tarefas e criar um espaço dentro do qual a equipe irá
trabalhar.
19) As Scrum Teams mature, it is expected that the following decision is likely to be taken: [Código
A) The Sprint Retrospectives will grow to be longer than 4 hours

B) A Scrum Master is no longer needed since they are a mature team now
C) They will improve their definition of done to include more stringent criteria
D) Sprint Reviews will no longer be needed
E) There is no need for a time-boxed Sprint, since time-boxes are only for new Scrum Teams
JUSTIFICATIVA:
Com uma equipe scrum madura, é esperado que a sua definição de “pronto” seja expandida para
incluir critérios mais rigorosos de alta qualidade.
20) The CEO asks the Development Team to add a "very important" item to the current Sprint.
What should the Development Team do? [Código de referência: 5213]
A) Add the item to the current Sprint without any adjustments

B) Inform the Product Owner so he/she can work with the CEO
C) Add the item to the current Sprint and drop an item of equal size
D) Add the item to the next Sprint
JUSTIFICATIVA:
Os itens selecionados para a sprint foram considerados valiosos pelo product owner e estão
alinhados com a meta da sprint. Não devem ser feitas alterações que coloquem em risco a meta da
sprint e nenhuma mudança pode ser forçada à equipe de desenvolvimento (sprint backlog) e ao
product owner (product backlog).
21) For which is the Scrum Master responsible? [Código de referência: 5214]
A) The Scrum process being adopted and used properl

B) The meetings and the objectives that a Scrum Team set for itself
C) Keeping track of resource allocation
D) Managing the performance of the Scrum Team
JUSTIFICATIVA:
O scrum master (SM) é responsável por garantir que o scrum seja entendido e aplicado. Seu foco é
no uso do scrum e no apoio à equipe scrum. O SM garante que os eventos do scrum sejam realizados
- mas ele não é responsável pela realização deles, como por exemplo pela reunião diária. O SM não
gerencia alocação de recursos e nem o desempenho da equipe scrum.
22) Development Team members step up to own a Sprint Backlog item: [Código de referência:
5215]
A) Whenever a team member can accommodate more work

B) Never - all Sprint Backlog items are "owned" by the entire Development Team, even though
each one may be done by an individual Development Team member
C) During the Daily Scrum
D) At the Sprint Planning meeting
JUSTIFICATIVA:
Para o scrum, todos os membros da equipe de desenvolvimento são responsáveis por todas as
tarefas do backlog da sprint, ainda que cada tarefa possa ser feita individualmente por um membro.
Então, nunca um item do backlog da sprint será exclusividade de apenas um membro da equipe.
23) Who is responsible for registering the work estimates during a Sprint? [Código de referência:
5216]
A) The most junior member of the team

A) The most junior member of the team
B) The Scrum Master
JUSTIFICATIVA:
A equipe de desenvolvimento é responsável por todas as estimativas.
24) If burndown charts are used to visualize progress, what do they track? [Código de referência:
5217]
A) Accumulated business value delivered to the customer

B) Individual worker productivity
C) Accumulated cost
D) Work remaining across time
JUSTIFICATIVA:
O foco dos gráficos burndown é acompanhar o trabalho que falta no período, seja da sprint ou do
release.
25) During a Sprint, when is new work or further decomposition of work added to the Sprint
Backlog? [Código de referência: 5218]
A) When the Product Owner identifies a new work

B) As soon as possible after they are identified
C) During the Daily Scrum after the Development Team approves them
D) When the Scrum Master has time to enter them
JUSTIFICATIVA:
A equipe de desenvolvimento modifica o backlog da sprint ao longo de toda a sprint, e o backlog da
sprint vai surgindo durante a sprint. Sempre que um novo trabalho é necessário, a equipe de
desenvolvimento o adiciona ao backlog da sprint. Não é necessário esperar nenhum evento ocorrer
para isto.
26) What are two good ways for a Scrum Team to ensure that security concerns are satisfied?
A) Have the Scrum Team create Product Backlog items for each concern
B) Add a Sprint to specifically resolve all security concerns
C) Delegate the work to the concerned department
D) Postpone the work until a specialist can perform a security audit and create a list of security-
related Product Backlog items
E) Add security concerns to the definition of "Done"
JUSTIFICATIVA:
Considerando que as equipes de desenvolvimento são multifuncionais e possuem todas as
habilidades necessárias para criar o incremento do produto, as preocupações de segurança não
devem ser delegadas para alguém de fora da equipe.
Além disto, toda sprint deve gerar incremento/funcionalidade utilizável. Sendo assim, está fora de
cogitação ter uma sprint apenas para resolver questões de segurança. Neste caso, faz mais sentido a
opção de resposta que se refere a criar itens no backlog do produto para tratar este tipo questão.
A) Whatever is deemed most appropriate by the Product Owner

B) Items are randomly arranged
C) Small items at the top to large items at the bottom
D) Least valuable items at the top to most valuable at the bottom
E) Safer items at the top to riskier items at the bottom
JUSTIFICATIVA:
O product owner decide a ordem do product backlog que faz mais sentido para otimizar o valor do
trabalho que está sendo feito pela equipe de desenvolvimento.
28) The time-box for a Daily Scrum is? [Código de referência: 5221]
A) Two minutes per person.

B) The same time of day every day.
C) 15 minutes.
D) 4 hours.
E) 15 minutes for a 4 week sprint. For shorter Sprints it is usually shorter.
JUSTIFICATIVA:
No Scrum, em cada dia de um sprint, a equipe realiza uma reunião diária chamada "Daily Scrum". As
reuniões normalmente são realizadas no mesmo local e ao mesmo tempo todos os dias. Idealmente, a
reunião Daily Scrum é realizada no manhã, pois ajuda a definir o contexto para o próximo dia de
trabalho. Essas reuniões fixas em 15 minutos. Isso mantém a discussão ativa, mas relevante.
29) Self-organization works best when there are goals and boundaries. Select two requirements
from the Scrum framework that are key for a Scrum Master to teach teams to help them self-organize.
A) Maintaining and preferably increasing velocity

B) Having an even number of team members to be able to do pair programming
C) Time-boxing events to manage risks
D) Forming teams happens by the Product Owner selecting each member
E) Creating a releasable Increment by the end of each Sprint
JUSTIFICATIVA:
O scrum master facilita os eventos scrum conforme exigidos ou necessários em um espaço de tempo.
Criar incremento liberáveis (releseable) é um principio básico do Scrum para cada Sprint. Isto não
quer dizer que o incremento será liberado em produção sempre, mas ele tem que ser potencialmente
utilizável, preparado para ser utilizado. Cabe ao dono do produto dizer quando o incremento será
liberado.
O time-boxing é uma técnica de gerenciamento de riscos, que ajuda a lidar com incertezas dentro de
um certo tempo, evita que os eventos se estendam além do prazo, que se perca controle sobre as
entregas. O Scrum trata o tempo como uma das restrições mais importantes na gestão de um projeto.
Scrum envolve várias reuniões curtas (Sprint Planning, Daily Scrum, Sprint Review e Sprint
Retrospective). Se essas reuniões não são time-boxed, então há um alto risco de que essas reuniões
se tornem discussões gerais e consumam quantidades consideráveis de tempo e energia de todos os
participantes. E o Scrum Master tem que incentivar o time a cumprir os tempos fechados, para que o
time se auto-organize para fazer o melhor dentro de um tempo determinado.
30) The Product Owner must ship each Sprint increment... [Código de referência: 5223]
A) ... to make sure the Development Team is done every Sprint

B) ... without exception
C) ... when it makes sense
D) ... whenever the increment is free of defects
JUSTIFICATIVA:
Ao final da sprint um novo incremento deve estar “pronto”, o que significa que deve estar em
condição utilizável e atender à definição de “pronto” da equipe scrum - independente de o product
owner decidir liberá-lo realmente.
31) During the Daily Scrum, the Scrum Master's role is to: [Código de referência: 5224]
A) Facilitate discussions of the Development Team

B) Ensure that all three questions have been answered
C) Ensure that each team member has a chance to speak
D) Teach the Development Team to keep the Daily Scrum within the 15-minute time-box
E) All answers apply.
JUSTIFICATIVA:
Considere que a participação do scrum master na reunião diária não é obrigatória. De acordo com o
scrum guide, o scrum master assegura que a equipe de desenvolvimento faça a reunião - mas a
equipe é responsável pela sua condução. Desta forma, qualquer membro da equipe de
desenvolvimento pode facilitar as discussões na reunião. Além disto, há o princípio de equipe auto-
organizada. Outra coisa que o guia declara é que o scrum master deve ensinar a equipe de
desenvolvimento a manter a reunião diária dentro da time-box de 15 minutos.
32) What is the main reason for the Scrum Master to be at the Daily Scrum? [Código de
referência: 5225]
A) To make sure every team member answers the three questions in the right team member order
B) To write down any changes to the Sprint Backlog, including adding new items, and tracking
progress on the burndown
C) He or she does not have to be there; he or she only has to ensure the Development Team has
a Daily Scrum
D) To gather status and progress information to report to management
D) To gather status and progress information to report to management
JUSTIFICATIVA:
A participação do scrum master na reunião diária não é obrigatória. Esta é uma reunião para a equipe
de desenvolvimento. O scrum master apenas deve garantir que esta reunião seja realizada.
33) Which of the following are true about the length of the Sprint? (Choose 2 answers) [Código de
referência: 5226]
A) The length of the Sprint should be proportional to the work that is done in between Sprints
B) All Sprints must be 1 month or less
C) It is best to have Sprints of consistent length throughout a development effort
D) Sprint length is determined during Sprint Planning, and should hold the time it will take to code
the planned features in the upcoming Sprint, but does not include time for any testing
E) Sprint length is determined during Sprint Planning, and should be long enough to make sure
the Development Team can deliver what is to be accomplished in the upcoming Sprint
JUSTIFICATIVA:
Sprints são limitadas a um mês corrido. E é importante que a duração seja consistente ao longo do
projeto para se obter regularidade (ritmo de trabalho).
34) When does the next Sprint begin? [Código de referência: 5227]
A) When the Product Owner is ready

B) Immediately following the next Sprint Planning
C) Immediately after the conclusion of the previous Sprint
D) Next Monday
JUSTIFICATIVA:
35) A Scrum Master is introducing Scrum to a new Development Team. The Development Team
has decided that a retrospective is unnecessary. What action should the Scrum Master take? [Código
A) Comply with the decision of the self-organizing team

B) Begin facilitating productive, useful retrospectives
C) Consult with the Product Owner to see how he/she feels about the situation
D) Call a meeting between the Development Team and senior management
JUSTIFICATIVA:
O scrum master (SM) precisa saber o motivo pelo qual a equipe de desenvolvimento está
considerando esta reunião desnecessária. O SM precisa ensinar como realizar esta reunião e obter
benefícios com ela.
36) What is the purpose of a Scrum of Scrums? [Código de referência: 5229]
A) Align Product Backlogs of related products by bringing their Product Owners together
) g g p y g g g
B) Align plans for different Scrum Teams by bringing the Scrum Masters together every day
C) Share cross-team experiences of different Scrum Masters
D) Meet to report to stakeholders
E) Align plans of different Development Teams working on the same product
JUSTIFICATIVA:
A principal abordagem para trabalhar com equipes grandes no scrum é usando o conceito de "scrum
of scrums". Cada equipe scrum trabalha normalmente, mas cada uma também contribui com uma
pessoa, geralmente alguém com um conhecimento técnico maior, que deverá frequentar a reunião
scrum of scrums para coordenar o trabalho de múltiplas equipes scrum. O foco desta reunião é
alinhar planos e tratar de dependências entre as equipes que estão trabalhando no mesmo produto.
Esses encontros são análogos às reuniões diárias, mas não acontecem necessariamente todos os
dias. Fazer essa reunião duas ou três vezes por semana tende a ser suficiente na maioria das
organizações. Os scrum masters e os product owners não têm obrigatoriedade de participar desta
reunião.
37) Which two ways of creating Development Teams are consistent with Scrum´s values? [Código
A) Managers personally re-assign current subordinates to new teams

B) The chief Product Owner determines the new team structures and assignments
C) Bring all the developers together and let them self-organize into Development Teams
D) Existing teams propose how they would like to go about organizing into the new structure
E) Managers collaborate to assign individuals to specific teams
JUSTIFICATIVA:
Considerando que o scrum defende equipes de desenvolvimento auto-organizadas, o correto é deixar
que elas decidam como querem se organizar dentro de uma nova estrutura, envolvendo todos os
seus membros nesta auto-organização.
38) At the end of a Sprint a Product Backlog item worked on during the Sprint does not meet the
definition of "Done". What two things should happen with the undone Product Backlog item? (Choose
2 answers). [Código de referência: 5231]
A) Put it on the Product Backlog for the Product Owner to decide what to do with it.
B) If the stakeholders agree, the Product Owner can accept it and release it to the users.
C) Review the item, add the"Done" part of the estimate to the velocity and create a Story for the
remaining work.
D) Do not include the item in the Increment this Sprint.
JUSTIFICATIVA:
Os itens que não foram concluídos em um sprint devem ser devolvidos ao Backlog do produto para
re-priorização pelo Dono do Produto. Portanto, faz mais sentido também não incluir no incremento
que vai ser liberado para revisão ao final da sprint.
39) Which of the following two items are NOT topics of discussion within a Sprint Retrospective?
A) Definition of "Done"
B) Team relations
C) Functionality implemented as a result of the Sprint
D) Process improvements
E) Sprint Backlog for the next Sprint
JUSTIFICATIVA:
A retrospectiva da sprint é uma oportunidade para a equipe scrum inspecionar a si própria e criar um
plano para melhorias a serem aplicadas na próxima sprint. A inspeção de produto ocorre na revisão
da sprint. E o surgimento do backlog da sprint ocorre na reunião de planejamento da sprint.
40) Which two things does the Development Team NOT do during the first Sprint? [Código de
referência: 5233]
A) Develop a plan for the rest of the project

B) Deliver an increment of potentially shippable functionality
C) Develop and deliver at least one piece of functionality
D) Nail down the complete architecture and infrastructure
JUSTIFICATIVA:
Não é uma prática do scrum desenvolver um planejamento para o resto do projeto na primeira sprint.
Toda sprint precisa fazer e entregar algum incremento potencialmente utilizável, não importa o
tamanho deste incremento. Itens de arquitetura e infraestrutura podem ser construidos aos poucos
juntamente com as funcionalidades que serão desenvolvidas na sprint.
41) Who is responsible for tracking the remaining work of the Sprint? [Código de referência:
5234]

B) The Development Team in consultation with the Product Owner
D) The Scrum Master
E) The Product Owner
JUSTIFICATIVA:
A equipe se auto-organiza e se autogerencia durante os trabalhos da sprint.
42) What is the recommended size for a Development Team (within the Scrum Team)? [Código de
referência: 5547]
A) 7 plus or minus 2
B) 9
B) 9
C) Minimal 7
D) 3 to 9
JUSTIFICATIVA:
O tamanho ideal da equipe de desenvolvimento deve ser pequeno o suficiente para permanecer ágil
e grande o suficiente para completar o trabalho significativo. Menos de três membros na equipe de
desenvolvimento diminui a interação e resulta em ganhos de produtividade menores. Mais de nove
membros exige muita coordenação.
43) What is the timebox for a Daily Scrum? [Código de referência: 5548]
A) 4 hours
B) 15 minutes
C) Two minutes per person
D) The same time of day every day
E) 15 minutes for a 4 week Sprint; for shorter Sprints it is usually shorter
JUSTIFICATIVA:
Independente da duração da sprint, a reunião diária deve ter 15 minutos.
44) During a Sprint, a Development Team determines that it will not be able to finish the complete
forecast. Who should be present to review and adjust the Sprint work selected? [Código de referência:
5549]
A) The Product Owner and all stakeholders

B) The Product Owner and the Development Team
C) The Scrum Master, the project manager and the Development Team
JUSTIFICATIVA:
Como a meta da sprint pode ser impactada com a remoção de algum item do backlog da sprint, o
product owner precisa estar presente neste ajuste.
Infelizmente você não selecionou nenhuma opção de resposta para esta

questão abaixo. Note que nenhuma opção foi marcada (não há nenhum
botão de opção marcado). Quando não há nenhuma opção selecionada,
é considerada a questão como errada. A mesma regra se aplica no

resultado do exame oficial. Você está visualizando em verde apenas a
opção que deveria ser a correta, mas que você não selecionou.
45) The purpose of a Sprint is to produce a done increment of working product. [Código de
referência: 5550]
A) True
B) False
JUSTIFICATIVA:
O coração do scrum é a sprint, uma time-box de um mês ou menos durante a qual uma versão
incremental "pronta" potencialmente utilizável do produto é criada.
46) It is mandatory that the product increment be released to production at the end of each
Sprint. [Código de referência: 5551]
A) True
B) False
JUSTIFICATIVA:
O incremento de produto deve ser utilizável e potencialmente liberável no final de cada sprint, mas
isso não quer dizer que este incremento tenha que ser liberado em produção.
47) The maximum length of the Sprint Review (its timebox) is: [Código de referência: 5552]
A) 2 hours
B) 1 day
C) 4 hours and longer as needed
D) As long as needed
E) 4 hours for a monthly Sprint; for shorter Sprints it is usually shorter
JUSTIFICATIVA:
Esta é uma reunião de 4 horas de duração para uma sprint de um mês. Proporcionalmente um tempo
menor é alocado para sprints menores. Por exemplo, uma sprint de duas semanas tem reunião de
revisão de 2 horas.
48) The three pillars of empirical process control are: [Código de referência: 5553]
A) Respect for people; kaizen; eliminating waste

B) Inspection; transparency; adaptation
C) Planning; inspection; adaptation
D) Transparency; eliminating waste; kaizen
E) Planning; demonstration; retrospective
JUSTIFICATIVA:
O scrum se baseia na teoria de controle de processos empíricos, ou empirismo. O empirismo afirma
que o conhecimento vem da experiência e toma decisões com base no que é conhecido. Três pilares
sustentam qualquer implementação de controle de processos empíricos: transparência, inspeção e
adaptação.
49) Who has the final say on the order of the Product Backlog? [Código de referência: 5554]
A) The Scrum Master

A) The Scrum Master
D) The CEO
E) The stakeholders
JUSTIFICATIVA:
ordenação. Então, a última palavra é a dele.
50) During a Sprint Retrospective, for what is the Scrum Master responsible? [Código de
referência: 5555]
A) Prioritizing the resulting action items

B) Participating as a Scrum Team member and facilitating as requested or needed
C) Acting as a scribe to capture the Development Team´s answers
D) Summarizing and reporting the discussions to management
JUSTIFICATIVA:
A retrospectiva da sprint é uma oportunidade para a equipe scrum inspecionar a si própria e criar um
plano para melhorias a serem aplicadas na próxima sprint. O scrum master faz parte da equipe scrum.
51) If quality assurance work does not occur as part of the development work within a Sprint,
which benefits are lost?
(Choose 3 answers) [Código de referência: 5556]
A) The increment is probably not releasable

B) Future Sprints will probably be interrupted with bugs that are being found
C) The indication of progress on the Product Backlog is not transparent
D) The project manager cannot effectively update the plan
JUSTIFICATIVA:
Como não existe o papel de gerente de projeto no scrum, a única opção falsa é a D.
52) A Scrum Master is working with a Development Team that has members in different physical
locations. The Development Team meets in a variety of meeting rooms and has much to do logistically
(for example, set up conference calls) before the Daily Scrum. What action should the Scrum Master
take? [Código de referência: 5557]
A) Inform management and ask them to solve it

B) Allow the Development Team to self-manage and determine for itself what to do
C) Ask the Development Team members to alternate who is responsible for meeting setup
D) Set up the meeting and tell the Development Team that is how it will be done
JUSTIFICATIVA:
Primeiro a equipe tem que ter capacidade de ser auto-organizar. O scrum master precisa ensinar a
equipe a ser auto-organizada e facilitar os eventos do scrum O Scrum Master não pode interferir nos
equipe a ser auto organizada e facilitar os eventos do scrum. O Scrum Master não pode interferir nos
horários, locais da reunião diária. Se a equipe pedir ajuda, ai sim o Scrum Master entra em ação para
resolver os impedimentos. É sempre a equipe que tem que pedir ajuda ao Scrum Master, ele é um
lider-servo, e não um líder autoritário.
53) Who is responsible for clearly expressing Product Backlog items? [Código de referência:
5558]

B) The Scrum Master
C) The business analyst who represents the Product Owner in the Development Team
D) The stakeholders
JUSTIFICATIVA:
Cabe ao product owner expressar claramente os itens do backlog do produto.
54) Which of the following best describes an increment of working software? [Código de
referência: 5559]
A) UML diagrams that describe how to deliver functionality in future iterations

B) A decomposition of all Product Backlog items into tasks for future Sprint Backlog lists
C) Additional features in a useable state that complement those delivered in previous iterations
D) A new user interface design for functionality delivered in previous iterations
E) An automated test suite to verify functionality delivered in previous iterations
JUSTIFICATIVA:
Incremento utilizável é alguma funcionalidade que o usuário possa usar. Das opções disponíveis,
somente funcionalidades adicionais em um estado utilizável seria compatível com esta definição.
55) Items on the Product Backlog tend to be: [Código de referência: 5560]
A) The same size as the items in the Sprint Backlog

B) It depends
C) Larger than the items in the Sprint Backlog
D) Smaller than the items in the Sprint Backlog
JUSTIFICATIVA:
Os itens do backlog de produto são decompostos em atividades ou histórias de usuários para facilitar
o desenvolvimento deste destes itens durante a sprint. No backlog do produto, por exemplo, pode ser
colocado como item uma "tela de pagamento em um site de e-commerce". No backlog da sprint,
quando este item da tela for selecionado para o desenvolvimento na sprint, pode ser quebrado em
várias tarefas, como por exemplo:
- desenvolvimento de layout em html e css
- codificação para integração com cartão visa
- codificação para gerar boleto
- etc.
Então, um item o backlog do produto é muito maior que um item no backlog da sprint.
56) Which of the following are NOT time-boxed events in Scrum?
A) Sprint 0
B) Sprint testing
C) Release testing
D) Sprint Retrospective
E) Daily Scrum
F) Release Retrospective
G) Sprint Planning
JUSTIFICATIVA:
Estes não são eventos definidos pelo scrum guide. Eles podem existir, mas não são oficiais.
57) What are two responsibilities of testers in a Development Team? [Código de referência: 5562]
A) Everyone in the Development Team is responsible for quality

B) Finding bugs
C) Tracking quality metrics
D) Scrum has no "tester" role
E) Verifying the work of programmers
JUSTIFICATIVA:
O scrum não reconhece títulos para os integrantes da equipe de Desenvolvimento que não seja o de
desenvolvedor, independentemente do trabalho realizado pela pessoa. Não há exceções para esta
regra. Então, não existe o papel de testador e espera-se que todos na equipe de desenvolvimento
sejam responsáveis pela qualidade.
58) How often should Development Team membership change? [Código de referência: 5564]
A) As needed, while taking into account a short term reduction in productivity

B) Just as it would on any Development Team, with no special allowance for changes in
productivity
C) Never, because it reduces productivity
D) Every Sprint, to promote shared learning
JUSTIFICATIVA:
Não há restrição sobre mudanças de membros na equipe de desenvolvimento, mas estas podem
levar à redução da produtividade.
59) Who is responsible for engaging the stakeholders? [Código de referência: 5565]

B) The Team Manager
C) The Project Manager
D) The Business Analyst
D) The Business Analyst
E) The Product Owner
JUSTIFICATIVA:
O product owner trata do engajamento com as partes interessadas para entender a suas
necessidades, explicar a velocidade da equipe e estabelecer a meta de sprint para a próxima sprint.
60) Which of the following are true about the Product Owner role? (Choose 3 answers) [Código
A) Multiple people can share the Product Owner role on a Scrum Team
B) The Product Owner can be influenced by a committee
C) The Product Owner role can be played by a committee or a team of people
D) The Product Owner is accountable for ordering the Product Backlog
E) The Product Owner is one person
JUSTIFICATIVA:
O scrum guide estabelece que o product owner tem a responsabilidade na ordenação dos itens do
backlog do produto para melhor alcançar metas e missões. O product owner é uma pessoa e não um
comitê. O product owner pode representar o desejo de um comitê no backlog do produto, mas
aqueles que quiserem uma alteração nas prioridades dos itens do backlog devem convencer o
product owner.
61) When is implementation of a Product Backlog item considered complete? [Código de

referência: 5567]
A) When QA reports that it passes all acceptance criteria

B) At the end of the Sprint
C) When all work in the Sprint Backlog that is related to it is complete
D) The item has no work remaining that must still be done before it can be used by its end user
JUSTIFICATIVA:
Considere que não existe o papel de quality assurance (QA) no scrum, então a primeira opção é
inválida. Se não existe nenhum trabalho faltando para um item ser liberado e utilizado por um usuário
final, então pela definição este item está completo. Desta forma, a opção D é a melhor.
Não temos como estabelecer que o trabalho completado de uma determinada sprint é o suficiente
para estabelecer que um Item do backlog do produto está completo, pois este item poderia ser
desenvolvido em várias sprints. Desta forma, as opções B e C não são as melhores respostas.
62) Who determines how work is performed during the Sprint? [Código de referência: 5568]
A) Development team managers

B) Subject matter experts
D) Architects
E) The Scrum Master
JUSTIFICATIVA:
O scrum guide estabelece que tendo selecionado o trabalho da sprint, a equipe de desenvolvimento
decide como irá construir essas funcionalidades e transformá-las em um incremento “pronto”.
63) A Sprint Retrospective should be held: [Código de referência: 5569]
A) At the beginning of each Sprint

B) At the end of the last Sprint in a project or a release
C) Only when the Scrum Team determines it needs one
D) At the end of each Sprint
JUSTIFICATIVA:
A retrospectiva da sprint ocorre depois da revisão da sprint e antes da reunião de planejamento da
próxima sprint.
64) When can a Development Team cancel a Sprint? [Código de referência: 5570]
A) The Product Owner is absent too often

B) Functional expectations are not well understood
C) It can´t - only Product Owners can cancel Sprints
D) A technical dependency cannot be resolved
E) The forecast for the Sprint becomes un-achievable
F) Answers A or D
JUSTIFICATIVA:
O scrum guide estabelece que somente o product owner tem a autoridade para cancelar uma sprint,
embora ele possa fazer isso sob influência das partes interessadas, da equipe de desenvolvimento ou
do scrum master.
65) Every Scrum Team must have a Product Owner and a Scrum Master. [Código de referência:
5571]
A) False; a Product Owner can be replaced by a business analyst in the Development Team
B) True; each must be 100% dedicated to the Scrum Team
C) True; outcomes are affected by their participation and availability
D) False; a Scrum Master is only required when asked for by the Development Team
JUSTIFICATIVA:
É possível uma pessoa assumir o papel de scrum master ou de product owner e atender a várias
equipes scrum.
66) Which technique is the LEAST productive way for the Scrum Master to ensure that the
Development Team communicates effectively with the Product Owner? [Código de referência: 5572]
A) Teach the team to talk in terms of business needs and objectives

B) Teach the Product Owner about the technologies employed during the Sprints
C) Act as a go-between for them
D) Monitor communications between them
JUSTIFICATIVA:
É importante que a equipe tenha acesso direto ao product owner para esclarecer determinados itens
do backlog.
67) Which of the following is true about Scrum?

A) Scrum is like traditional processes but with self-organization to replace project managers
B) Scrum is based on empirical process control theory
C) Scrum is a methodology where you can pick and choose which parts of scrum you think will
work for your environment
D) Scrum is a framework for developing and maintaining complex products
E) Each component of scrum serves a specific purpose, and is essential to scrum´s success and
your usage of scrum to develop complex products
JUSTIFICATIVA:
Scrum é um framework para desenvolver e manter produtos complexos. O framework scrum consiste
em equipes de scrum associadas a papéis, eventos, artefatos e regras. Cada componente dentro do
framework serve a um propósito específico e é essencial
para o uso e o sucesso do scrum. O scrum é fundamentado nas teorias empíricas de controle de
processo, ou empirismo. O empirismo afirma que o conhecimento vem da experiência e de tomada de
decisões baseadas no que é conhecido.
68) The definition of “Done” is used to: (Choose 3 answers) [Código de referência: 5574]
A) Describe the work that must be done before the Sprint can end
B) Guide the Development Team on how many Product Backlog Items to do in a Sprint
C) Describe purpose, objective, and timebox of each Scrum event
D) Create a shared understanding of when work is complete
E) Increase transparency
JUSTIFICATIVA:
Quando o item do backlog do produto ou um incremento é descrito como “pronto”, todos devem
entender o que o “pronto” significa. Embora isso varie significativamente de um extremo ao outro para
cada equipe scrum, os integrantes devem ter um entendimento
compartilhado do que significa o trabalho estar completo, assegurando a transparência. A mesma
definição orienta a equipe de desenvolvimento no conhecimento de quantos itens
do backlog do produto podem ser selecionados durante a reunião de planejamento da sprint.
Considere que definição de pronto não descreve o trabalho que precisa ser feito antes da Sprint
termina. Ela descreve os requisitos que precisam ser atendidos para os itens escolhidos. São os itens
escolhidos do backlog do produto, formando o backlog da Sprint, que define o trabalho que precisa
ser feito.
69) Which of these may a Development Team deliver at the end of a Sprint? [Código de
referência: 5575]
A) Failing unit tests, to identify acceptance tests for the next Sprint
B) An increment of software with minor known bugs in it
C) A single document, if that is what the Scrum Master asked for
D) An increment of working software that is "Done"
JUSTIFICATIVA:
O propósito de cada sprint é entregar incrementos de funcionalidades potencialmente utilizáveis que
aderem à definição atual de “pronto” da equipe scrum. E a equipe de desenvolvimento entrega um
incremento de funcionalidade do produto a cada
sprint.
70) Which does a self-organizing Development Team choose? [Código de referência: 5576]
A) When to release, based on its progress

B) Product backlog ordering
C) Sprint length
D) How to best accomplish its work
E) Stakeholders for the Sprint Review
JUSTIFICATIVA:
As equipes de desenvolvimento são estruturadas e autorizadas pela organização para organizar e
gerenciar seu próprio trabalho.
71) An organization has decided to adopt Scrum, but management wants to change the
terminology to fit with terminology already used. What will likely happen if this is done? [Código de
referência: 5577]
A) Without a new vocabulary as a reminder of the change, very little change may actually happen
B) The organization may not understand what has changed with scrum and the benefits of scrum
may be lost
C) Management may feel less anxious
D) All answers may apply
JUSTIFICATIVA:
A adoção do scrum precisa ser integral para se ter agilidade, segundo a visão de seus criadores. Não
adotar o vocabulário do scrum pode fazer com que as pessoas não se lembrem corretamente o
propósito de cada componente do scrum, o que pode não gerar a mudança esperada.
Consequentemente os benefícios do scrum podem ser perdidos. Sobre a ansiedade da gerência, isto
varia em cada organização: há as mais aderentes a mudanças radicais, e usar a terminologia correta
não deixaria a gerência ansiosa em relação à adoção correta do scrum. Como esta pergunta não tem
a opção de marcar mais de uma opção de resposta, a melhor resposta é "All answers may apply".
72) What are three benefits of self-organization?

A) Increased self-accountability
B) Increased rule compliance
C) Increased commitment
D) Increased creativity
E) Increased predictability
JUSTIFICATIVA:
Esta questão se refere à característica de auto-organização da equipe de desenvolvimento. Dando a
possibilidade para que a equipe possa decidir como ele vai atuar, isto naturalmente aumenta o seu
comprometimento e a sua responsabilidade, dando chance para que a criatividade aflore.
73) Which phrase best describes a Product Owner? [Código de referência: 5579]
A) Value optimizer
B) Requirements engineer
C) Team manager
D) Go-between between Development Team and customers
JUSTIFICATIVA:
O product owner, ou dono do produto, é o responsável por maximizar o valor do produto e do trabalho
da equipe de desenvolvimento.
74) Why should the Product Owner be present at the Daily Scrum? [Código de referência: 5580]
A) To participate as a Scrum Team member
B) To represent the stakeholders´ point of view

C) He/She doesn´t need to be there
D) To hear about impediments in functionality
JUSTIFICATIVA:
O scrum master reforça a regra de que somente os integrantes da equipe de desenvolvimento
participem da reunião diária. A reunião diária não é uma reunião de status: é voltada para as pessoas
que transformam os itens do backlog do produto em um incremento. Não há impedimento do Product
Owner comparecer a esta reunião, mas apenas como ouvinte, afinal o Scrum prega a transparência.
A) Each task is estimated in hours

B) It is ordered by the Product Owner
C) It is a complete list of all work to be done in a Sprint.
D) Every item has a designated owner
E) It is the Development Team´s plan for the Sprint
JUSTIFICATIVA:
O backlog da sprint é um plano com detalhes suficientes para que as mudanças em progresso sejam
entendidas durante a reunião diária. A equipe de desenvolvimento modifica o backlog da sprint ao
longo de toda a sprint. Desta forma, a melhor resposta é ver o backlog da sprint no resultado da
reunião de planejamento como sendo um plano da equipe de desenvolvimento para a sprint em vez
de uma lista completa de todo o trabalho que precisa ser feito.
76) The Product Owner makes sure the team selects enough from the Product Backlog for a
Sprint to satisfy the stakeholders. [Código de referência: 5582]
A) True
B) False
JUSTIFICATIVA:
O Dono do Produto é responsável por priorizar os itens do backlog do produto de acordo com a
importância e interesse das partes interessadas (stakeholders). Entretanto, o Dono do Produto não
pode interferir na quantidade de itens selecionados pela equipe de desenvolvimento para serem
desenvolvidos na Sprint. A equipe de desenvolvimento selecionará os itens na ordem priorizada pelo
Dono Produto e a quantidade será determinada pela sua capacidade, velocidade já conhecida.
Somente a equipe de desenvolvimento tem condições de dizer o quanto ela é capaz de entregar, ela
é autogerenciada. Considerar também que o scrum guide estabelece que somente a equipe de
desenvolvimento pode avaliar o que pode ser completado ao longo da sprint.
77) What happens if the Development Team cannot complete its work by the end of a time-box?
A) Scrum should be abandoned

B) The time-box holds and the Development Team continuously learns what is actually possible to
do within a time-box
C) The time-box is adjusted permanently to reflect reality
D) The time-box is extended temporarily; lessons are taken to ensure it doesn´t happen again
JUSTIFICATIVA:
O ideal é que esta situação seja detectada durante a sprint e a equipe de desenvolvimento discuta
com o product owner sobre o que fazer. O melhor é manter o tempo definido para a sprint e remover
os itens que não possam ser completados na sprint.
78) An abnormal termination of a Sprint is called when? [Código de referência: 5584]
A) When the team feels that the work is too hard

B) When it is clear at the end of a Sprint that everything won´t be finished
C) When the Product Owner determines that it makes no sense to finish it
D) When sales has an important opportunity
JUSTIFICATIVA:
Somente o product owner tem a autoridade para cancelar a sprint, embora ele possa fazer isso sob
influência das partes interessadas, da equipe de desenvolvimento ou do scrum master.
79) Which of the following is true about the Scrum Master role?
A) The Scrum Master teaches the Development Team to keep the scrum meetings to their time-
box
B) At the Sprint Review, the Scrum Master identifies what has been "Done" and what has not been
"Done"
C) The Scrum Master assigns tasks to Development Team members when they need work
D) The Scrum Master is responsible for updating the Sprint burndown
E) The Scrum Master helps those outside the team interact with the Scrum Team
JUSTIFICATIVA:
O scrum master ajuda aqueles que estão fora da equipe scrum a entender quais das suas interações
com a equipe são úteis e quais não são. O scrum master facilita os eventos scrum conforme exigidos
ou necessários junto à equipe de desenvolvimento.
80) Drawing a trend line through a release burndown chart indicates... [Código de referência:
7904]
A) When the work remaining will likely be completed if nothing changes on Product Backlog or on
Development Team
B) When all Sprint Backlog work will be completed & ScrumTeam will be released for other work
C) When the project will be over if Product Owner removes work that is equal in effort to any new
work added
D) Cost of the project
Evite a pirataria
SOBRE NÓS
Blog
Quem somos
Fale conosco
O QUE OFERECEMOS
Cursos e-learning
Cursos ao vivo
ACESSO ALUNO
Termos de uso
Menu
Simulado

Tipo de questões:Múltipla escolha podendo mais de opção a ser marcada como correta.


36:48
Fe e dback final:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80


1) Select two ways that time-boxing promotes self-organization. [Código de referência: 5776]
A) Time-boxes do not allow enough time for stringent processes or meeting overhead
B) Time-boxes eliminate politics and bureaucracy
C) Time-boxes help everyone focus on the same problem at the same time
D) Teams can determine on their own how much overtime is acceptable for a time-box, generally
expressed as a percentage of the time-box
E) Time-boxes encourage the people who are closest to the problem to create the best possible
result in the time allotted, given the current context
JUSTIFICATIVA:
Os eventos no scrum são time-boxed para forçar os participantes a focarem no propósito do evento e
fazer o melhor possível dentro do tempo determinado. Neste sentido, este tipo de evento incentiva a
auto-organização da equipe de desenvolvimento para que esta tenha autonomia e desenvolva
criatividade dentro dos seus limites de atuação para identificar soluções.
2) The Product Owner is not collaborating with the Development Team during the Sprint. What are
two valuable actions for a Scrum Master to take? [Código de referência: 5777]
A) Coach the Product Owner in the values of scrum and incremental delivery
B) Stop the Sprint, send the Product Owner to a course and restart
C) Inform the Product Owner’s functional manager
D) Bring up the problem in the Sprint Retrospective

E) Nominate a proxy Product Owner
JUSTIFICATIVA:
O scrum master serve ao product owner de várias maneiras, incluindo ensinar como comunicar a
visão, o objetivo e os itens do backlog do produto para a equipe de desenvolvimento. Todos os
problemas (impedimentos) que ocorrem durante a sprint devem ser levados para a reunião de
retrospectiva para que toda a equipe tenha ciência dos problemas e possa resolvê-los ou sugerir
caminhos (ideias) para que sejam resolvidos.
3) What activities would a Product Owner typically undertake in the phase between the end of the
current Sprint and the start of the next Sprint? [Código de referência: 5778]
A) Update the project plan with stakeholders

B) Refine the Product Backlog
C) There are no such activities - the next Sprint starts immediately after the current Sprint
D) Work with the QA department on the increment of the current Sprint
JUSTIFICATIVA:
Uma nova sprint começa imediatamente após o término de sua antecessora. Então não há tempo
para nenhuma atividade entre estes dois eventos.
Atualizar as partes interessadas sobre o plano de projeto e refinar o backlog do produto é algo deve
ser feito continuamente e de forma iterativa. Publicar o release burndown em um local visível e
acessível e mantê-lo atualizado pode ser uma maneira de comunicar os planos de projeto para as
partes interessadas.
4) For the purpose of transparency, when does Scrum say a new increment of working software
must be available? [Código de referência: 5779]
A) Before the release Sprint

B) Every 3 Sprints
C) After the acceptance testing phase
D) When the Product Owner asks to create one
E) At the end of every Sprint
JUSTIFICATIVA:
O scrum guide estabelece que ao final da sprint um novo incremento deve estar “pronto”, o que
significa que deve estar na condição utilizável e atender à definição de “pronto” da equipe scrum. Ele
deve estar na condição utilizável independente de o product owner decidir por liberá-lo realmente ou
não.
5) Who must attend the Daily Scrum? [Código de referência: 5780]
A) The Scrum Master and the Product Owner

B) The Development Team and the Scrum Master
C) The Development Team and the Product Owner
D) The Scrum Team
E) The Development Team
JUSTIFICATIVA:
Apenas as pessoas que fazem o trabalho descrita no Backlog da Sprint precisam (must) participar da
desenvolvimento então eles terão de estar também na Reunião Diária Caso contrário o Scrum
Reunião Diária. Nada impede que qualquer outra parte compareça nessa reunião como ouvinte, afinal
o Scrum prega a transparência. Entretanto, somente membros da Equipe de Desenvolvendo
participam ativamente.
6) Cross-functional teams are optimized to work on one technical layer of a system only (e.g. GUI,
database, middle tier, interfaces). [Código de referência: 5781]
A) True
B) False
JUSTIFICATIVA:
Equipes de desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias para
criar o incremento do produto. Portanto, elas podem possuir conhecimento técnico para atuar em
qualquer camada do sistema.
7) What enhances the transparency of an Increment? [Código de referência: 5782]
A) Doing all work needed to meet the definition of “Done”

B) Keeping track of and estimating all undone work to be completed in a separate Sprint
C) Updating Sprint tasks properly in the electronic tracking tool
D) Reporting Sprint progress to the stakeholders daily
JUSTIFICATIVA:
O pilar transparência do Scrum significa que aspectos significativos do processo devem estar visíveis
aos responsáveis pelos resultados. Esta transparência requer aspectos definidos por um padrão
comum para que os observadores compartilharem um mesmo entendimento do que está sendo visto.
Por exemplo:
Uma linguagem comum referindo-se ao processo deve ser compartilhada por todos os
participantes; e,
Uma definição comum de “Pronto” deve ser compartilhada por aqueles que realizam o
trabalho e por aqueles que aceitam o resultado do trabalho.
Entre as opções disponíveis que mais estão alinhadas com práticas do Scrum é "Fazer todo o
trabalho necessário para atender a definição de Pronto".
8) When do Development Team members take ownership of a Sprint Backlog item? [Código de
referência: 5783]
A) During the Daily Scrum

B) Whenever a team member can accommodate more work
C) At the Sprint Planning meeting
D) Never. All Sprint Backlog Items are "owned" by the entire Development Team, even though
each one may be done by an individual Development Team member.
JUSTIFICATIVA:
Para o scrum todos os membros da equipe de desenvolvimento são responsáveis por todas as
Para o scrum, todos os membros da equipe de desenvolvimento são responsáveis por todas as
tarefas, ainda que cada tarefa possa ser feita individualmente por um membro.
9) Which two of the following are true about the Scrum Master role? [Código de referência: 5784]
A) The Scrum Master assigns tasks to Development Team members when they need work
B) The Scrum Master teaches the Development Team to keep the scrum meetings to their timebox
C) At the Sprint Review, the Scrum Master identifies what has been "Done" and what has not been
"Done"
D) The Scrum Master helps those outside the team interact with the Scrum Team
E) The Scrum Master is responsible for updating the Sprint burndown
JUSTIFICATIVA:
O scrum master ajuda aqueles que estão fora da equipe scrum a entender quais as suas interações
com a equipe e quais são úteis e quais não são. Além disto, ele ajuda a equipe no que diz respeito
aos eventos scrum conforme exigidos ou necessários.
10) When is a Product Backlog item considered complete? [Código de referência: 5785]
A) When all work in the Sprint Backlog related to the item is finished
B) When the item has no work remaining in order to be released
C) When QA reports that the item passes all acceptance criteria
D) At the end of the Sprint
JUSTIFICATIVA:
Não temos como estabelecer que o trabalho completado de uma determinada sprint é o suficiente
para estabelecer que um Item do backlog do produto está completo, pois este item poderia ser
desenvolvido em várias sprints. Desta forma, as opções A e D não são as melhores respostas.
Considere que não existe o papel de quality assurance (QA) no scrum, então a primeira opção é
inválida.
Se não existe nenhum trabalho faltando para um item ser liberado e usado por um usuário final, então
pela definição este item está completo. Desta forma, a opção B é a melhor resposta.
11) Which of the following is required by Scrum? [Código de referência: 5786]
A) Release Planning
B) Sprint Retrospective
C) Sprint Burndown Chart
D) Members must stand up at the Daily Scrum
E) All of the above
JUSTIFICATIVA:
A sprint retrospective é um evento obrigatório no scrum. Release planning e sprint burndown chart
são artefados que podem ser utilizados no desenvolvimento, mas não são obrigatórios no scrum. E
em nenhuma parte do guia é estabelecido que os membros precisam estar de pé (stand up) na
reunião diária: isto é boa prática mas não uma obrigação
reunião diária: isto é boa prática, mas não uma obrigação.
12) Multiple Scrum Teams working on the same project must have the same Sprint start date.
A) True
B) False
JUSTIFICATIVA:
O scrum não torna obrigatório que sprints sejam iniciadas na mesma data. Além disto, se existir um
único dono de produto atendendo a estas múltiplas equipes teríamos um problema de logística, pois
ele não conseguiria participar dos eventos ao mesmo tempo em cada equipe.
13) You have just been hired by a company new to Scrum. Your management has assigned you
to be the Scrum Master of six new Scrum Teams. These teams will build one product. Select two
conditions you should strive for in this scenario. [Código de referência: 5788]
A) There should be six Product Owners reporting to a chief Product Owner

B) There should be six Product Owners, one for each Scrum Team
C) There should be only one Product Owner
D) The product has one Product Backlog
E) Each Scrum Team should have a separate Product Backlog
JUSTIFICATIVA:
Sempre deve existir apenas um Backlog de Produto por produto, independente da quantidade de
equipes que vão trabalhar no desenvolvimento do mesmo produto. Partimos da premissa que sempre
vai haver um único Dono de Produto por Backlog de Produto, assim as decisões podem ser
centralizadas.
Por se tratar de 6 equipes novas no Scrum, no primeiro momento o Scrum Master deve defender a
proposta de ter um único Dono de Produto para todas as 6 equipes. Mais tarde, quando estas estas
equipes estiver maduras no uso do Scrum e notar que o um único Dono de Produto não será capaz
de atender todas das equipes, o Scrum Master poderá propor a criação de uma hierarquia de donos
de produto com um Dono de Produto chefe no topo.
14) What is the time-box for the Sprint Planning meeting? [Código de referência: 5789]
A) Whenever it is done
B) 4 hours for a monthly Sprint
C) Monthly
D) 8 hours for a monthly Sprint
JUSTIFICATIVA:
A reunião de planejamento da sprint tem uma time-box de oito horas para uma sprint de um mês de
duração. Para Sprints menores, este evento deve ser proporcionalmente menor. Por exemplo, uma
sprint de duas semanas terá uma reunião de planejamento de sprint de quatro horas.
15) Whi h t thi i t f S M t t d if th D l tT d 't

15) Which two things are appropriate for a Scrum Master to do if the Development Team doesn't
have the engineering tools and infrastructure to completely finish each selected Product Backlog item?
A) Refocus the current Sprint on establishing the Development Team´s infrastructure instead of
delivering an Increment
B) Declare the Development Team not ready for scrum
C) Encourage the Product Owner to accept partially done increments until the situation improve.
D) Coach the Development Team to improve its skills, tools and infrastructure over time and adjust
the definition of done accordingly
E) Have the Development Team establish a definition of done that is actually possible to achieve
given current circumstances
JUSTIFICATIVA:
Toda sprint deve entregar algum incremento potencialmente utilizável. Então o scrum master deve
orientar a equipe para que ela crie o que for possível com os recursos disponíveis dentro da definição
de "pronto". Os requisitos desta definição podem ser diminuídos nas sprints iniciais até que se
tenham todas as ferramentas e infraestrutura estabelecidas. Mais tarde esta definição de "pronto"
pode ser melhorada.
16) The Daily Scrum is an event that happens every day. What would be three key concerns if the
frequency were to be lowered to every two or three days? (select three answers) [Código de
referência: 5791]
A) Opportunities to inspect and adapt the Sprint Backlog are lost

B) Impediments are raised and resolved more slowly
C) The Sprint plan becomes inaccurate
D) The Product Owner cannot accurately report progress to the stakeholders
E) The Scrum Master loses the ability to update the Gantt chart properly
F) Too much work is spent updating the scrum board before the meeting
JUSTIFICATIVA:
Esta reunião é feita para inspecionar o trabalho desde a última reunião diária e prever o trabalho que
deverá ser feito antes da próxima reunião diária. Portanto, esta reunião serve para atualizar o plano
da Sprint e mantê-lo atualizado. Também durante esta reunião, os membros reportam quais são os
seus impedimentos. A equipe de desenvolvimento usa a reunião diária para avaliar o progresso em
direção à meta da sprint e para avaliar se o progresso tende a completar o trabalho do backlog da
Sprint.
Já a atualização do quadro scrum pode ocorrer durante toda a Sprint e não precisa da reunião diária
para isto. No Scrum o Scrum Master não gerencia atividades da equipe, não é esse seu papel. E o
Product Owner pode reportar o progresso para os stakeholder a partir das reuniões de revisão da
sprint ou os stakeholders podem acompanhar a evolução da sprint a partir do quadro scrum que é
compartilhado com toda a organização.
17) As the Sprint Planning meeting progresses, the Development Team sees that the workload is
greater than they can handle. Which two are valid actions? [Código de referência: 5792]
A) Recruit additional Development Team members before the work can begin
B) Remove or change selected Product Backlog items
) g g
D) The Development Team works overtime during this Sprint
E) The Development Team ensures that the Product Owner is aware, starts the Sprint, and
monitors progress
F) Add a specialist to the Development Team
JUSTIFICATIVA:
A equipe de desenvolvimento faz o seu melhor para puxar a quantidade certa de itens do backlog do
produto para a sprint, mas algumas vezes é preciso adicionar ou remover itens. O dono do produto
precisa ser consultado quando se quer remover itens do backlog da sprint.
18) When a Development Team is having trouble delivering a working increment because they
don't understand a functional requirement, what should they do? [Código de referência: 5793]
A) Add a specialist to the Development Team

B) Collaborate with the Product Owner to determine what is possible and acceptable
C) Partially complete the functionality, and discuss the remaining work at the Sprint Review
D) Defer the work to a more appropriate Sprint
JUSTIFICATIVA:
Cabe ao product owner garantir que a equipe de desenvolvimento entenda os itens do backlog do
produto no nível necessário. Neste caso, a equipe de desenvolvimento precisa conversar com o
product owner para entender melhor os requisitos e ver o que seria possível e aceitável para a sprint
atual.
19) The Product Owner determines how many Product Backlog items the Development Team
selects for a Sprint. [Código de referência: 5794]
A) True, accordingly to what was committed to the stakeholders

B) True, but only after confirmation by the resource manager that the team has enough capacity
C) True
D) False - the Scrum Master does that
E) False
F) False, capacity and commitment are the project manager´s responsibility
JUSTIFICATIVA:
O scrum guide estabelece que somente a equipe de desenvolvimento pode avaliar o que pode ser
completado ao longo de uma sprint. O product owner apresenta os itens ordenados no backlog do
produto na reunião de planejamento da Sprint, e a partir disto a equipe de desenvolvimento seleciona

o que ela pode entregar com base na sua capacidade.
20) Who should make sure everyone on the Development Team does his or her tasks for the

D) The Scrum Master
E) All of the above
JUSTIFICATIVA:
As equipes de desenvolvimento são estruturadas e autorizadas pela organização para organizar e
gerenciar seu próprio trabalho na sprint. Portanto, não há necessidade de outra pessoa ficar
gerenciando o trabalho da equipe de desenvolvimento durante a sprint.
21) Which of the following are roles on a Scrum Team? (Choose 3 answers) [Código de
referência: 5796]
A) Scrum master
B) Users
C) Development team
D) Product owner
E) Customers
JUSTIFICATIVA:
Usuários e clientes não tem papéis definidos no scrum. Eles existem, são partes interessadas e
interagem com o product owner, mas não têm papel definido no framework.
22) What is the accountability of the Product Owner during Sprint 0? [Código de referência: 5797]
A) There is no such thing as Sprint 0

B) Determine the composition of the Development Teams so they have the capacity to deliver the
completed forecast
C) Make the complete project plan to commit date, budget and scope to the stakeholders
D) Gathering, eliciting, and analyzing the requirements that will be inserted into the Product
Backlog
E) Make sure enough Product Backlog items are refined to fill the first 3 Sprints
JUSTIFICATIVA:
Sprint zero é um termo não-oficial utilizado no quando se inicia uma nova equipe ou projeto.
Habitualmente, algumas equipes scrum estabelecem uma sprint inicial para preparar o backlog de
produto, organizar o espaço de trabalho da equipe com máquinas para o desenvolvimento, configurar
as ferramentas de desenvolvimento e em alguns casos até aplicar algum treinamento - ou seja, pouco
trabalho produtivo e algo mais focado para fazer o setup do ambiente. Espera-se que depois da sprint
zero as equipes estejam prontas para meter a mão na massa. Isto não é descrito no scrum guide, mas
é comum acontecer na prática.
O que o scrum guide estabelece é que ao final de uma sprint um novo incremento deve estar
“pronto”, o que significa que deve estar na condição utilizável e atender à definição de “pronto” da
equipe scrum. Então toda Sprint (não importa o número dado a ela) deveria entregar algum
incremento de software na condição de utilizável. Sprint 0 com a intenção só de planejamento não é
oficial e não existe no guia.
23) A Product Owner wants advice from the Scrum Master about estimating work in Scrum. Which
of these is the guideline that a Scrum Master should give? [Código de referência: 5798]
A) Estimates are made by the Development Team

B) Estimates are made by the Product Owner, but are best checked with the Development Team
C) Product backlog items must be estimated in story points
D) Scrum forbids estimating
E) Estimates must be in relative units
JUSTIFICATIVA:
A equipe de desenvolvimento é responsável por todas as estimativas. O product owner deve
influenciar a equipe, ajudando no entendimento e nas decisões conflituosas. Mas as pessoas que irão
realizar o trabalho fazem a estimativa final.
24) Which three of the following are feedback loops in Scrum? (Choose 3 answers) [Código de
referência: 5799]
A) Sprint retrospective
B) Sprint Review
C) Refinement meeting
D) Daily scrum
E) Release planning
JUSTIFICATIVA:
Sprint retrospective, sprint review e daily scrum são eventos oficias do scrum que podem no final
gerar algum tipo de feedback, ou seja, alguma adaptação no processo ou no produto pode ser
gerada com base no que foi discutido nestes eventos. Release planning não é um evento oficial
estabelecido no framework. E as reuniões de refinamento não têm propósito de fornecer feedback
para adaptações no que está sendo desenvolvido ou foi desenvolvido: o foco é detalhar e preparar
os itens do backlog do produto para as próximas reuniões de planejamento de sprint.
25) How should the Development Team deal with non-functional requirements? [Código de
referência: 5800]
A) Handle them during the integration Sprint preceding the release Sprint
B) Make sure the release department understands these requirements, but it is not the
Development Team’s responsibility
C) Leave them for the lead developers on the team
D) Assure every Increment meets them
JUSTIFICATIVA:
Requisitos não-funcionais podem ser transformados em história de usuário, história de teste ou até
incluídos na definição de "pronto" quando estes requisitos se aplicam a todas às histórias de usuário.
A equipe de desenvolvimento precisa assegurar que cada incremento do produto atende a estes
requisitos. Então, eles são de responsabilidade da equipe de desenvolvimento e são considerados a
cada sprint.
) S
26) A Development Team pulled a Product Backlog item into the Sprint and worked on it. However,
it does not meet their definition of "done" by the end of the Sprint. What three things should happen
with the incomplete Product Backlog item? (select 3 answers) [Código de referência: 5801]
A) Review the item, add the"Done" part of the estimate to the velocity and create a story for the
remaining work
B) Re-estimate it and return it to the Product Backlog for the Product Owner to decide what to do
with it
C) Do not include the item in the increment in this Sprint
D) Do not show it in the Sprint Review
E) If the stakeholders agree, the Product Owner can accept it anyhow and release it to the users
JUSTIFICATIVA:
O incremento é a soma de todos os itens do backlog do produto completados durante a Sprint, além
das sprints anteriores. Portanto, o que não está completo não pode ser incluído no incremento da
sprint atual. Automaticamente, o item que ficou incompleto poderá ser completado na próxima sprint,
desde que de acordo com o produtct owner. Na sprint review o product owner precisa saber o que
ficou e o que não ficou pronto, mas o que não estiver pronto não precisa ser demonstrado.
27) When does the second Sprint start? [Código de referência: 5802]
A) Once the architectural changes for the second Sprint have been approved by the senior
architect
B) After the customer completes acceptance testing of the first Sprint
C) After the Product Backlog for the second Sprint has been selected
D) Immediately after the first Sprint
JUSTIFICATIVA:
28) A Scrum Team has been working on a product for nine Sprints. A new Product Owner comes
in, understanding he is accountable for the Product Backlog. However, he is unsure about his
responsibilities. Which two activities are part of the Product Owner role according to Scrum? [Código
A) Describing features as Use Cases

B) Providing the Development Team with detailed specifications
C) Ensuring that the most valuable functionality is produced first, at all times
D) Interacting with stakeholders
E) Creating detailed functional test cases
JUSTIFICATIVA:
Observe que a opção B não menciona detalhamento de item de backlog de produto e sim
especificações detalhadas. Especificações detalhadas podem se referir ao detalhamento que é feito
no backlog da sprint, poderia ser uma especificação técnica de como implementar um item do backlog
do produto. Então, não está claro o que poderia ser esta especificação.
Como a questão pede para selecionar somente duas respostas, então tem que selecionar as opções
que são claramente responsabilidades do dono do produto: priorizar o backlog do produto de acordo
com o valor (importância) e interação com as partes interessadas ficam sob responsabilidade do
product owner.
29) During a Sprint Retrospective, for what is the Product Owner responsible? [Código de
referência: 5804]
A) Summarizing and reporting the discussions to the stakeholders that he/she represents in the
Scrum Team
B) The Product Owner should not take part in Sprint Retrospectives
C) Participating as a Scrum Team member
D) Capturing requirements for the Product Backlog
JUSTIFICATIVA:
O scrum guide estabelece que a retrospectiva da sprint é uma oportunidade para a equipe scrum
inspecionar a si própria e criar um plano para melhorias a serem aplicadas na próxima sprint. O
product owner também pode participar desta reunião.
30) What is the recommended number of members for a Development Team? [Código de
referência: 5805]
A) At least 7
B) 3 to 9
C) 7 plus or minus 3
D) 9
JUSTIFICATIVA:
Menos de 3 integrantes na equipe de desenvolvimento diminui a interação e resulta em menor ganho
de produtividade. Equipes de desenvolvimento menores podem encontrar restrições de habilidades
durante a sprint, gerando uma equipe de desenvolvimento incapaz de entregar um incremento
potencialmente utilizável. Havendo mais de 9 integrantes é exigida muita coordenação.
31) What does it mean to say that an event has a time-box? [Código de referência: 5806]
A) The event must happen at a set time

B) The event must happen by a given time
C) The event can take no more than a maximum amount of time
D) The event must take at least a minimum amount of time
JUSTIFICATIVA:
O scrum usa eventos time-boxed, onde todo evento tem uma duração máxima. Isto garante que uma
quantidade adequada de tempo seja gasta no planejamento sem permitir perdas no processo de
planejamento.
32) The Product Owner must release each increment to production. [Código de referência: 5807]
A) Whenever the product is free of defects

B) To make sure the Development Team is done every Sprint
B) To make sure the Development Team is done every Sprint
C) When it makes sense
D) Without exception
JUSTIFICATIVA:
Ao final da sprint um novo incremento deve estar “pronto”, o que significa que deve estar na condição
utilizável e atender à definição de “pronto” da equipe scrum independente de o product owner decidir
por liberá-lo realmente ou não. O product owner libera o incremento em produção quando fizer
sentido para ele.
33) Which two ways of creating Development Teams are consistent with Scrum's values? [Código
A) Existing teams propose how they would like to go about organizing into the new structure
B) The chief Product Owner determines the new team structures and assignments
C) Managers collaborate to assign individuals to specific teams
D) Managers personally re-assign current subordinates to new teams
E) Bring all the developers together and let them self-organize into Development Teams
JUSTIFICATIVA:
As equipes de desenvolvimento são auto-organizadas. Ninguém (nem mesmo o scrum master) diz à
equipe de desenvolvimento como transformar o backlog do produto em incrementos de
funcionalidades potencialmente utilizáveis.
34) Which Scrum Values are exhibited by not building Product Backlog items that have low
business value? (Choose 3 answers) [Código de referência: 5809]
A) Economic Value Added

B) Earned Value
C) Focus
D) Respect
E) Courage
JUSTIFICATIVA:
OS VALORES DO SCRUM SAO:
Coragem: O Time Scrum precisa ter coragem para fazer a coisa certa e trabalhar em problemas
difíceis.
Foco: Todos focam no trabalho da Sprint e nos objetivos do Time Scrum.
Comprometimento: As pessoas se comprometem pessoalmente em alcançar os objetivos do Time

Scrum.
Respeito: Os membros do Time Scrum respeitam uns aos outros para serem pessoas capazes e
independentes.
O S S
Abertura: O Time Scrum e seus Stakeholders concordam em estarem abertos a todo o trabalho e aos
desafios com a execução dos trabalho
35) If two Scrum Teams are added to a project that previously had only one Scrum Team, what will
be the most likely impact on the first Scrum Team's productivity? [Código de referência: 5810]
A) Productivity will decrease

B) Productivity will increase
C) Productivity will stay the same
JUSTIFICATIVA:
A equipe original do scrum precisará aprender como trabalhar com a nova equipe, já que ambas as
equipes vão trabalhar com o mesmo backlog e com o mesmo PO. Esse esforço de coordenação extra
(comunicação, reuniões) afetará negativamente a capacidade da equipe original.
36) Which technique is the best way the Scrum Master can ensure that the Development Team
communicates effectively with the Product Owner? [Código de referência: 5811]
A) Teach the Development Team to talk in terms of business needs and objectives
B) Teach the Product Owner about the technologies employed during the Sprints
C) Monitor communications between them and facilitate direct collaboration
D) Act as a go-between for them
JUSTIFICATIVA:
Fique atento ao enunciado desta questão. No simulado 3 há uma questão parecida, com as mesmas
opções de resposta, mas lá pede-se a forma menos efetiva de garantir a comunicação da equipe. E
aqui neste simulado, a questão pede a forma mais efetiva.
O papel do scrum master (SM) é de facilitador para ambos os lados, tanto para a equipe de
desenvolvimento como para o product owner. A melhor opção que atende aos dois lados é monitorar
as comunicações e facilitar uma colaboração direta. Facilitando uma colaboração direta o SM não
precisará gastar tempo como intermediador (Act as a go-between for them).
37) What three factors are best considered when establishing the Sprint length? (select three
answers) [Código de referência: 5812]
A) The level of uncertainty over the technology to be used

B) The risk of being disconnected from the stakeholders
C) The need for a consistent Sprint cadence throughout the organization
D) The frequency at which team formation can be changed
E) The ability to go to market with a product release
JUSTIFICATIVA:
Uma sprint é um período de tempo fixo limitado a um mês corrido por conta dos riscos envolvidos.
Quanto menores forem as sprints, mais inspeções e adaptações poderão ser feitas. A equipe scrum
pode decidir qual é o melhor intervalo da sprint para o seu cenário, mas existem alguns fatores que
podem influenciar esta decisão - veja em
https://www.scrumalliance.org/community/articles/2014/november/selecting-sprint-length-for-your-
https://www.scrumalliance.org/community/articles/2014/november/selecting sprint length for your
project
O risco de desconexão com as expectativas da partes interessadas é um fator. As partes interessadas

podem ter expectativas em relação as liberações dos incrementos e isto precisa ser considerado.
Embora nem sempre vai ser liberado para o mercado o produto no final de uma Sprint, temos que
considerar que algumas vezes isto poderá ocorrer. Então, é necessário alinhar a duração da Sprint
com a habilidade de ir para o mercado com uma release do produto.
O nível de incerteza sobre a tecnologia que vai ser usada também é um fator a ser considerado, pois
quanto maior a duração da sprint, maior será o espaçamento entre as revisões da Sprint e da
Retrospectiva da Sprint, que são duas reuniões que ajudam na inspeção e adaptação.
38) In accordance with Scrum theory, how should a group of 100 people be divided into multiple
Development Teams?
A) Create a matrix of skills, seniority, and level of experience to assign people to teams.
B) Check with the allocation department to see who has worked together before and make these
the first teams.
C) Understanding the product, the product vision and the rules of the Scrum framework, the group
divides itself into teams.
D) It doesn’t really matter because you can rotate the teams every Sprint to spread knowledge
JUSTIFICATIVA:
O scrum master não tem poder para dizer quem vai fazer parte de cada equipe. Como sua
responsabilidade primária é garantir que o framework do scrum seja entendido e aplicado e o scrum
defende a ideia de equipes auto-organizadas, a opção C é a resposta mais coerente.
39) What are two guidelines a Scrum Master would use to divide a group of 100 people into
multiple Development Teams? [Código de referência: 5814]
A) Ask the Product Owner to assign the teams

B) Let the Development Teams decide
C) Create teams to work on different layers (such as database, UI, etc.)
D) Let the Product Owner decide
E) Ask the developers to divide themselves into teams
JUSTIFICATIVA:
Considerando que as equipes são auto-organizadas, poderia ser deixado para que os lideres do
grupo de 100 pessoas determinassem como eles gostariam de se organizar. O dono do produto não
tem influência sobre a organização da equipe e criar equipes para trabalhar em diferentes camadas é
fora de cogitação, pois o scrum prega que as equipes precisam ser multifuncionais - isto é, os
membros precisam ter todas as habilidades necessárias para gerar os incrementos do produto.
40) The Development Team informs the Scrum Master that the IT manager has asked for a status
report during the Sprint. The Scrum Master will: [Código de referência: 5815]
p g p [ g ]
A) Talk to the IT manager and explain that progress in scrum comes from inspecting an increment
at the Sprint Review
B) Create and deliver the report to the manager herself
C) Tell the Development Team to figure it out themselves
D) Tell the Development Team to fit the report into the Sprint Backlog
E) Ask the Product Owner to send the manager the report
JUSTIFICATIVA:
Criar relatórios de status durante a sprint é algo que não é defendido pelo scrum. O Scrum prega a
transparência e a visibilidade do que está sendo feito, e isso pode ser alcançado deixando o quadro
de tarefas (scrum board) e gráfico de burndown da sprint visíveis para todos.
Durante a reunião de revisão da Sprint, a equipe scrum e as partes interessadas colaboram sobre o
que foi feito na sprint. O gerente de TI é uma parte interessada e ele pode participar desta reunião se
desejar.
41) What are two things a group of 100 people should take into account when they are forming
into multiple Scrum Teams? [Código de referência: 5816]
A) The skills needed for the specific technical layer the team will develop (such as database or UI)
B) The mixture of senior and junior people on each team
C) The mixture of skills in each team to avoid dependencies on external experts
D) The effect of team size on the team’s ability to work together
JUSTIFICATIVA:
As equipes de desenvolvimento devem ser multifuncionais, possuindo todas as habilidades
necessárias para criar o incremento do produto. Não é defendida pelo scrum a criação de equipes
especializadas em determinadas camadas do sistema. O ideal é que a equipe possa ter conhecimento
para desenvolver em qualquer camada.
O tamanho da equipe afeta a sua eficiência: o scrum guide diz que o tamanho ideal da equipe de
desenvolvimento deve ser pequeno o suficiente para se manter ágil e grande o suficiente para
completar uma parcela significativa do trabalho.
Em uma equipe podemos encontrar profissionais seniores e juniores, mas não é defendida em
nenhuma parte do scrum guide a necessidade de uma combinação de nível de experiência.
42) How should a Development Team deal with non-functional requirements? [Código de
referência: 5817]
A) Handle them during the Integration Sprint preceding the Release Sprint.
B) Make sure the release department understands these requirements, but it is not the
Development Team’s responsibility.
C) Ensure every Increment meets them.
D) Assign them to the lead developers on the team.
JUSTIFICATIVA
JUSTIFICATIVA:
Desempenho, assim como segurança, escalabilidade e manutenção, são requisitos não funcionais.
Normalmente os requisitos não-funcionais são adicionados à definição de "Pronto" quando eles são
genéricos e se aplicam a todos os requisitos funcionais. Então, havendo uma definição de "Pronto"
contendo esses requisitos, é necessário que todo incremento atenda a estes requisitos.
43) A member of the Development Team takes the Scrum Master aside to express his concerns
about data security issues. What should the Scrum Master do? [Código de referência: 5818]
A) Create a Product Backlog item for security

B) Add security to the definition of “done”
C) Tell the Product Owner to stop further development of features until the issues are fixed
D) Ask the person to share the issue with the team as soon as possible
E) Go check with the testers
Menu
Simulado



25:54
Fe e dback final:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80


1) What is the standard used by the Product Owner and Scrum Team to identify unfinished work
in a Sprint? [Código de referência: 7023]
A) Coding Standard
B) Definition of Ready
C) Testing Standard
D) Definition of “Done”
JUSTIFICATIVA:
Definição de " pronto" proporciona o entendimento comum para a Equipe de Scrum sobre como
avaliar a conclusão de um item do Backlog do Produto ou do Incremento
2) What does the Scrum Master manage? [Código de referência: 7024]
A) Scrum People
B) Scrum Framework
C) Scrum Technology
D) All of them
E) None of them
JUSTIFICATIVA:
O Scrum Master não é um gerente de pessoas. O Scrum não prescreve qualquer tecnologia. Scrum é
Framework dentro do qual as técnicas e tecnologias podem ser utilizadas para o desenvolvimento de
produtos complexos.
3) Which Scrum events facilitate inspection and adaptation? [Código de referência: 7025]
A) Sprint
B) Testing
C) Sprint Retrospective
D) Analysis
JUSTIFICATIVA:
Uma sprint existe para que o time de desenvolvimento execute o trabalho necessário para produzir o
incremento sem receber interferências externas. Este evento não é focado em inspeção e adaptação.
Até poderia acontecer inspeção e adaptação, mas não é a proposta do Scrum para este evento. Para
inspeção e adaptação exitem a revisão da Sprint e retrospectiva da Sprint.
4) An important executive wants the Development Team to take in a highly critical feature in the
current Sprint. What should the Development Team do? [Código de referência: 7026]
A) Work on that since organization priority is more important

B) Ask the executive to talk to Product Owner
C) As empowered team, should seek the executive to select an alternative work to be removed
instead
JUSTIFICATIVA:
A equipe de desenvolvimento não deve receber diretamente solicitações de funcionalidades das
partes interessadas, isto deve ser feito ao Dono do Produto.
5) During Daily Scrum, what plan is used as a reference to understand the changes in progress?
A) Sprint Backlog
B) Product Backlog
C) Sprint Burn-down
JUSTIFICATIVA:
O Backlog da Sprint é um plano com detalhes suficientes para que mudanças no progresso possam
ser entendidas na Reunião Diária do Scrum.
6) Sprint Planning helps in: [Código de referência: 7028]
A) Building entire technical architecture

B) Staffing plan
C) Testing strategy
D) Release plan
E) None of the above
JUSTIFICATIVA:
O Planejamento da Sprint é focado em gerar um Backlog da Sprint e um Objetivo de Sprint. O Backlog
da Sprint consiste em escopo do trabalho planejado para que a Sprint e o plano para atinjam esse
escopo. Arquitetura técnica evolui ao longo das Sprints.
7) One of the Scrum Teams chose to have a Development Team member also playing the role of
Scrum Master. A Development Team member cannot also play Scrum Master’s role. [Código de
referência: 7029]
A) True
B) False
JUSTIFICATIVA:
A Scrum Master pode ser um membro do Time de Desenvolvimento, mas isso não é obrigatório e nem
recomendado porque pode gerar conflitos nos papéis.
8) The team has not completed anything by Sprint end. What is the next step? [Código de
referência: 7030]
A) Extend the Sprint since Scrum favors "getting done"

B) Advice Product Owner to accept completed portion of story, and plan to complete 100% of it by
next Sprint, since Scrum favors "empowered teams"
C) End the Sprint with a retrospective, since Scrum favors time boxing
JUSTIFICATIVA:
Os eventos do Scrum são baseados em um tempo fixo. Eles sempre terminam quando o tempo
estabelecido se esgota, não importa a questão que haja.
9) The Scrum Team, based on the learning from previous Sprints, decides to revisit the length of
the Sprint. What is the appropriate Scrum event to discuss and agree on the change? [Código de
referência: 7031]
A) Sprint Planning
B) Sprint Retrospective
C) Daily Scrum
D) Sprint Review
JUSTIFICATIVA:
A Retrospectiva da Sprint é um evento onde a equipe inspeciona a sua forma de trabalhar (pessoas,
relações, processos e ferramentas), e adapta-se quaisquer melhorias.
10) To effectively track the Sprint progress, Scrum mandates: [Código de referência: 7032]
A) Preparing Sprint burn down charts

B) Increasing the transparency by frequently updating the remaining work
C) Earned Value approach
JUSTIFICATIVA:
O Scrum não obriga o uso de gráfico ou técnicas como gerenciamento de valor agregado. Entretanto,
ele obriga que haja transparência em relação as informações por traz dos artefatos.
11) Only the Product Owner can come up with items that can be considered for Product Backlog.
Others cannot provide input / recommendations / ideas about new items [Código de referência: 7033]
Others cannot provide input / recommendations / ideas about new items [Código de referência: 7033]
A) True
B) False
JUSTIFICATIVA:
Embora o Product Owner tem a palavra final sobre o conteúdo e ordem do Product Backlog, ele ainda
pode obter a entrada / recomendações / ideias sobre novos itens de todos as partes interessadas
para consideração.
12) Sprint Planning is the only occasion where the Development Team estimates the Product
Backlog items [Código de referência: 7034]
A) True, because without estimate, the team cannot plan what can go into the Sprint
B) False, estimation of Product Backlog Items is a continuous event throughout
JUSTIFICATIVA:
Cada item no Product Backlog precisa ter uma descrição, ordem, valor e estimativa. O Product Owner
trabalha com equipe de desenvolvimento ao longo das sessões de refinamento Backlog para detalhar
os itens do backlog e obter a estimativas.
13) Which is true about Sprint Restrospective? [Código de referência: 7035]
A) It focuses on Product and Sprint Review focuses on development process

B) It focuses on development process and Sprint Review focuses on Velocity
C) It focuses on development process and Sprint Review focuses on Product
JUSTIFICATIVA:
A Sprint Review é um evento Scrum para inspecionar e adaptar o desenvolvimento do produto. A
Sprint Retrospective foca na inspeção e adaptação da forma de trabalhar para desenvolver o
produto.
14) During a Sprint Review, the Scrum Master notices that the Product Owner does not use the
Product burn-down graph to explain the status to stakeholder. The Scrum Master: [Código de
referência: 7036]
A) Should coach the Product Owner on the importance of using this Scrum tool
B) Should cancel the review and schedule it back when the Product Owner is ready with this
C) Do Nothing
JUSTIFICATIVA:
Existem muitas ferramentas como o gráfico burn-down que ajudam a mostrar a evolução do passado
e sua projeção no futuro. Enquanto elas são úteis, nenhuma destas ferramentas são obrigatórias no
Scrum. O Scrum Master deve se esforçar para treinar a equipe sobre a importância do empirismo e
não das ferramentas.
15) A short expression of the purpose of a Sprint which is often a business need– is called as:
A) Sprint Goal
B) Acceptance Criteria
C) Definition of Done
JUSTIFICATIVA:
A meta da Sprint precisa ser preservada. A Meta da Sprint dá a Equipe de Desenvolvimento alguma
flexibilidade em relação a funcionalidade a ser implementada na Sprint.
16) The estimation method recommended by Scrum is: [Código de referência: 7038]
A) Planning Poker
B) T-Shirt Sizing
C) Yesterday’s weather
JUSTIFICATIVA:
Embora estudado neste curso, o Scrum não prescreve qualquer técnica de estimativa específica. O
planning poker é totalmente opcional.
17) It is mandatory that the definition of "Done" includes “Release to Production”. [Código de
referência: 7039]
A) True
B) False
JUSTIFICATIVA:
Cada Sprint inclui a produção de um Incremento potencialmente liberável. No entanto, é o Product
Owner que tem a decisão de libera-lo em produção
18) Under this part of the Sprint Planning, the Development Team is more active in planning and
Product Owner is mostly observing or clarifying in: [Código de referência: 7040]
A) Part One (What)

B) Part Two (How)
JUSTIFICATIVA:
Na parte II da reunião de Planejamento da Sprint a equipe de desenvolvimento é mais ativa, pois ela
irá transformar o itens escolhidos em tarefas no backlog da Sprint.
19) What is the definition of “Done”? [Código de referência: 7041]
A) Testing strategy for Scrum Team

B) A standard used by Scrum Team to assess if a product Increment is “done”
C) Defined by Product Owner and safeguarded by Scrum Master
JUSTIFICATIVA:
Esta definição é usada para assegurar que o incremento do produto está "pronto".
20) A person external to the Scrum Team with a specific interest in and knowledge of a product
that is required for Incremental discovery, is known as: [Código de referência: 7042]
A) Technical/Domain Expert
B) Stakeholder
C) Senior Management
JUSTIFICATIVA:
As partes interessadas são geralmente consideradas como aquelas que têm algum interesse no
produto.
21) The Development Team tries to put together some guidelines on testing approach. Who will
own these guidelines? [Código de referência: 7043]
A) Development Team
B) Test Lead
C) Scrum Master
JUSTIFICATIVA:
A abordagem de testes é parte do trabalho de desenvolvimento. O trabalho de desenvolvimento é de
propriedade da Equipe de Desenvolvimento .
22) Who should participate of the Sprint Retrospective meeting? (select three options) [Código de
referência: 7044]
A) Product Owner
B) Stakeholders invited by Product Owner
C) Scrum Master
D) Development Team
E) Technical/Domain/Process experts invited by Development Team
JUSTIFICATIVA:
A Retrospectiva da Sprint é uma oportunidade para todo o Time Scrum para inspecionar e adaptar a
sua forma de trabalho. O Scrum Guide menciona que o todo o Time Scrum participa, logo inclui o
dono de produto, scrum master e equipe de desenvolvimento. Convém que todos participem desta
reunião.
23) Sprint Backlog is modified throughout the Sprint. What does Development Team need to do
as soon as a new task is identified? [Código de referência: 7045]
A) Product Owner adds it to the Sprint Backlog and communicates about it to Scrum Team
B) Scrum Master adds it to the Sprint Backlog and communicates about it to Scrum Team
C) Development Team adds it to the Sprint Backlog and communicates about it to Scrum Team
JUSTIFICATIVA:
A Equipe de Desenvolvimento é a proprietária do Backlog da Sprint.
24) What is required during the Sprint Review? (select two options) [Código de referência: 7046]
A) Product Owner’s sign-off

B) Stakeholders active participation
C) Transition sign-off
D) Inspection and Adaptation activities
JUSTIFICATIVA:
A Revisão da Sprint é uma reunião informal, não uma reunião de status. E a apresentação do
incremento se destina a obter feedback e promover a colaboração. Não há sinal-offs.
25) Does the application of Scrum guarantees the success of software projects? (select two
options) [Código de referência: 7047]
A) Yes
B) Compared to Waterfall – Yes
C) Scrum is a framework to solve complex problems using team work. It does not guarantee
anything
D) Scrum increases the opportunity to control risk and optimizes the predictability of progress
JUSTIFICATIVA:
Scrum aumenta a transparência para que as partes interessadas possam tomar decisões informadas
, e com isso há mais chances de sucesso.
26) The Sprint Backlog emerges during the Sprint because the Development Team modifies it
throughout the Sprint. In the middle of the Sprint, new work is added to Sprint Backlog. As a result,
estimated remaining work will: [Código de referência: 7048]
A) Increase
B) Decrease
C) Stay the same
JUSTIFICATIVA:
A estimativa da Sprint não é necessariamente constante. Quanto mais se aprende, mais o trabalho é
ajustado. Quando um novo trabalho é adicionado, ele aumenta a quantidade de trabalho restante.
27) To deliver a single product, three different Development Teams are formed. How many
Product Owners are needed? [Código de referência: 7049]
A) As many as recommended by Scrum Master

B) Three
C) One
JUSTIFICATIVA:
JUSTIFICATIVA:
Um único produto deve ter um único Product Backlog e, portanto, um único proprietário, um Product
Owner. O Product Owner pode delegar algumas das suas responsabilidades para a equipe, no
entanto ele ainda é responsável final pelo Product Backlog.
28) What are Scrum Value? (select three options) [Código de referência: 7050]
A) Respect and courage

B) Simplicity
C) Commitment and Openness
D) Creativity and Intuition
E) Focus
JUSTIFICATIVA:
Consulte o novo Scrum Guide 2016 em inglês que estabelece quais são os valores do Scrum bem no
início.
29) A Scrum Team has five members. Each one works on a different product. What could we infer
about the team? [Código de referência: 7051]
A) The team will have higher productivity since division of work is clear
B) The team implements diversity, a principle of Scrum
C) The potential of team work and benefit of Scrum is less
D) All of them still will have common definition of “Done”
JUSTIFICATIVA:
Considerando que todos estão trabalhando em produtos diferentes, há possibilidade muito mínima de
trabalho em equipe, colaboração e equipe auto-organizada.
30) What team Velocity refers to? [Código de referência: 7052]
A) Average of amount of Product Backlog Items turned into "Done" Items per Sprint
B) Average rate of churn of team members in Scrum Team during a Sprint
C) Average number of defects per Sprint normalized over all defect types
JUSTIFICATIVA:
A velocidade da equipe será medida pela quantidade de itens que ficaram "prontos" na Sprint. Elas
poderá ser baseada em pontos por história. Soma-se os pontos das histórias "prontas" para saber
qual é a velocidade.
31) The Scrum Framework is founded on: [Código de referência: 7053]
A) Empiricism
B) Empiricism and Technical Practices

C) Empiricism and Emotional Intelligence
JUSTIFICATIVA:
Práticas técnicas e inteligência emocional podem ser agregadas ao framework, mas não sua a sua
base.
32) Scrum Master forecasts the the date of release of product during Sprint Review. [Código de
referência: 7054]
A) True
B) False
JUSTIFICATIVA:
É responsabilidade do dono do produto acompanhar o andamento do Product Backlog e prever a
conclusão do produto.
33) In the middle of the Sprint, the Development Team didn’t get some technical tools that were
originally promised. This will slow down the work. What is the next best thing to do? [Código de
referência: 7055]
A) Scrum Master should escalate to Project Manager

B) Product Owner should cancel the Sprint
C) The Development Team should assess the impact to meeting the Sprint Goal and the definition
of “Done”, and find alternatives to still meet the Sprint Goal without compromising definition of "Done"
JUSTIFICATIVA:
O primeiro passo é a equipe tentar resolver sozinha o problema e encontrar trabalho em torno de
preservar a conclusão Meta da Sprint . Se isso não resolver o problema, isto precisa ser levantado
como um impedimento e contar com a ajuda Scrum Master.
34) A Development Team has created the Sprint Backlog in the form of a task board. What is your
inference as Scrum Master? [Código de referência: 7056]
A) The team can choose to represent it any form that makes sense
B) It is okay to have it in task board format, but it must be ensured that it follows Kanban guidelines
C) Scrum Master must coach the team to create proper Sprint Backlog in the form of list of backlog
items, related tasks, and estimations
JUSTIFICATIVA:
O Backlog da Sprint contém os itens do Product Backlog para a Sprint atual e o plano para completar
e alcançar o Objetivo da Sprint. O Scrum não prescreve qualquer formato ou técnica específica a ser
seguido para representar o Backlog da Sprint.
35) Velocity is an indication of team performance. Who may use it? [Código de referência: 7057]
A) The Scrum Team an internal measure to plan and track their improvements.
B) The managers to do performance appraisals for the team
C) The organization to aggregate into organization level productivity
JUSTIFICATIVA:
A Equipe Scrum é autogerenciada, então esta medida é para sua autoavaliação.
36) In a new Scrum Team, a Scrum Master notices that a Development Team member works on a
task that is not contributing to the Sprint Goal or Sprint Backlog. What should the Scrum Master do?
A) Escalate this to Product Owner

B) Discuss with team member and educate about Scrum way of working
C) Do not interrupt since the team is self-organizing
JUSTIFICATIVA:
O Scrum Master não gerencia pessoa . Ele encorajar a auto-organização da equipe para gerir o seu
trabalho. No entanto, o Scrum Master é o guardião do framework Scrum e, consequentemente, as
suas regras. Um membro da equipe de desenvolvimento só deve trabalhar em tarefas relacionadas
com a Sprint Goal. Quando há uma violação, o Scrum Master ativamente atua para treinar a equipe
em Scrum.
37) The Scrum Team gathers for Sprint Planning meeting. The Product Owner has some Product
Backlog items but the Development Team finds that they do not have enough information to
understand the work involved and to make forecast. What is the next best thing to do? [Código de
referência: 7059]
A) The Scrum Master cancels the Sprint

B) The Development Team proceeds with starting with whatever is known
C) The Development Team makes it transparent that they cannot make a forecast with insufficient
information, and negotiates with Product Owner on refining the Product Backlog items to ready state
D) The Scrum Team discusses the root cause in the retrospective
JUSTIFICATIVA:
A equipe de desenvolvimento deve manter maior transparência ao fazer uma previsão do trabalho
que ela acredita que poderia ser concluído. Neste caso, ela não pode fazer isso porque os itens do
Product Backlog não fornecem informações suficientes. Assim, ela tem que utilizar o tempo disponível
para refinar os itens para o estado requerido e prosseguir com o plano.
38) In the middle of the Sprint, the Development Team finds that it has more capacity to take more
work. What is the next best thing to do? [Código de referência: 7060]
A) Make it transparent to Product Owner immediately, and collaborate to add additional work.
B) Consult and follow Scrum Master’s and follow their direction
C) Keep that as a contingency to accommodate unplanned work
JUSTIFICATIVA:
Se tempo vai sobrar, a equipe de desenvolvimento tem que avisar o Product Owner para seja
encaixado mais trabalho na sprint atual.
39) The Development Team is not having regular Daily Scrums. What do you have to do as a
Scrum Master? [Código de referência: 7061]
A) Will advise the team to think about conducting regular Scrums, but will let the team take the
decision themselves as they are self-organizing
B) Will escalate this to resource managers
C) Will step in directly to guard the Scrum Framework by asking action-begetting questions to
team and positively influencing them to conduct Scrum events
JUSTIFICATIVA:
O Scrum Master é o guardião do framework Scrum e, consequentemente, as suas regras.
40) When a Scrum Team adds new team members for replacing some members going out, the
productivity of the team [Código de referência: 7062]
A) Will be negatively impacted

B) Will be positively impacted
C) Will remain the same
JUSTIFICATIVA:
Quando os novos membros da equipe entram, a produtividade da equipe será temporariamente
reduzida.
41) Who starts the Daily Scrum? [Código de referência: 7063]
A) Whoever the Development Team decides should start.

B) The person who last broke the build.
C) The person who has the token.
D) The person coming in last. This encourages people to be on time and helps to stay within the
time-box.
E) The Scrum Master. This ensures that the Development Team has the meeting and stays within
the time-box.
JUSTIFICATIVA:
O Scrum Guide não determina como a reunião diária deve ser realizada. As únicas regras explícitas
são:
- Ser um timebox de 15 minutos

- Deve ser mantida no mesmo horário e local todo dia para reduzir a complexidade
- Deve ser diária
Apesar de ser tentador achar que o Scrum Master é quem deve iniciar a reunião, lembre-se que o
Scrum Master não precisa sequer participar da reunião, ele precisa apenas garantir que ela ocorra.
Sendo assim, a opção mais correta é deixar o time se auto-organizar.
42) What is the role of Scrum Master with respect to Scrum artifacts? [Código de referência:
7064]
A) Coach the team to increase the transparency of the artifacts
B) Decide the format of the artifacts and ensures that the team follows it
C) Owner of the artifacts and responsible for having them up to date
JUSTIFICATIVA:
O Scrum Master pode ensinar a utilizar os artefatos definidos pelo Scrum, especialmente em relação a
transparência que é um pilar importante.
43) Three Development Teams are working as part of a big project to develop a product. When
Sprints are in motion, there will be: [Código de referência: 7065]
A) Three Product Backlogs, and three Sprint Backlogs

B) One Product Backlog, and three Sprint Backlogs
C) One Product Backlog and one Sprint Backlog
JUSTIFICATIVA:
Cada equipe vai ter o seu próprio Backlog de Sprint, mas o Backlog de Produto será único.
44) In empiricism, the decisions are based on: [Código de referência: 7066]
A) Scientific calculation and Prediction

B) Meeting and Brainstorming
C) Observation, experience and experimentation
JUSTIFICATIVA:
O empirismo é uma teoria de controle de processos em que apenas o passado é aceito como certo e
em que as decisões são baseadas em observação, experiência e experimentação.
45) What is the correct statement? [Código de referência: 7067]
A) The technical design continuously evolves over the Sprints. Hence the team should have some
basic guidelines to start with, but try to emerge the design through the Sprints.
B) The team can choose to have an exclusive Sprint only to finalize the technical design. At the
end, the design should be approved by the project architect
C) The team does not need to pay attention on the architecture as it will evolve itself as a by-
product of self-organization
JUSTIFICATIVA:
Não há Sprint exclusiva apenas para finalizar o design. Cada Sprint deve ser usada para produzir,
pelo menos, uma funcionalidade que é potencialmente liberável.
46) A Development Team is often interrupted in the Sprint midway and assigned to work on
“other” high priority items. Frequently, such interruptions lead to not meeting the Sprint Goal. The most
likely cause could be [Código de referência: 7068]
A) The Development Team is not technically competent

B) The Product Owner authority is ineffective or influenced by another authority
C) Th S i t Pl i i
C) The Sprint Planning is poor
JUSTIFICATIVA:
O Product Owner é a autoridade final do Product Backlog em que a equipe de desenvolvimento deve
trabalhar. Aqueles que querem mudar a prioridade de um item do Backlog do Produto deve falar com
Product Owner. Para o Product Owner ter sucesso, toda a organização deve respeitar as suas
decisões. Se a equipe de desenvolvimento está fazendo um trabalho diferente, isso indica que a
autoridade Product Owner foi interrompida.
47) Select all that apply. In Sprint Planning, a Scrum Team spends lot of time in discussing and
estimating Product Backlog items. It also ensures that all the work associated with each Product
Backlog item are identified and sufficiently decomposed. The Sprint Planning meetings are always
going beyond the time boxing. What could be the possible causes? (select two options) [Código de
referência: 7069]
A) The Scrum Master is new

B) The team didn’t invest enough in Backlog Refinement
C) The Product Backlog size is huge
D) The Development Team is trying to get perfect and detailed Sprint plan before starting any
work
JUSTIFICATIVA:
O papel do Scrum Master não é controlar pessoas ou discussões. Ele é um treinador e educador. O
Scrum Master ensina as práticas ágeis para que o time pode ter eficiência no seu trabalho. Ele pode
ensinar o Dono do Produto a priorizar. Ele pode ensinar a como fazer o grooming e preparar o
backlog para a reunião de planejamento. Se ele ensinar a fazer isto, o time terá condições de realizar
a reunião de planejamento da Sprint dentro do time-box. O fato de ser um Scrum Master novo não
necessariamente indica que ele não sabe atuar como um treinador. Isto seria muito diferente em dizer
que o Scrum Master é inexperiente e não treinou o time adequadamente, entretanto, não existe esta
opção de resposta.
O tamanho Product Backlog não tem impacto sobre o tempo porque o time não precisa discutir todos
os itens do backlog, mas apenas aqueles que estão ordenados no topo e os que estão
suficientemente preparados "ready" para serem puxados para dentro da Sprint.
Para que a reunião de planejamento da Sprint possa ser realizada com sucesso dentro da time-box é
imprescindível que o Backlog de Produto venha com os itens prioritários PREPARADOS para a
reunião e isto é feito na sessões de grooming (refinamento) durante as sprints anteriores. Estar
preparado significa que o item do Backlog do Produto tem que estar detalhado o suficiente para que
ele possa ser entendido e estimado. Se isto não for feito antes da reunião de planejamento da Sprint,
então o Time Scrum vai gastar mais tempo adicional para fazer isto na própria reunião de
planejamento. Recomenda-se que o time reserve em torno de 5% da sua capacidade para fazer esse
grooming.
48) Middle of the Sprint, the Development Team finds that some of the Product Backlog Items
forecast for this Sprint cannot be finished because they need significant additional effort. However, the
Development Team can still meet Sprint Goal with rest of the items. What is the next thing to do?
A) C l ihP d O d if h h h l h S i d l
A) Consult with Product Owner and if they agree, have them cancel the current Sprint, and plan
new Sprint with new estimations
B) Do not cancel or modify the Sprint. Extend the Sprint duration as required for the additional
effort
C) Remove the Product Backlog Items that cannot progress. Collaborate with the Product Owner
to add new work up to team’s capacity. Complete the Sprint.
JUSTIFICATIVA:
Cancelamento da Sprint é decidido pelo Product Owner e Product Owner não vai cancelar a Sprint a
menos que o objetivo do Sprint tornou-se obsoleto . Aqui nesta questão, o objetivo da Sprint está
intacto. Além disso, o tempo da Sprint não pode alongado uma vez que seu tempo é time-boxed .
49) For a Scrum Team that develops software, what provides the shared understanding of
standards that software should meet in order to be accepted as complete by Product Owner? [Código
A) Acceptance Criteria
B) Definition of ready
C) Definition of “Done”
JUSTIFICATIVA:
Definição de " pronto" define as normas a serem cumpridas para um item de Backlog do Produto para
ele ser considerado como "pronto".
50) The Product Owner provides the transparency of their product plan to the stakeholders and
the Scrum Team through [Código de referência: 7072]
A) Sprint Backlog
B) Planning Backlog
C) Project Backlog
D) Product Backlog
JUSTIFICATIVA:
O Product Owner usa Product Backlog para atualizar as partes interessadas sobre o estado atual do
plano de produto.
51) What is the role of Scrum Master during the Daily Scrum? (select two options) [Código de
referência: 7073]
A) Facilitate discussions of the Development Team

B) Moderate and control so that everyone gets a fair chance to speak
C) Ensure that all 3 questions have been answered
D) Teach the Development Team to keep the Daily Scrum within the 15 minute time box
E) All of the above
JUSTIFICATIVA:
Scrum Master facilita os eventos Scrum conforme e quando solicitado por outros ou exigidos por suas
observações. O Scrum Master não tem qualquer papel ativo em dirigir ou controlar o Daily Scrum.
Cabe à equipe de desenvolvimento para fazer a sua sincronização e discutir o progresso. Scrum
Master é o guardião do processo Scrum e o time-box e é uma regra fundamental do Scrum . Então,
Scrum Master treina a equipe para manter as regras do Scrum.
52) Burn-up and Burn-down charts show evolution of progress over time. In particular, [Código de
referência: 7074]
A) Burn-up shows increase in completion, while Burn-down shows remaining effort

B) Burn-up shows increase in team productivity, while Burn-down shows decrease in productivity
C) Burn-up shows increase in turn-around time, while Burn-down shows decrease in turn-around
time
JUSTIFICATIVA:
Estes gráficos não são obrigatórios, mas sim opcionais no Scrum. Eles são usados para tornar o
progresso transparente.
53) A Development Team decides to have an exclusive Sprint to evolve the technical architecture.
The sole outcome of this Sprint is a finalized architecture design. [Código de referência: 7075]
A) It is a good practice since it will help the design to emerge

B) It is not the Scrum approach, since every Sprint must produce at least one releasable
functionality
C) It does not matter, since the team is self-organized about how to perform their work
JUSTIFICATIVA:
Não há Sprint exclusiva ou evento Scrum para definir a arquitetura técnica inicial. Normalmente
Equipe de Desenvolvimento define diretrizes arquitetônicas que
cada membro da equipe pode usar em seu trabalho.
54) In Scrum based software development effort, while the Sprint Goal will deliver a Product
Increment, one of the Product Backlog Items is asking for production of a document. [Código de
referência: 7076]
A) It is not okay. Every Product Backlog item must be about a working software requirement
B) It is not okay. Documentation is not needed until Product Owner chooses to release an
Increment to production
C) It is okay. A Sprint can produce a document as a sole outcome of the Sprint
D) It is okay. A Sprint can produce other deliverables like document requested by Product Owner
along with working Increment.
JUSTIFICATIVA:
Embora a Sprint tem de produzir necessariamente um incremento potencialmente liberável e útil,
alguns dos itens do Product Backlog poderiam produzir outras entregas, incluindo documentos, se o
Product Owner os considera ter valor apropriado.
55) It is essential for the Product Owner to have these skills. Usually Scrum Master serves the
Product Owner by coaching him in: (select two options) [Código de referência: 7077]
A) Software application development

B) Understanding and practicing agility
C) Coaching team
D) Product planning in empirical environments
JUSTIFICATIVA:
Considere que treinar a equipe é atribuição do Scrum Master, então ele vai servir o dono do produto
no que se refere ao entendimento de práticas ágeis.
56) What is the role of Scrum Master in Sprint Retrospective? [Código de referência: 7078]
A) Auditor
B) Silent Observer
C) Peer Team Member
JUSTIFICATIVA:
Um dos itens revistos na retrospectiva é a " implementação do framework Scrum". Considerando que
Scrum Master é o proprietário disto, ele participa como qualquer membro da equipe.
57) A Scrum Team is in the process of defining Product Backlog items. The Scrum Master notices
that the team is not using User Story format to capture the backlog items. What should the Scrum
Master do? [Código de referência: 7079]
A) correct the team’s behavior by coaching them about user stories

B) let the team decide the format of Product Backlog items
C) add a business analyst with knowledge of writing user stories to the team, with specific
responsibility of documenting backlog in terms of user stories
JUSTIFICATIVA:
O Scrum não prescreve qualquer técnica específica para capturar os itens do Product Backlog. A
equipe pode escolher a técnica mais benéfica para trabalhar.
58) An organization decides to have very small Development Teams of size fewer than three. The
likely result could be: [Código de referência: 7080]
A) The team may have decreased interaction

B) The team may have skills shortage
C) The team may have low productivity gains
D) All of the above
JUSTIFICATIVA:
Enquanto a equipe de desenvolvimento deve ser pequena o suficiente para ser ágil, menos de três
membros na equipe diminui a interação e resulta em ganhos de produtividade menores. Equipes de
desenvolvimento menores podem encontrar limitações de conhecimento durante a Sprint, fazendo
com que a equipe de desenvolvimento seja incapaz de entregar um incremento potencialmente
co que a equ pe de dese o e to seja capa de e t ega u c e e to pote c a e te
liberável .
59) The leadership model followed by Scrum Master is: [Código de referência: 7081]
A) Micro Management
B) Servant Leadership
C) Command and Control
JUSTIFICATIVA:
O Scrum Master serve a equipe de desenvolvimento.
60) During a Sprint Review, the stakeholders notice that the product development progress is not
very clearly visible and lacked transparency. Moreover, they are not able to understand the next steps.
Who is responsible for this? [Código de referência: 7082]
A) Development Team
B) Product Owner
C) Scrum Master
D) Scrum Team
JUSTIFICATIVA:
O dono do produto é responsável por manter a transparência do Product Backlog, o progresso até
agora e os próximos passos, juntamente com alternativas, se houver.
61) When more Scrum Teams are added to a project that works on one single product, the
productivity of the original Scrum Teams mostly likely will increase. [Código de referência: 7083]
A) True
B) False
JUSTIFICATIVA:
Cada equipe Scrum precisa definir mutuamente a sua definição de "pronto " para o seu trabalho
combinado que será potencialmente liberável. Isso envolve algum trabalho de sobrecarga na
sincronização e, portanto, há impacto na produtividade.
62) The architectural features of the product need to be: [Código de referência: 7084]
A) Evolved along with Sprint deliveries

B) Completely designed upfront before the Sprints
C) Decided at least at skeleton level in Sprint zero
JUSTIFICATIVA:
Algumas equipes podem personalizar o Scrum para incluir iteração/Sprint zero antes da primeira
Sprint para fazer o design. Esta é a substituição do tradicional " Big Upfront Design" do modelo
cascada e põe abaixo a ideia do empirismo defendida pelo Scrum.
63) Sprint longer than one calendar month may result in: [Código de referência: 7085]
A) Too much to inspect in short meetings

B) Detached stakeholders
C) Increased complexity needing more traditional controls like documentations
D) All of the above
JUSTIFICATIVA:
Quanto mais tempo tiver a duração da Sprint, as práticas de trabalho tendem a se basear no modelo
cascata: com longas reuniões, falta de feedback inicial das partes interessadas,
documentação/necessidades de comunicação devido à crescente complexidade.
64) The work left against time is shown by: [Código de referência: 7086]
A) Team Velocity
B) Burn-down graph
C) Story Points Burn
D) Release Burn-up
JUSTIFICATIVA:
O Burndown chart ou gráfico de Burndown é o gráfico utilizado pelas equipes Scrum para representar
diariamente o progresso do trabalho em desenvolvimento. Ou seja, após cada dia de trabalho o
gráfico apresenta a porção de trabalho finalizada em comparação com o trabalho total planejado.
Também é possível ver o trabalho que falta e o tempo que resta na sprint.
65) In Sprint Review, along with the review of the product Increment and progress, “what (steps) to
do next” is also discussed. [Código de referência: 7087]
A) False
B) True, and the scope of the next Sprint is also finalized here
C) True, and it may capture probable backlog items for next Sprint, but the scope of the next
Sprint is deferred until Sprint Planning
JUSTIFICATIVA:
Cada evento Sprint é uma oportunidade para inspecionar e adaptar-se. "O que fazer a seguir " é
sobre a adaptação do Product Backlog se necessário. O escopo da Sprint é tratado no Planejamento
da Sprint, e não na Sprint Review.
66) A Scrum Team decides that the frequency of Daily Scrum should be reduced to once per
week. Is this consideration correct? [Código de referência: 7088]
A) Yes, because the Scrum Team is self-organized. So they can choose their practices
B) No, self-organization is alright but such decisions need to be approved by agile coach. So, they
should involve agile coach.
C) No, self-organization is about how to get the Sprint work done but subject to following Scrum.
So, Scrum Master should strive to coach the team on the essentials of Daily Scrum
JUSTIFICATIVA:
É essencial que esta reunião seja diária, senão poderá se perder as oportunidades de adaptação e
inspeção.
67) Every Sprint, the working Increment should be tested progressively from unit testing, to
integration testing, and then user acceptance testing. [Código de referência: 7089]
A) Yes. It is the prescribed method

B) No. The test strategy is decided by the Quality Assurance Lead in the team
C) Not necessary. While the team needs to ensure that each Increment is thoroughly tested,
ensuring that all Increments work together, and meets definition of “Done”, it is up to the team to find
best method to achieve this
D) Incorrect. It should also include non-functional testing.
JUSTIFICATIVA:
A equipe é auto-organizada em relação a seu próprio trabalho. Ela pode empregar abordagens e
técnicas que proporcionam melhor retorno sobre o seu esforço.
68) Definition of “Done” is: [Código de referência: 7090]
A) Initially defined per product by Scrum Team, but may change throughout the product
development duration
B) Initially defined per Scrum Team, and does not change
C) Defined after first Sprint based on the new insights obtained from first Sprint Review
JUSTIFICATIVA:
Se a definição de “pronto” para um incremento é parte das convenções, padrões ou diretrizes de
desenvolvimento da organização, todos os Times Scrum devem segui-la
como um mínimo. Se “pronto” para um incremento não é uma convenção de desenvolvimento da
organização, o Time de Desenvolvimento do Time Scrum deve definir uma definição de “pronto”
apropriada para o produto. E esta definição pode ser adaptada ao longo do projeto, conforme o Time
Scrum aprende mais sobre o seu trabalho.
69) Which of the following statements are true? (select two options) [Código de referência: 7091]
A) After Sprint Planning, a Sprint cannot proceed without complete requirement specification
B) After Sprint Planning, a Sprint cannot proceed without a Sprint Goal
C) After Sprint Planning, a Sprint can proceed without a complete Sprint Backlog
D) After Sprint Planning, a Sprint cannot proceed without complete architecture
JUSTIFICATIVA:
- Após Planejamento de Sprint, uma sprint não poderá prosseguir sem uma meta. A definição de meta
é obrigatória durante o planejamento da Sprint. A meta é que vai guiar a Equipe de Desenvolvimento
durante a Sprint.
- Após Planejamento de Sprint, uma sprint PODE prosseguir SEM ter um backlog de Sprint completo.
O que não for possível detalhar em termos de atividades para desenvolver os itens selecionados
q p p
durante a reunião de planejamento poderá ser feito durante a Sprint. Tem que considerar que o
Backlog da Sprint pode ser ajustado durante a Sprint. O próprio Scrum Guide deixa bem claro isto: A
Equipe de Desenvolvimento modifica o Backlog da Sprint ao longo de toda a Sprint, e o Backlog da
Sprint vai surgindo durante a Sprint. Este surgimento ocorre quando a Equipe de Desenvolvimento
trabalha segundo o plano e aprende mais sobre o trabalho necessário para alcançar o objetivo da
Sprint.
70) A Development Team is self-organized and empowered. It is also the authority on deciding
what business needs are required to be developed [Código de referência: 7092]
A) True
B) False
JUSTIFICATIVA:
Isto é responsabilidade do Dono de Produto.
71) A Product Owner can not send a representative (delegate) to the Sprint Review. [Código de
referência: 7093]
A) True
B) False
JUSTIFICATIVA:
O Product Owner é responsável pelo Product Backlog, ele pode delegar muitas das atividades em
torno da gestão Product Backlog, como escrever os itens, ordenar, etc. No entanto, ele não pode
delegar a sua participação em eventos Scrum
72) What is an Increment? [Código de referência: 7094]
A) The sum of the value of all increments from previous iterations integrated with the Product
Backlog Items “done” in latest Sprint
B) The sum of Product Backlog Items selected into Sprint Backlog
C) The sum of Product Backlog Items “done” in latest Sprint
JUSTIFICATIVA:
O Scrum Guide estabelece que um Incremento é é a soma de todos os itens do Backlog do Produto
completados durante a Sprint atual e tudo das Sprints anteriores.

PSM PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

PSM PDF

Încărcat de

Drepturi de autor:

Formate disponibile

The Scrum Guide™

The Definitive Guide to Scrum:

1. Research and identify viable markets, technologies, and product capabilities;

Three pillars uphold every implementation of empirical process control: transparency,

The Product Owner

• Clearly expressing Product Backlog items;

Development Teams have the following characteristics:

Development Team Size

The Scrum Master

Scrum Master Service to the Development Team

• Coaching the Development Team in self-organization and cross-functionality;

Scrum Master Service to the Organization

• Leading and coaching the organization in its Scrum adoption;

During the Sprint:

• No changes are made that would endanger the Sprint Goal;

Sprint Planning answers the following:

Topic One: What can be done this Sprint?

Topic Two: How will the chosen work get done?

Daily Scrums improve communications, eliminate other meetings, identify impediments to

The Sprint Review includes the following elements:

The purpose of the Sprint Retrospective is to:

If "Done" for an increment is not a convention of the development organization, the

Desenvolvido e mantido pelos criadores do Scrum: Ken Schwaber e Jeff

As regras do Scrum integram os papéis, eventos e artefatos, administrando as relações e

1. Pesquisar e Identificar mercados viáveis, tecnologias e funcionalidades de produtos;

Como tecnologia, mercado, complexidades ambientais e suas interações tem aumentado

Scrum demonstra efetividade especialmente na transferência de conhecimento iterativo e

A essência do Scrum é um pequeno time de pessoas. O time individual é altamente flexível e

Quando as palavras “desenvolver” e “desenvolvimento” são usadas no Guia Scrum, elas se

Três pilares apoiam a implementação de controle de processo empírico: transparência,

2 Veja definição de “Pronto”, p. 17

Times Scrum entregam produtos de forma iterativa e incremental, maximizando as

O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. O

• Expressar claramente os itens do Backlog do Produto;

Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar

Os Times de Desenvolvimento tem as seguintes características:

Tamanho do Time de Desenvolvimento

O Scrum Master trabalhando para o Product Owner

• Garantindo que objetivos, escopo e domínio do produto sejam entendidos o melhor

O Scrum Master trabalhando para o Time de Desenvolvimento

• Treinando o Time de Desenvolvimento em autogerenciamento e interdisciplinaridade;

O Scrum Master trabalhando para a Organização

• Liderando e treinando a organização na adoção do Scrum;

As Sprints contém e consistem de um planejamento da Sprint, reuniões diárias, o trabalho de

Quando a Sprint é cancelada, qualquer item de Backlog do Produto completado e “Pronto” é

O cancelamento de Sprints consome recursos, já que todos se reagrupam em outro

O planejamento da Sprint responde as seguintes questões:

• O que pode ser entregue como resultado do incremento da próxima Sprint?

Tópico Um: O que pode ser Pronto nesta Sprint?

A entrada desta reunião é o Backlog do Produto, o mais recente incremento do produto, a

Tópico Dois: Como o trabalho escolhido será Pronto?

O Time de Desenvolvimento frequentemente inicia o desenho do sistema e do trabalho

No final do planejamento da Sprint, o Time de Desenvolvimento deve ser capaz de explicar ao

Conforme o Time de Desenvolvimento trabalha, eles mantêm o objetivo da Sprint em mente.

O Time de Desenvolvimento usa a Reunião Diária para inspecionar o progresso em direção ao

A estrutura da reunião é definida pelo Time de Desenvolvimento e pode ser conduzida de

O Time de Desenvolvimento ou membros da equipe frequentemente se encontram

A Reunião Diária é uma reunião interna do Time de Desenvolvimento. Se outros estiverem

Reuniões Diárias melhoram as comunicações, eliminam outras reuniões, identificam e

A Revisão da Sprint inclui os seguintes elementos:

• Os participantes incluem o Time Scrum e os Stakeholders chaves convidados pelo Product

O resultado da Revisão da Sprint é um Backlog do Produto revisado que define os prováveis

A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes do planejamento da