PSM.pdf

The Scrum Guide Guide™ The Definitive Guide to Scrum: The Rules of the Game

November 2017

Developed and sustained by b y Scrum creators: Ken Schwaber and Jeff Sutherland

Table of Contents

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 http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary for m at http://creativecommons.org/licenses/by-sa/ http://creativecommons.org/licenses/by-sa/4.0/. 4.0/. By utilizing this Scrum Guide, you ack nowledge and agree that you have read and agree to be bo und by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 2

Purpose of the Scrum Guide

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


Page | 2

Purpose of the Scrum Guide

Purpose of the Scrum Guide Scrum is a framework for developing, delivering, 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 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 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 improve the product, the team, and the working environment. 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 t he roles, events, and artifacts, governing the relationships and interaction between them. The rules of Scrum are described t hroughout hroughout the body of this document. Specific tactics for using the Scrum framework vary and are described elsewhere.


Page | 3

Uses of Scrum

Uses of Scrum Scrum was initially developed for managing and developing products. Starting in t he 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) a nd 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 pe ople. 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.

©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 for m at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you ack nowledge and agree that you have read and agree to be bo und by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 4

Transparency

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 t o 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. ©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 for m at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you ack nowledge and agree that you have read and agree to be bo und by the terms of the Attribution Share-Alike license of Creative Commons.

Page | 5

The Scrum Team

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 n ot 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 P roduct 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 o f 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 interact ions to maximize the

value created by the Scrum Team.


Page | 7

Scrum Master Service to the Product Owner

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

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 c annot be shortened or lengthened. The remaining events may end whenever the purpose of t he 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

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 t o 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 P roduct 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 t hat the Sprint should achieve and the Product Backlog items that, if completed in t he 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 so lely 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

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 I ncrement 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 t his 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 t he 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

Daily Scrum The Daily Scrum is a 15-minute t ime-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 t he 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 t o 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 selforganizing team to accomplish the Sprint Goal and create the anticipated Increment by t he end of the Sprint. The structure of the meeting is set by t he Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. questions, some will be more discussion based.

Some Development Teams will use

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

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 timebox. 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 t he 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

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 po tential 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 t he 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 t o provide transparency and opportunities for

inspection and adaptation. Artifacts defined by Scrum ar e specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.


Page | 14

Product Backlog

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 o f 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 selec tion 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 t he 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

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 burndowns, 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 m odifies 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 t he Development Team.


Page | 16

Monitoring Sprint Progress

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 en d 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 h elp 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”

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 Scr um 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 func tionality that adhere to the Scr um 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 de finition 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

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 t oday.

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

MR Scrum

Um guia definitivo para o Scrum: As regras do Jogo

Novembro de 2017

Desenvolvido e mantido pelos criadores do Scrum: Ken Schwaber e Jef f 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.


Página | 3

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. 2. 3. 4.

Pesquisar e Identificar mercados viáveis, tecnologias e funci onalidades de produtos; Desenvolver produtos e melhorias; Liberar produtos e melhorias frequentes, chegando a várias vezes por dia; 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. ©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 | 4

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 t rabalho 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. 1 7


Página | 5

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 increme ntais 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.


Página | 6

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


Página | 7

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.


Página | 8

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 prog resso em direção à meta pelo menos a cada mês corrido. Sprints também limitam o risco ao custo de um mês corrido.


Página | 9

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 li mites 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.


Página | 10

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


Página | 11

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.


Página | 12

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 S prints 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. ©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 | 13

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 ©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 | 14

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 burndowns, burn-ups, ou fluxos cumulativos . Estas tem se provado úteis. Contudo, não substituem


Página | 15

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 Spr int 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.


Página | 16

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”, todo s 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 seguila 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”.


Página | 17

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 coapresentaçã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 incl uem Fábio Cruz e Eduardo Rodrigues Sucena. ©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 | 18

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 i terativo 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


Página | 19

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.


Página | 20

Ambiente de ens ino virtual

Log off

Menu

Simulado Curso e-le arning Fundamentos do Scrum - Preparatório para o e xame PSM I (novo curso atualizado) >Simulado Scrum Master 1 - 80 questões em inglês

PRATICAR NOVO SIMULADO

CONSULTAR MEU HISTÓRICO

ENCERRAR

Seu resultado neste 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ê ace rtou:75(93.75%) Tempo para completar o teste:60

min

Tempo que você usou:

38:07 Fee 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 q uestão e cor ver de 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

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 respo sta corretas foram marcadas em cor verde e as o pções incorretas selecionadas por você foram marcadas em cor laranja. Algumas questões podem apresentar jus tificativ a para a op ção correta logo aba ixo. 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 qu e você não entendeu da questão e também qual é o código de referência da questão para que o tutor po ssa localizar a questão q ue você ficou em dúvida. O código de referência aparece no final da pergunta e está entre colchetes. Não permitimos a cópia de conteúdo das que stões. Se o simulado for em inglês e você precisa

de tradução, utilize o navegador Chro me 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 pre cisam 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 d eterminar 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

nspect ng wor at pr nt ev ew JUSTIFICATIVA: O product owner não é re sponsável pela condução da reunião diária, e sim a equipe de desenvolvimento. O scrum master deve assegu rar que esta r euniã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 re quisitos para os itens do backlog do pro duto e por tra balhar em conjunto com as partes interessadas para determinar características e detalhes do produto.

4) How should items in the Product Backlog be or dered? [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 p roduto sejam priorizados por ord em de valor ao negócio. Os mais importantes deve m 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á ape nas três pa pé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 traba lho realizado pela pe ssoa.

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 can celada se a Meta da Sprint se tornar obsoleta. Isto pode ocorrer se a empresa mudar a direção ou se as

con ç es o merca o ou ecno og a mu arem.

7) When multiple teams work together on the same product, each te am 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 equ ipes forem usadas para desenvolver no mesmo produto. Qua lquer outra configuração p ode dificultar a Equipe de Desenvolvimento para de terminar 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 d e desenvolvimento concordou e se comprometeu com o product owner sobre q uais 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 pa drão do framework scrum definido no scrum guide, ap esar de largamente utilizado pelas equipes que adotam o scrum. Todos os de mais fazem parte do framework scrum.

10) When do Development Team members become the exclusive owner of a Sprint Backlog item?

[Código de referência: 3835]

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 pro priedade da Equipe de desenvolvimento. Nenhum membro individual pode requer er a propriedade de um item porque isto bloquearia a comunicação e e colaboração.

11) Which of the following statements best e xplains 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 pro duto 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 prob lemas.

C) A sprint é o momento de realizar todo o trab alho 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 cau sar descontentamentos e desmotivar a equipe.

12) A Product Owner is entitled to postpone the star t 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 se r diária por meio das reuniões diárias. Todas as outras o pções são eventos o ficiais.

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 prod uto com baixa prioridade. Recomenda-se que os itens do b acklog 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 d evem ser colocados no backlog do pro duto, mesmo os itens com menos detalhes. Itens com menos detalhes normalmente são itens d e baixa prioridade. Conforme mais detalhes são conhecidos, eles tendem a r eceber 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 duran te as sprints. Se você escolheu a opção B, saiba que ela não é a melhor resposta p orque não e xiste fase de desenho de ntro da a bordagem 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 sp rint é 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 segund a opção: quand o 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 deter mines whether the Development Team has been assigned enou gh 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 é cap az de entrega r durante uma sprint. Ninguém mais pode dizer à equipe quantos itens e la deve entrega r. 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 autog erenciada.

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 é re sponsável pela atribuição de tarefas aos membros da equipe de desenvolvimento. A própria equipe de d esenvolvimento se or ganiza e define quem fará determinada atividade (normalmente cada membro da equipe escolhe qua is atividades fará). As demais atividades são de respon sabilidade do product owner.


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 engan e! Atividades de teste, g arantia da qualidade, implantação e desenvolvimento do software são atividades que devem ser re alizadas durante uma sprint, por meio de tarefas do backlog da sprint. No final de uma sprint não ocor rem mais atividades de dese nvolvimento - 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”, po tencialmente 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 e quipe de desenvolvimento planeja as tarefas n ecessárias, faz as estimativas e cria o b acklog 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 d as partes interessadas du rante a revisão da sp rint 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 d a 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 qu e aconteceu d urante a Sprint. No máximo o time de desen volvimento vai discutir isso n a reunião de retrospectiva, mas não em forma de re latório.

24) Who is responsible for managing the progress o f work during a Sprint? [Código de referência:

3850]

A) The most junior member of the Team B) The Product Owner 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 progr esso está indo em direção a completar o trabalho no Backlog da Sprint.

25) From the a ctivities 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 re trospectiva 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 d o backlog do produto. Ele pode ajudar o Product Owner a encontrar técnicas mais eficientes para fazer a priorização, mas quem define se u m 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 da s práticas Scrum na organização (socializing scrum).

27) Which of the following is reflected in a Sprint bur ndown chart? [Código de referência: 3853]

A) Team members names B) Number of Product Backlog items completed

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 pe r 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 a gradá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 qu atro 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 po ints 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) d a equipe de desenvolvimento. Para isso, some a quantidade de ponto s 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 par a entregar os itens restantes, estimados em 42 pontos. Para isso, divida a quantidade restante d e pontos pela prod utividade 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 repr ioritized? [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 nece ssidade, especialmente se novas informações são ap rendidas. É esperado que o backlog do prod uto mude conforme a dinâmica dos negócios ou as necessidades dos clientes/usuários. É esperado qu e 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 co mo 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 p ró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 p lanning, sprint review e reunião diária, entre ou tros.

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 ara a resentar o roduto desenvolvido ara o roduct owner e ara ue 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 prod uto entregue. Uma reunião de sprint r eview sem feedback e aceitação do pr oduct 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, depend endo 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. T he team has just enough time to complete all tasks in the remaining 16 hours with the exception of three ta sks. Of these three tasks, two tasks (a total of 6 hour s) are required to complete one Product Backlog item and one task (a n estimate of 2 hours) is required to complete another Product Backlog item. How should the Development Team handle the remaining three tasks? [Código de referência: 3863]

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 inacabado s em relação aos no vos 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 q ue o outro item que só tem 2 horas d e duração estimada seria feita em hora extra. Considerando qu e a equipe deve trabalhar em um ritmo sustentável, 1 hora extra por dia não seria tão difícil.


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 sp rint é 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 re stantes não é ilustrado em um gráfico burndown da sprint. O objetivo principal do gráfico burndown da sprint é ilustrar o trabalho restan te durante uma sprint. O gráfico reflete, para cada dia finalizado na Sprint, uma estimativa de quanto trabalho resta até qu e 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 burn down exibe o trabalho p lanejado em relação ao trab alho 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 sprin s print, t, a equ equipe ipe de des desenv envolvimen olvimento to ent entreg rega a um u m incremen incr emento to de sof software tware pro pronto nto e potencialmente utiliz utilizável e que PODE ser implantando (shippable). Ainda que apó apóss a spr sprint int o soft s oftware ware poss p ossa a ser s er implan implantad tado o e dist distribu ribuído ído aos clien clientes tes,, isso iss o nem n em sempre se mpre é feito porque para alguns clientes e tipos de negó cio uma atualização atualização de softw software are no ambiente de produção muito frequente (por exemplo: exemplo: 2 vezes por mês se considerar mos sprints com duração de 2 semanas) pode gerar r iscos para a organização. Atualizar Atua lizar um u m software sof tware em produ pr odução ção sempr sempre e gera g era risc riscos, os, esp especia ecialment lmente e para p ara gra grande ndess orga o rganizaçõe nizações. s. Quem decide se o incremento gerado na sp rint será liberado em uma nova versão para os clientes é o product produ ct owner. owner.

maximum amount amount of tim time e a Sprint Retrospective should take? [Código de 42) What is the maximum 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 Proporcionalmente um tempo menor é alocado para sprints menores.

commited itens (requirements) are not completed at the end of the 43) What happ ens when all commited Sprint? [Código de referência: 3869]

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 finaliz ados de acord o com a definição de "pronto" devem voltar para o ba cklog do produto. O p roduct owner deve priorizar priorizar novamente estes itens, juntamente com os itens que já estavam no b acklog do produto. Se fore m novamente priorizados, priorizados, podem entrar na próxima 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, company, which which has five major products, is using Scrum for product

development. Which statements are the two best alternatives for how many many Product Owners should

ex s

g o e re er nc a :

A) One and only one: on e: the Product Ow Owner ner may not delegate t o 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 communicate expectations and requirements to the Development Teams Teams JUSTIFICATIVA: Para cada backlog de pr oduto deve existir somente somente uma pessoa que assuma o pap el de product owner.. A mesma pessoa pode ser product owner de mais de um produto: não há problema nisto se owner ela conseguir desempenhar bem suas responsabilidades. Além disto, o scrum guide diz que o product owner pode realizar realizar suas responsabilidades ou delega-las par a a equipe equ ipe 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 con hecimento sobre o idioma inglês. Muitos Muitos não tra duzem corretamente as questõe s e tem entendimento errado. Esta é uma questão que g eralmente alguns traduzem traduzem "management" "management" como "gerente" e está errado ". A tradução correta desta questão é: "O Scrum Master é uma posição gerencial?" A respo re sposta sta é SIM, porém po rém é uma posiç p osição ão de ger gerenc enciamen iamento to de PROC PROCESSO ESSO e não de pes pessoa soas. s. O Scrum Master Master gerencia o processo Scrum. O Scrum Master não exerce chefia sobre o tim time e de desenvolvimento ou sobre o dono do produto.

46) Who is on the Scrum Team? Team? (choose 3 answers)


A) Project manager B) Project owner C) Product owner owner D) Development team E) Manager F) CEO G) Scrum master master JUSTIFICATIVA: A equipe eq uipe scr scrum um é for formada mada por trê trêss papé p apéis: is: equ equipe ipe de des desenv envolvimen olvimento, to, scr scrum um master mas ter e prod p roduct uct

.

Team? [Código de referência: 3873] 47) What is the recommended size for a De velopment Team?

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 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 o wner não en tram nesta contagem).

Scrum? [Código de referência: 3874] 48) Who is required to attend the Daily Scrum?

A) The Scrum Master Master B) The Development Team Team C) The T he Development Team and the Product Owner D) The T he Development Team and the Scrum Master JUSTIFICATIVA: Apenas Apen as as pes pessoa soass que q ue fazem o tra trabalh balho o desc d escrita rita no Back Backlog log da Sprin Sprintt prec p recisam isam part p articipa iciparr da da reunião Diária do Scrum. Se o Scrum Master ou Product O wner também estão na eq uipe 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 simplesmente gar antir que a Equipe de Desenvolvim Desenvolvimento ento saiba como conduzir conduzir uma Reunião Diária. Nada impede impede que qualquer compareça nessa reunião como ouvinte, afinal o Scrum prega a tran sparência. Entretanto, somente membros membros da Equipe de Desen volvendo 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 answer is correct? [Código de referência: 3875]

A) Discuss with the Product Ow Owner ner B) Start doing retrospectives C) None of the above JUSTIFICATIVA: Esta é uma pegadinha. Veja Veja que se trata de uma equipe nova. Se for nova, provavelmente ainda não começaram a fazer fazer todas as prá ticas do scrum, e se estão querendo deix deixar ar de fazer algo é porque não estão vend o valor na prática. Logo, começar a fa zer a reunião de retrospectiva é a melhor maneira de entender o valor qu e isso traz para a equipe. E realizar realizar a reunião d e retrospectiva não é opcional no scrum: é obrigatório.

mainteined by: [Código de referência: 3876] 50) The Product Backlog is mainteined

A) The Scrum Master B) The Development Team 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 D) None of the above JUSTIFICATIVA: Scrum é um framework no qual pessoas pod em 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 q ue faz mais sentido para otimizar o valor do tra balho que está send o feito pelo time de d esenvolvimento.

53) Who has the a uthority to cancel a Sprint? [Código de referência: 3879]

A) The team members B) The Scrum Master C) The Product Owner D) The project manager JUSTIFICATIVA: Somente o produtc owner tem autoridade par a cancelar uma sprint. Ele faz isso quando a sp rint 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]

A) The Product Owner B) The Development Team in agreement with the Product Owner C) The Scrum Master D) The stakeholders JUSTIFICATIVA: Na parte 1 d a reunião de planejamento da sprint, a equ ipe 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 prod uto 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 prod uto. Assim, o backlog da sprint é um subconjunto do backlog do produto.

56) As the Sprint Planning progresses, the workload has grown beyond the De velopment 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 e quipe de desenvolvimento identifica que se comprometeu com uma quantidade de itens maior que sua capacidade de pro dução ou que terá tempo disponível para produzir mais itens do que os selecionados para a spr int, 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 se r 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

ncremen s rom a o er crum eams on e n a ve; e sum o a o ncremen s s e ncremen 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 happ ens 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 traba lho estiver potencialmente utilizável, tipicamente o product o wner o aceita. Todos os itens de backlog do produto incompletos são reavaliados e colocados de volta no b acklog do produto. O trabalho feito deprecia-se rapidamente e deve ser frequentemente reavaliado.

59) What is the release burndo wn? [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 bu rndown 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 prefere ncial 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]

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 d esenvolvimento auto-organ izada tenha au tonomia 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 eq uipe de desenvolvimento reporte o progr esso 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 re união de planejamento da Sprint para que a equipe selecione os itens que vão ser de senvolvidos 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 o r 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 u m ú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 eq uipes 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 e ntregar um único produto, é absolutamente necessário integrar o traba lho 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 du ring 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 q ualquer impedimento encon trado pela equipe de desenvolvimento e que afete o seu trabalho.

65) Which three o f 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 B) The Product Owner C) The Development Team 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 cap az e ter habilidades para fazer tudo que precisa ser feito.

69) Who deter mines when it is appropriate to u pdate the Sprint Backlog during a Sprint?


A) The project manager B) The Scrum Team C) The Development 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 n egociar junto a equipe de de senvolvimento 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 e quipe de desenvolvimento, contém as tarefas e todos os detalhes p ara cumprir os itens selecionados para Sprint. Somente a equ ipe 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?


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 d e acordo com a definição de "pronto" a cordada. Ao final da sprint, a equipe de desenvolvimento entrega na verdade u m incremento de software pronto e potencialmente utilizável (software rodando). Ela não precisa entregar todo o so ftware pronto , até porque isso ser ia praticamente impossível, mas o incremento, ou seja, a no va parte d o 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 curr ent 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 stakeh olders (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 p roduto (se nece ssá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 respo nsá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 prod uto, mas a equipe d e desenvolvimento é auto-orga nizada 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 " "

ever; a pr n ac og ems are owne y e en re eve opmen each one may be done by an individual team member D) At the Sprint Planning meeting

eam, even oug

JUSTIFICATIVA: Essa é uma pergunta pegadinha. Veja que a pergun ta afirma que cada membro da equipe de desenvolvimento voluntariamente escolhe de qua is tarefas será o "dono". Para o scrum, todos os membros da equipe de desenvolvimento são respo nsáveis por todas as tare fas, 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 e ntregará 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 o u 4 semanas. Esta reunião geralmente acontece em pé (afinal, são somente 15 minutos) e de prefe rê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 d esenvolvimento. Dentre todas as suas atribuições, remover impedimentos e fa cilitar (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 Retrospe ctive? [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 retrosp ectiva 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:

segun a par e a reun o e p ane amen o a spr n se n c a ogo ap s o rm no a pr me ra. 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 pote ncialmente utilizável são chamados de backlog da sprint. O b acklog 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, an d

be able to explain the alternatives most clearly? [Código de referência: 3906]

A) The Product Owner B) The Scrum Master C) The project manager 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 e mpresa quiser saber como está o andamento geral do projeto de de senvolvimento, deve pro curar o produ ct 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 noss os cursos não pode s er redistribuído de qualquer forma ou por qualquer meio. Somente o aluno devidamente inscrito nos cursos poderá fazer uso dos noss os materiais. Se você identificar que alguém está us ando indevidamente o conteúdo dos nossos cursos, ou distribuindo-o ilegalmente, por favor avise-nos imediatamente através do e-mail [email protected]. 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


Log off

Menu




ENCERRAR

Seu resultado neste Simulado : Total de questões:80 Questões que você respondeu:80 Tipo de questões:Múltipla escolha podendo mais de opção a

ser marcada como correta.


min






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 o f process contro l is Scrum based? [Código de referência: 4047]

A) Hybrid B) Defined C) Complex D) Empirical JUSTIFICATIVA: Scrum não é um processo p revisível. É um processo empírico, ou seja, usa a experiência da equ ipe e da experimentação para r esolver 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 limita do 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 Retrospe ctive 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 sp rints menores.

5) Who must conform to the definition of done? [Código de referência: 4051]

A) The Product Owner B) The Development Team C) The Scrum Team D) The QA department JUSTIFICATIVA: Quando o item do backlog do pr oduto ou um incremento é descrito como “pronto”, todos de vem entender o que “pron to” significa. Embora isso varie significativamente em cada e quipe scrum, os integrantes devem ter um entend imento 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 equ ipe 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

.

7) When sho uld 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 de ve 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 a pós o término de cad a 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 d e 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 C) Cancel the Sprint 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 tr ocar itens com prioridade menor em acordo com o product owner. Também seria aceito que a equipe informasse ao produ ct 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 e xtras (o scrum é totalmente contra isto) - Recrutar mais membros para a Sprint (isto atrapalharia o ritmo de desen volvimento)

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 p roduct owner, equipe de desenvolvimento e scrum master.

12) What is the best term to define the function of th e 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 ga rantindo a ade sã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 def inition 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 s rint termina uando o limite de tem o time-box ex ira. A s rint é um evento com tem o limitado

. e deve ser en cerrada quand o 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 repre sentado o esforço total da Sprint que pode se em pontos de história ou em horas. Nada impede de considerar as horas d as 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 ne m "cada membro" e sim o tempo para completar todas as tarefas ou itens selecionados. Se você tem o tempo requerido para completar cada tarefa qu e vai ser executada por cada membro, então você tem o tempo total. Então, não há nada de errado nesta qu estão. Ela está desta forma justamente para confundir o candidato.

15) The Sprint Goal is a result of th e Sprint Planning, as is the Sprint Backlog. [Código de

referência: 4061]

A) True B) False JUSTIFICATIVA: Durante a par te 1 da reun ião de planejamento da Sprint, a equipe de desenvolvimento prevê os itens de backlog do pro duto que irá entreg ar na sprint e a e quipe 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 ab le to finish the complete forecast,

who has to be pre sent when reviewing and adjusting the Sprint work selected? [Código de referência: 4062]

A) The Product Owner and the Development Team B) 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 Do no 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 h eld? [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 d e 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 dura nte 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 B) The Product Owner C) The stakeholders D) The Development Team

JUSTIFICATIVA: A equipe de desenvolvimento é responsável por todas as estimativas. O product owner pode influenciar a equipe, ajudando no enten dimento e nas decisões conflituosas de troca, mas os desenvolvedores que irão realizar o trabalho são resp onsá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 orga nização para organizar e gerenciar seu próp rio trabalho. Eles devem ser incentivados a resolver por conta própr ia seus conflitos internos. Reportar a pr odutividade não é uma responsabilidade, uma vez que isto ocorre na turalmente por conta da transpa rência. Não é necessário ger ar 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 prod uct 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 eq uipe 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 ante s o que for mais fácil tecnicamente (deve-se fazer o que g erar mais valor para o negócio)

23) Who must do a ll the work to make sure Product Backlog items conform to the definition of

“done?” [Código de referência: 4069]

A) The Scrum Master B) The Development Team C) The Product Owner 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 d efinition of “Do ne”?


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 "don e"? [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 "pro nto" 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 for ma 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 e xternas 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 D) The Product Owner JUSTIFICATIVA: Somente product owner tem autoridade para cancelar a sprint, embora e le possa fazer isso sob influência das partes interessadas, da equipe d e desenvolvimento ou do scru m 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 eve nto deve ser proporcionalmente menor. Por exemplo: uma sprint de duas semanas terá uma reunião de planejamento de 4 h oras.

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 fren te 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 eq uipes precisam ter pro duzido um "incremento de produto potencialmente entregável." No entanto, "potencialmente entregável" e "entr egável" não são a mesma coisa. A definição de "pronto" para u ma sprint pode não ser a mesma definição de "pronto" para uma liberação. Alguns projetos gr andes 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 o u 2 sprints de release). Projetos menores talvez não precisem de sprints de release. Nas sprints de release ocorr e 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 ara o usuário elaborar material de treinamento e treinar os usuários entre outras

atividades. Apesar de sprints de release não serem consideradas eventos oficiais dentro do framework scrum, todas estas atividades abordadas a nteriormente 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 se rem descritas no framework, elas podem ser usadas. No entanto, não se pod e afirmar que uma ou mais sprints de release sejam necessárias para que se ten ha 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 unde rstanding about the h ighest order of Product Backlog items. Because of this, the Development Team couldn´t figure o ut how much functionality it could forecast for the upcoming Sprint. They were able to ag ree 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 b acklog da sprint ficará congelado: este backlog pode mudar, tanto para incluir mais detalhes para desenvolver o que foi selecionado inicialmente na reunião d e 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 d iscutido 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 " ronto".

.

32) Which statement is an incorrect a ssessment 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 é p equena o suficiente para se r ágil e grande o suficiente para completar o trabalho q ue deve ser feito. Tipicamente, uma equipe pode variar entre 3 a 9 participantes (o scrum master e o produ ct 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 u m incremento de so ftware 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, o u 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?


ac tas s est mate n ours 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 de stes itens é criado. Isto forma o que é chamado de backlog da sprint. Uma vez criado o backlog da sprint, este pertencerá exclusivamente à equipe de desenvo lvimento. Somente ela poderá planejar o desenvolvimento dos itens selecionados. É preciso considerar que nem sempre o backlog da sprint sairá totalmente detalhado da r euniã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 te am´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 C) Cancel the Sprint 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 o wner. Só a equipe de desen volvimento pode sabe r o quanto e la 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 s rint não faz muito sentido nesta situa ão. Trabalhar em horas extras não é al o

defendido pelo scrum. E recrutar membros para uma sprint é pode atrapalhar o ritmo da equipe.

38) What does it mean to say that a n 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 qua ntidade limitada de tempo. Muitos candidatos erram esta qu estão porque não souber am 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 te rminar 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, selforganization, 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 é traba lhar 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 ge rência deve apoiar o scru m master na remoção de impedimentos da equipe de d esenvolvimento. 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 produ ct 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 de ve estar ciente do pessoa l 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 é a utogerenciável de forma que a decisão de remover alguém da equipe deve se r 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-co mmitted itself for a Sprint, who has

to be pr esent 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 B) 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 pro duto é tra nsformado em incremento em forma de um ou mais itens do backlog da sprint. Se a equipe d e desenvolvimento assumiu um compromisso durante a reu niã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 qu alidade. Por esta razão, ao rever ou ajustar o traba lho da sprint, tanto o product owner quanto a equ ipe de desenvolvimento devem estar presentes. Quanto às outra s alternativas: gerente de pro jeto não é um papel no scrum. A equipe de desenvolvimento é autogerida e decide como transformar um item de backlog do prod uto em um incremento de trabalho. A definição dos itens do backlog do prod uto 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 respon sible for updating the work estimates during a Sprint? [Código de referência:

4088]

A) The Scrum Master B) The Development Team C) The Product Owner 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 d esenvolvimento também fica encarregada d e atualizar o backlog da sprint, que contém estimativas de trabalho e a lista de tarefas a serem executadas durante a sprint.


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 acord o com a definição de "pr onto". A equipe de desenvolvimento não pode selecionar os itens do ba cklog 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 scru m - Não pode ser simplesmente o que puder ser acomodado n a sprint, pois o que for d esenvolvido 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 pr oduct owner pode representar o desejo de um comitê no backlog do produto, mas aqueles que quiserem uma alteração nas pr ioridades 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 pr oduct owner. Então, neste caso, o CEO deve conven cer o product o wner sobre a adição de um item na sprint.

45) A product Increment must be released to production at the end of ea ch Sprint. [Código de

referência: 4091]

A) False B) True JUSTIFICATIVA: O incremento precisa ser e ntregue poten cialmente utilizável, mas não necessariamente deve ser liberado em produção no final de cada spr int. Esta é uma decisão que cabe somente ao dono d o 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 acor do com a definição de "pronto". A equipe de dese nvolvimento nunca irá dese nvolver 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 e stá sujeito a alterações. E a equipe de desen volvimento implanta apenas a arquitetura e a infraestrutur a 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 equ ipe 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 autoge renciamento. Neste sentido, cabe a ele ou vir 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 propor cionalmente. Por exemplo, para u ma sprint de duas semanas o limite é de 4 h oras e para uma sprint de uma semana é de 2 horas.

49) It is important that the product increment be released to prod uction 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 d esenvolvimento vai entrega r incrementos de funcionalidades potencialmente utilizáveis em conformidade com a d efinição de "pronto " acordada entre a equipe scru m 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 é d o 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 d eterminar 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 "ge rente 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 en tregam 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 traba lho que fazia um típico gerente de pr ojetos no modelo tradicional passa agora a ser assumido pelo product o wner.

52) Who has the last say on the order of the Product Backlog? [Código de referência: 4098]

A) The CEO B) The Development Team C) The stakeholders D) The Product Owner E) The Scrum Master JUSTIFICATIVA: O product owner é responsável pelo backlog do produto, incluindo seu conteúdo, disponibilidade e ordenação. O product owner pode fazer todo o trabalho de gerenciamento do backlog do produto ou pode delegar pa ra 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 organ izar os itens no backlog do prod uto 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 RO I.

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 r equisitos não funcionais. Normalmente os re quisitos não funcionais são adicionados à definição de "Pronto" porque se aplicam a todos os req uisitos 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 (T CO) do trabalho qu e a equipe de d esenvolvimento faz. Gerenciar o projeto não seria a principal responsabilidade do product owner, apesar de ele assumir

, 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 B) The Product Owner C) The Development Team D) The Project Manager E) None of the above JUSTIFICATIVA: O scrum master, o product owner e a eq uipe de desenvo lvimento 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 considerado s parte da eq uipe 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 on ly 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 qu e seja tarde demais. É importante considerar que uma equipe de desenvo lvimento não ope ra 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 trab alhar. Consultar a equipe de d esenvolvimento se encaixa no conceito de inspeção e adapta ção. Conversar

raiz, se existir. Priorizar a lista de impedimentos pode ser u ma 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 dese nvolvimento e outras entidades envolvidas pode ajudar a re solvê-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 e le esteja, mas isto não é ob rigatório.

60) Scrum Master is a “management” po sition. [Código de referência: 4106]

A) True B) False JUSTIFICATIVA: Esta é uma das que stõ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 pr ocesso de scrum. O scrum master nunca gerencia a equipe de desenvolvimento que é, por definição, uma equipe autogerenciada. O scru m 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 reu nião de revisão da sprint, a eq uipe 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 eq uipe de desenvolvimento, mas isso é apenas par te 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 sp rint em termos de incrementos de funcionalidade. Nenhuma congratulação ou pu nição acontece na reun iã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 d e sprint para uma sprint mensal é de 4 h oras. Se a duração da sp rint selecionada é menos de um mês, então uma reunião mais curta para re visã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 do Scrum. Se o Scrum Master ou Product O wner também estão na eq uipe 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 gar antir 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 tran sparência. Entretando, somente membros da Equipe de Desenvolvendo participam ativamente.

64) Why is the Da ily 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:

, que também remove a complexidade e a so brecarga deste e vento, consequentemente melhorando a experiência de desenvolvimento e sincronização da equipe. Mudar constantemente a data e o h orário do scrum diário pode induzir frustração nas p essoas, 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 retrosp ective), teste de liberação (release testing), sprint 0 e teste de spr int (sprint testing) não sã o eventos o ficiais descritos no scru m como tendo limites de tempo. Isto não significa que estes eventos não possam existir, mas que eles não são padron izados 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 qu e usam a primeira sprint com o intuito de fazer planejamento e definições de infraestrutura e arq uitetura 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 Develo ment Team self-mana es and is the onl mana ement re uired at the Dail Scrum

D) The Scrum Master speaks on their behalf JUSTIFICATIVA: O scrum master aplica a regra de que ape nas os membros da equipe de desenvolvimento devem participar do scrum diário. O scrum diário não é u ma reunião de status: é apenas para as pessoas que transformam os itens do backlog do prod uto em um incremento. Não há necessidade de qualquer gerê ncia externa na reun ião diária. O trabalho que terá d e 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 p roduct owner. Assim, esta reunião é ape nas para a equ ipe 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 se rá entregue co mo resultado do incremento da próxima sprint? 2) Como o trabalho necessário para entregar o incremento será re alizado?

69) When multiple teams are working together, each tea m should maintain a separate Product

Backlog. [Código de referência: 4115]

A) True B) False JUSTIFICATIVA: Se a empresa tiver 20 desenvolvedores trab alhando 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 pro duct, 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

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 qu e 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 the y 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 traba lho 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 u m 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 pa ra assegurar q uando o trab alho 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]

A) The Development Team B) The Scrum Master C) The Scrum Team D) The Product Owner JUSTIFICATIVA: O backlog da sprint é uma imagem em tempo real do trabalho que a equipe de desenvolvimento planeja completar durante a Sprint, e pertence e xclusivamente a e la.

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á atrapalhand o e pedir para q ue 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 qu al o Scrum Master precisará auxiliar a equipe. O Scrum Master pode conversar com o g erente de desenvolvimento para realocar o membro que está criando conflito para outra equipe ou outro trabalho. O Scrum Master não pod e chegar a co nclusão sozinho de remoção de um membro de equipe, porque ele não faz a gestão de equipe. O Product O wner também não interfere na estrutura da equipe. O gerente funcional nã o é descrito n o 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 e quipe.

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) 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 ba nco de dados, uma para back-end, etc.) n ão é uma boa opção porque estas eq uipes 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 d ividir 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 respo stas disponíveis.

77) The Scrum Master should not allow the Product Owner to go to the Sprint Planning meeting

without having already de vised 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 d esenvolvimento trabalhar no incremento. Portanto, a meta da sprint é definida DURANTE a reunião de planejamento da sprint envolvendo a equipe de desen volvimento e o prod uct 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 u ma 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 a s 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 aprend e sobre o prod uto e seus clientes. Por isto que a resposta correta é a "It is allowed to grow and change as more is learned about the pro duct 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 de sign (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 ba cklog 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 respon sible 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.


SOBRE NÓS

Depoimentos de alunos Blog Quem somos Perguntas frequentes Fale conosco





Log off

Menu




ENCERRAR



Respostas corretas para ser aprovado:68(85%) Respostas que você ace rtou:72(90%) Tempo para completar o teste:60

min






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 ra zã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 pro duto, em menos de 1 mês pode não ser p ossível liberar um "pr oduto" 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 tr abalho é 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:

(choose 2 answers) [Código de referência: 5195]

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 r emover impedimentos e é um defensor do scrum, observando se a equipe está seguindo suas regras. Desta forma, seria errado o scrum master atribuir tarefas à eq uipe já que ela deve ser au to-organizada. O product owner não precisa participar de todos os even tos. O scrum master procura ajudar a resolver alguns co nflitos 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 r emove 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 ba cklog 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 reu nião da sprint. É importante que na re união de planejamento da sp rint exista pelo menos um planejamento inicial para o trabalho do s primeiros dias. É verdadeiro afirmar que conforme é feito a decomposição dos itens selecionados o backlog da sprint pode crescer (e le vai conter mais tarefas). É verdadeiro afirmar que o time de desenvolvimento pode trabalhar com o dono do p roduto 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 o s itens) quando o time de desenvolvimento solicitar ajuda.

4) The Product O wner remains distant. He/she has hande d over the req uired Product Backlog for

the Sprint but is not collaborating with the Development Team during the Sprint. What are valuable actions for a Scrum Master? (choose 2 answers) [Código de referência: 5197]

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) (SM) é responsável por garantir que o scru m seja entendido e aplicado. O scrum master faz isso para garantir que a equipe adere à teoria, às práticas e às regr as do scrum. Desta forma, o SM pode ensinar o product owner a aderir às práticas do scru m. Como Como a retrospectiva da sprint tem como propósito inspecionar como a última sprint foi em relação a pessoas, r elaçõ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 r euniã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 próxima sprint. Além disto, disto, o guia e stabelece que a equipe de d esenvolvim esenvolvimento ento modifica o backlog da spr int ao longo de toda a sprint de acordo com o andamento do trabalho. Então, nem tudo precisa ser detalhado na reun ião de planejamento da sprint.

6) Which statement best describes the Sprint Backlog as an o utcome of the Sprint Planning?


A) It is a task list where every Development Team Team member member has signed up u p 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, juntamen junt amente te com o plan plano o de d e entr e ntrega ega do incr incremen emento to do pro produt duto o e o alcan a lcance ce do obje objetivo tivo da spr sprint. int. O backlog da sprint pode ser composto de tarefas que for am identificadas identificadas a partir dos itens do backlog do produto que precisam ser desenvolvidos.

self-organizing? [Código de referência: 5200] 7) Which two behaviors de monstrate that a team is self-organizing?

A) Development team members members collaboratively collabor atively select their own 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 T he Development Team members members work within within the boundaries b oundaries of o f their functional description descr iption and nicely hand off work from analyst to developer to tester to integration E) The Development Team Team invites external external people pe ople to the t he 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 q ue a equipe eq uipe de desenvolvimento planeja completar completar durante a sprint, e p ertence exclusivamente exclusivamente a ela. Sendo assim, a equipe deve ter cap acidade de criar e gere nciar o backlog da sprint. E durante a sprint os membros membros da equipe d e desenvolvimento podem de forma colaborativa escolher em quais tare fas 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 f inal da Reu Reunião nião de Plane Planejamen jamento to da Sprin Sprint, t, espe e sperara-se se ter uma meta me ta de spr sprint int est estabe abelecid lecida a e um backlog de sprint inicial.

9) The IT manager asks a Development Team for a status repor t describing the progress

throughout th e Sprint. The Development Team Team asks the Scrum Master for advice. T he 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. the mselves. C) Talk to the IT manager and an d explain that progr ess 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 Development Team to fit the r eport into the Sprint Backlog. JUSTIFICATIVA: Se os radiadores de informação, como Quadro Kanba n e Gráfico Grá fico Burndown Burndown estivessem disponíveis, o gerente de T I poderia obter o status da Sprint olhando diretamente neles.

Durante a Sprint Review, 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 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 mem bros da equipe po dem levar à redução de pr odutividade.

11) Who has the last say on the order of the Product Backlog? [Código de referência: 5204]

A) The Development Team Team B) The CEO C) The T he Scrum Master Master D) The Product Owner E) The stakeholders JUSTIFICATIVA: O product owner é responsável pelo backlog do produto, incluindo seu conteúdo, disponibilidade e ordenação. Portanto, a últim última a palavra é a d ele.

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 member roles r oles will will be B) How conditions have changed and an d 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 d uas par partes tes da reu reunião nião de pla planeja nejamento mento da spr sprint int res respon pondem dem às seg seguint uintes es que questõ stões, es, respectivamente: - O que ser á entregue como resultado do incremento da próxima próxima sprint? - Como o trabalho necessário para entregar o incremento será r ealiz ealizado? ado?

following is the Development Team Team NOT NOT responsible for? [Código de referência: 13) Which of the following 5206]

A) Selecting the Product Ow Owner ner 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 equ ipe scrum, pelo cliente cliente ou pela ger ência sênior. Não Não existe exi ste uma formalização formalização no scrum guide sobre quem deve de signar 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 pode m ter habilidades especializadas e área de especialização, mas a respon sabilidade 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 é a firmado no Scrum guide.

15) What are some consequences if a Development Team does not h ave a consistent d efinition

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”, to dos devem entender o que “pron to” significa. Embora isso varie significativamente de um extremo ao outro para cada equipe scrum, os integrantes devem ter um entendimento compartilhado do qu e significa o trabalho estar completo, assegurando a transp arê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 "pro nto" na revisão da sprint e a equipe de desenvolvimento não saberá identificar as atividades necessárias para co mpletar 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 pa ra 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 enten dimento 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 fraca sso 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, é esper ado que a sua definição de “pronto” seja expandida para incluir critérios mais rigorosos d e alta qu alidade.

20) The CEO asks the Development Team to add a "very important" item to the curr ent 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 q ue coloquem em risco a meta da sprint e nenhuma mudança pode ser fo rç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 scru m seja entendido e aplicado. Seu foco é no uso do scru m e no apoio à equipe scrum. O SM garante que os even tos do scrum sejam realizados - mas ele não é responsável pela rea lização deles, como por exemplo pela reunião diária. O SM não gerencia alocação de recu rsos e nem o desempenho da eq uipe 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 toda s as tarefas do backlog da sprint, ainda que cada tare fa 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 respon sible for registering the work estimates during a Sprint? [Código de referência:

5216]

B) The Scrum Master C) The Product Owner D) The Development Team JUSTIFICATIVA: A equipe de desenvolvimento é responsável por todas as estimativas.

24) If burndown charts ar e 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 fu rther decomposition of work added to th e 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 sp rint. Sempre que um novo trab alho é necessário, a equipe de desenvolvimento o adiciona ao backlog da sprint. Não é necessário esperar nenhum evento ocor rer para isto.

26) What are two good ways for a Scrum Team to ensure tha t security concerns a re 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 securityrelated Product Backlog items E) Add security concerns to the definition of "Done" JUSTIFICATIVA: Considerando que a s 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 se guranç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 pr oduct backlog que faz mais sentido para o timizar o valor do trabalho que está se ndo feito pela equipe de dese nvolvimento.

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 d ia de um sprint, a equipe realiza uma reunião diária chamada "Daily Scrum". As reuniões normalmente são rea lizadas no mesmo local e ao mesmo tempo todos os dias. Idealmente, a reunião Daily Scrum é realizada no manhã, pois ajuda a de finir o contexto para o próximo dia de trabalho. Essas reu niõ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 ar e key for a Scrum Master to teach teams to he lp them self-organize. [Código de referência: 5222]

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ár ios 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 se r potencialmente

utilizável, preparado para ser utilizado. Cabe ao dono do produto dizer quand o 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 estenda m além do prazo, que se perca controle sobr e 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 todo s os participantes. E o Scrum Master tem que incentivar o time a cumprir os tempos fechados, pa ra que o time se auto-organize para fazer o melhor dentro de u m 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 à d efinição de “pronto” da e quipe scrum - independente de o product owner decidir liberá-lo realmente.

31) During the Da ily 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 p articipação do scrum master na reunião diária não é obrigatória. De acord o com o scrum guide, o scrum master assegura q ue a equipe de desenvolvimento faça a reunião - mas a equipe é responsáve l pela sua condução. Desta forma, qualquer membro da equipe de desenvolvimento pode facilitar as discussões na reun ião. Além disto, há o princípio de equipe au toorganizada. Outra coisa que o guia declara é qu e o scrum master deve ensinar a equipe de desenvolvimento a manter a reunião d iá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

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 de ve garantir que esta reunião seja realizada.

33) Which of the following are true abo ut the length of the Sprint? (Choo se 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: Uma nova sprint inicia imediatamente após a conclusão da sprint anterior.

35) A Scrum Master is introducing Scrum to a new Development Team. The Development Team

has decided that a r etrospective is unnecessary. What action should the Scrum Master take? [Código de referência: 5228]

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 d esenvolvimento está considerando esta reu nião desnecessária. O SM precisa ensinar como realizar esta reunião e obter benefícios com ela.

36) What is the purpose o f a Scrum of Scrums? [Código de referência: 5229]

A Ali n Product Backlo s of related roducts b brin in their Product Owners to ether

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á fre quentar a reunião scrum of scrums para coordenar o tra balho de múltiplas equipes scrum. O foco desta reu niã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 par ticipar 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 desen volvimento auto-org anizadas, o correto é deixar que elas decidam como querem se organizar dentro de uma nova estrutura, envolvendo tod os os seus membros nesta auto-orga nização.

38) At the end of a Sprint a Product Backlog item worked on during th e 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 for am concluídos em um sprint devem ser devolvidos ao Backlog do produto para re-priorização pelo Dono do Produto. Portanto, fa z 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 pro duto ocorre na revisão da sprint. E o surgimento do backlog da sprint ocorre na reunião de p lanejamento 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 entreg ar algum incremento potencialmente utilizável, não importa o tamanho deste incremento. Itens de arquitetura e infraestrutura podem ser construidos aos p oucos juntamente com as funcionalidades que serão desenvolvidas na sprint.

41) Who is respon sible for tracking the re maining work of the Sprint? [Código de referência:

5234]

A) The Development Team B) The Development Team in consultation with the Product Owner C) The project manager 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 C) Minimal 7 D) 3 to 9 JUSTIFICATIVA: O tamanho ideal da equipe de dese nvolvimento deve ser p equeno 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 coor denaçã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 D) The Development Team JUSTIFICATIVA: Como a meta da sprint pod e 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 pur pose 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 en d of each

Sprint. [Código de referência: 5551]

A) True B) False JUSTIFICATIVA: O incremento de pro duto 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 p ara uma sprint de um mês. Proporcionalmente um tempo menor é alocado pa ra sprints menores. Por exemplo, uma sprint de d uas 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 n a teoria de controle de pr ocessos 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 pro cessos empíricos: transparência, inspeção e adaptação.

49) Who has the final say on th e order of the Product Backlog? [Código de referência: 5554]

B) The Product Owner C) The Development Team D) The CEO E) The stakeholders JUSTIFICATIVA: O product owner é responsável pelo backlog do produto, incluindo seu conteúdo, disponibilidade e ordenação. Então, a última palavra é a dele.

50) During a Sprint Retrosp ective, 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 sere m aplicadas na próxima sprint. O scru m 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 ge rente de pro jeto 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 capa cidade de ser auto-organizar. O scrum master precisa ensinar a -

. horários, locais da reun ião diária. Se a equipe pe dir 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]

A) The Product Owner B) The Scrum Master C) The business analyst who represents the Product Owner in the Development Team D) The stakeholders JUSTIFICATIVA: Cabe ao prod uct owner expressar claramente os itens do backlog do p roduto.

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 qu e o usuário possa usar. Das opções disponíveis, somente funcionalidades adicionais em um estado utilizável seria compatível com esta de finiçã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 pr oduto são decompostos em atividades ou histórias de usuários para facilitar o desenvolvimento deste destes itens durante a sprint. No backlog do prod uto, 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?

(Choose 4 answers) [Código de referência: 5561]

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 trab alho realizado pela pessoa . Não há exceções para esta regra. Então, não e xiste o papel de testador e espera-se que todos na equipe d e 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 sobr e 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]

A) The Development Team B) The Team Manager C) The Project Manager

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 estabe lecer a meta de spr int para a próxima sprint.

60) Which of the following are true abo ut the Product Owner role? (Choose 3 an swers) [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 pr oduct owner tem a responsabilidade na ordenação dos itens do backlog do produto para melhor alcançar metas e missões. O product o wner é uma pessoa e n ão um comitê. O product owner pode representar o d esejo de um comitê no backlog do p roduto, 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 qua lity 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 deter mines how work is performed during the Sprint? [Código de referência: 5568]

A) Development team managers B) Subject matter experts C) The Development Team D) Architects E) The Scrum Master

JUSTIFICATIVA: O scrum guide estabelece que tendo selecionado o trabalho da sprint, a e quipe de desenvolvimento decide como irá construir essas fu ncionalidades e transformá-las em um incremento “pron to”.

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 prod uct owner tem a autoridade para cancelar uma sprint, embora ele possa fazer isso sob influência das partes interessada s, da equipe de de senvolvimento 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 p roduct owner e atender a vár ias equipes scrum.

66) Which technique is the LEAST productive way for the Scrum Master to ensure tha t 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 abou t 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 scru m. O scrum é fundamentado nas teorias empíricas de controle de processo, ou empirismo. O empirismo afirma que o conhecimento vem da experiência e d e tomada de decisões baseadas no que é conhecido.

68) The definition of “Done” is used to: (Choose 3 an swers) [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 pr oduto ou um incremento é descrito como “pronto”, todos de vem 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 dese nvolvimento no conhe cimento de quan tos 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 r equisitos 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 desenvo lvimento 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 ado pt Scrum, but management wants to cha nge 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 vocabu lá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 scru m podem ser perdidos. Sobre a ansiedade da g erência, isto varia em cada organ ização: há a s mais aderentes a mudanças r adicais, e usar a terminologia correta não deixaria a gerência ansiosa em relação à adoção correta do scrum. Como esta pergun ta não tem a opção de marcar mais de uma opção d e 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-or ganização da equ ipe de desenvolvimento. Dando a possibilidade para que a equipe possa de cidir como ele vai atuar, isto naturalmente aumenta o seu comprometimento e a sua responsa bilidade, dando chance para q ue 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 p roduto e do trabalho da equipe de de senvolvimento.

74) Why should the Product Owner be present a t 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 pa ra as pessoas que transformam os itens do backlog do prod uto 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.

75) Which statement best describes the Sprint Backlog as an outcome of the Sprint Planning?


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 de senvolvimento para a sprint em vez de uma lista completa de todo o tra balho 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 aco rdo com a importância e interesse das partes interessadas (stakeholders). Entretanto, o Dono do Produto não pode interferir na quan tidade de itens selecionados pela equipe de de senvolvimento para ser em desenvolvidos na Sprint. A equipe de desenvolvimento selecionará os itens na ord em 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. Con siderar 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 happ ens 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 dete ctada 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 r emover os itens que não p ossam 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 fa zer isso sob influência das partes interessadas, da equipe d e desenvolvimento ou do scru m master.

79) Which of the following is true abou t the Scrum Master role?


A) The Scrum Master teaches the Development Team to keep the scrum meetings to their timebox 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 à equ ipe de desenvolvimento.

80) Drawing a trend line through a release bur ndown 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


SOBRE NÓS Depoimentos de alunos Blog Quem somos Perguntas frequentes

Fale conosco





Log off

Menu




ENCERRAR

Seu resultado neste Simulado : Total de questões:80 Questões que você respondeu:80 Tipo de questões:Múltipla escolha podendo mais de opção a

ser marcada como correta.


min






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 scru m são time-boxed para forçar os participantes a focare m no propósito do evento e fazer o melhor possível dentro do tempo de terminado. 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 seu s 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 pr oduto para a equipe de desenvolvimento. Todos os problemas (impedimentos) que ocorrem durante a spr int devem ser levados para a reunião d e

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 O wner 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 a ntecessora. 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 d e 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 qu e 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 d e 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 reunião Diária do Scrum. Se o Scrum Master ou Product O wner também estão na eq uipe de

, . , Master tem que simplesmente gar antir que a Equipe de Desenvolvimento saiba como conduzir uma Reunião Diária. Nada impede que qualquer ou tra parte compareça nessa r eunião como ouvinte, afinal o Scrum prega a transparên cia. Entretanto, somente membros da Equipe de Desenvo lvendo 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 pod em possuir conhecimento técnico para atu ar 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 d o 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 ob servadores compartilharem um mesmo entendimento do que e stá sendo visto. Por exemplo:  Uma linguagem comum referindo-se ao processo deve ser co mpartilhada por todos os participantes; e,  Uma definição comum de “Pronto” deve ser compartilhada por aqu eles 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 é "F azer 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:

, tarefas, ainda que cad a 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 qua lity 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 é estabe lecido que os membros precisam estar de pé (stan d up) na

,

.

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 torn a obrigatório que sprints sejam iniciadas na mesma data. Além disto, se existir um único dono de pr oduto atendendo a estas múltiplas equipes teríamos um problema de logística, pois ele não conseguiria participar dos eventos a o 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 p or produto, independ ente da quan tidade de equipes que vão trabalhar n o desenvolvimento do mesmo produto. Partimos da premissa que sempre vai haver um único Dono de Produto po r 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 de ve ser pro porcionalmente menor. Por exemplo, uma sprint de duas semanas terá uma reunião de planejamento de sprint de quatro hora s.

c

wo

ngs are appropr a e or a crum

as er o o

e

eve opmen

eam oesn

have the engineering tools and infrastructure to completely finish each selected Product Backlog item? [Código de referência: 5790]

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 entre gar algum incremento potencialmente utilizável. Então o scrum master deve orientar a equipe par a que ela crie o que for possível com os recursos disponíveis dentro da d efinição de "pronto". O s requisitos desta definição pod em ser diminuídos nas sprints iniciais até que se tenham todas as ferramentas e infraestrutura estabelecidas. Mais tarde esta definição de "pro nto" pode ser melhorada.

16) The Daily Scrum is an event that happens ever y day. What would be three key con cerns 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 tr abalho desde a última reunião diária e prever o tra balho que deverá ser feito antes da próxima reunião diária. Portanto, esta reunião ser ve 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 desen volvimento usa a r eunião diária para avaliar o progresso em direção à meta da sprint e para avaliar se o progresso tend e a completar o trabalho do backlog da Sprint. Já a atualização do qua dro scrum pode ocorrer durante toda a Sprint e não precisa da reu nião diária para isto. No Scrum o Scrum Master não ger encia 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 chan e selected Product Backlo items

C) Cancel the Sprint 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 don o 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 d e 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 r euniã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


A) The Development Team B) The Product Owner C The ro ect mana er

D) The Scrum Master Master E) All of the above JUSTIFICATIVA: As equip e quipes es de des desenv envolvime olvimento nto são est estrut rutura uradas das e auto a utorizada rizadass pela p ela org organizaçã anização o para p ara org organizar anizar 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 follow following ing are roles o n a Scrum Team? Team? (Choose 3 answers) [Código de

referência: 5796]

A) Scrum master B) Users C) Development team D) Product owner owner E) Customers JUSTIFICATIVA: Usuários e clientes não tem papé is definidos no scrum. Eles existem, existem, são partes interessadas e interagem com o produ ct owner, owner, mas não têm papel definido no framew framework. ork.

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 zero é um termo não-oficial utiliz utilizado ado no quando se inicia uma uma nova equipe e quipe ou pro jeto. Habitualmente, algumas equipes scrum estabelecem uma sprint inicial para prepa rar o backlog de produto, organ iz izar ar o espaço d e trabalho da equ ipe com máquinas máquinas para o de senvolvim senvolvimento, ento, configurar as ferramentas de desenvolvimento e em alguns casos até ap licar algum treinamento 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 scru m guide estabelece é que ao final de uma sprint um novo incremento deve estar “pronto”, o qu e significa que deve estar na con dição utiliz utilizável e atender à definição de “pronto” da equipe scrum. Então toda Sprint (não importa o número dado a ela) deve ria entregar algum incremento de software na condição de utiliz utilizável. ável. Sprint 0 com a intenção só de planejamento não é oficial e não e xiste 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 Team B) Estimates Estimates are made by the Product Ow Owner, ner, but are ar e best checked with the Development Team Team C) Product backlog items must be estimated in story points D) Scrum forbids estimating E) Estimates Estimates must be in relative units JUSTIFICATIVA: A equipe eq uipe de des desenv envolvimen olvimento to é resp r espons onsáve ávell por po r toda t odass as a s estimat e stimativas ivas.. O pro produc ductt owner o wner deve d eve influenciar a equipe, ajudando no enten dimento e nas decisões conflituosas. Mas as pessoas que irão realizar o trabalho fazem a estimativa final.

following are feedback loops in Scrum? (Choose 3 answers) [Código de 24) Which three o f the following 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 q ue foi discutido nestes eventos. Release planning não é um evento oficial estabelecido no framework. framework. E as reuniões de refinamento não têm propósito de fo rnecer feedback

para adaptações no que está sendo desenvolvido ou foi desenvolvido: o foco é detalhar e preparar os itens do backlog do pro duto para as próxi próximas mas 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 Team’s responsibility C) Leave them for the lead developers on the team D) Assure every ever y Increment 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 eq uipe de des desenv envolvimen olvimento to pre precisa cisa ass assegu egurar rar que cad cada a incre in cremento mento do pro produt duto o aten a tende de a este e stess requisitos. Então, eles são de responsabilidade da equipe de desenvolvimento e são considerados a cada sprint.

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 happ en with the incompl incomplete ete 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 co mpletados durante a Sprint, além das sprints anteriores. Portanto, o qu e não está completo não pode ser incluído no incremento da sprint atual. Automaticamente, Automaticamente, o item que ficou incompleto poderá ser completado na próxi próxima ma sprint, desde que de acordo com o produtct owner. Na 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 Immediately after the first Sprint JUSTIFICATIVA: Uma nova sprint inicia imediatamente imediatamente após a conclusão da sprint anterior.

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 However,, he is unsure about his responsibilities. responsibiliti es. Which two activities are part of the Product Owner role according to Scrum? [Código de referência: 5803]

A) Describing features as Use Cases B) Providing the t he Development Team with with detailed deta iled 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 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 p artes interessadas ficam sob respo nsabilidade do product owner.

29) During a Sprint Retrosp ective, 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 o f 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 e quipe de desenvolvimento diminui a interação e resulta em menor ganho de produtividade. Equipes de desenvolvimento menores podem encontrar restrições de hab ilidades durante a spr int, gerando uma equipe de desen volvimento 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 adequa da 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

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 à d efinição de “pronto” da equipe scrum independente de o p roduct 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 n ot building Product Backlog items that h ave low

business value? (Choose 3 a nswers) [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 e m 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.

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 tra balhar com o mesmo backlog e com o mesmo PO. Esse esforço de coo rdenaçã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 resp osta, 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 equ ipe 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. F acilitando uma colaboração direta o SM não precisará gastar tempo como intermediador (Act as a go-between for them).

37) What three factors a re 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 é u m 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 htt s://www.scrumalliance.or /communit /articles/2014/november/selectin -s rint-len th-for- our-

.

.

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 p recisa 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 con siderado, 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? [Código de referência: 5813]

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 e quipes auto-organizadas, a opção C é a r esposta mais coerente.

39) What are two guidelines a Scrum Master would use to divide a group o f 100 pe ople 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 a s equipes são auto-or ganizadas, poderia ser d eixado para qu e os lideres do grupo de 1 00 pessoas determinassem como eles gostariam de se organ izar. O dono do produto não tem influência sobre a org anização da equipe e criar equipes para traba lhar em diferentes camadas é fora de cogitação, pois o scru m prega que as equipes pr ecisam ser multifuncionais - isto é, os membros precisam ter todas as habilidades necessárias para ge rar os incrementos do produto.

40) The Development Team informs the Scrum Master that the IT manager h as asked for a status

re ort durin the S rint. The Scrum Master will: Códi o de referência: 5815

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 d eixando o qua dro de tarefas (scrum board) e gráfico de burnd own da sprint visíveis para todos. Durante a reu nião de revisão da Sprint, a equipe scrum e as pa rtes interessadas colaboram sobre o que foi feito na sprint. O geren te de TI é uma parte interessada e ele pod e 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 pr oduto. Não é defendida pelo scrum a criação de equipes especializadas em determinadas camadas do sistema. O ideal é qu e 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 é de fendida em nenhuma parte do scrum guide a ne cessidade 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.

: Desempenho, assim como segurança, escalabilidade e manutenção, são r equisitos não funcionais. Normalmente os re quisitos não-funcionais são adicionados à definição de "Pronto" quand o 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 secur ity 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


Log off

Menu




ENCERRAR




min






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" propor ciona 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 a s técnicas e tecnologias pod em 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 q ue o time de desen volvimento execute o trabalho ne cessário para pr oduzir 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 sh ould 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 und erstand the chang es 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 po ssam ser entendidas na Re uniã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 p ara atinjam esse escopo. Arquitetura técnica evolui ao longo das Sprints.

7) One of the Scrum Teams chose to have a Deve lopment 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 Scr um Master Mast er pod pode e ser s er um membro membr o do d o Time T ime de Des Desenv envolvime olvimento nto,, mas isso não é obrig o brigató atório rio e nem n em 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 "empowered teams" C) End the Sprint with with a retrospective, r etrospective, since Scrum favors time boxing boxing JUSTIFICATIVA: Os eventos d o Scrum são baseados em um tempo fixo. fixo. Eles sempre terminam quando o tempo estabelecido se esgota, não importa a questão que haja.

Team, based on the learning from previous Sprints, decides to revisit the length of 9) The Scrum Team, 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 Retro Re trospe spectiva ctiva da Spr Sprint int é um u m evento eve nto ond onde e a equ equipe ipe insp inspecio eciona na a sua s ua for forma ma de d e trab t rabalha alharr (pes ( pessoa soas, s, relações, processos e ferr amentas), e adapta-se quaisquer melhori melhorias. as.

effectively track the Sprint prog ress, Scrum mandates: [Código de referência: 7032] 10) To effectively

A) Preparing Sprint burn down charts B) Increasing the transparency by frequently updating the remaining work C) Earned Value approach appro ach JUSTIFICATIVA: O Scrum não obriga o uso de gráfico ou técnicas como gerenciamento de valor agregado. Entretanto , ele obriga que haja transpa rência em relação as informações por traz dos artefatos.

11) Only the Product Ow Owner ner can come up with with items that can be considered for Product Backlog.

A) True B) False JUSTIFICATIVA: Embora o Product Owner Owner tem a palavra final sobre o conteúd o 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 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 d evelopment process and Sprint Review focuses on Velocity Velocity C) It focuses on development process and Sprint Review focuses on Product JUSTIFICATIVA: A Sprint Spr int Rev Review iew é um u m evento eve nto Scru Scrum m para pa ra insp inspecio ecionar nar e adap a daptar tar o dese d esenvo nvolvimen lvimento to do pro produt duto. o. A Sprint Retrospective foca na inspeção e adaptação da forma de trabalhar para desenvolver o produto.

Review, the Scrum Master notices that the Product Owner does not u se the 14) During a Sprint Review, Product burn-down graph to explain 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 Ex istem muitas muitas ferramentas como o gráfico bu rn-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 Master deve se esforçar para treinar a equipe sobre a im importância portância do e mpiri mpirismo smo e não das ferramentas.

which is often a b usiness need– is called as: 15) A short expression of the pu rpose of a Sprint which

go e r e e r n c a:

A) Sprint Goal B) Acceptance Criteria C) Definition of Done JUSTIFICATIVA: A meta da Sprin Sprintt prec p recisa isa ser pre preser servad vada. a. A Meta da Sprin Sprintt dá d á a Equip Equipe e de d e Dese D esenvo nvolvimen lvimento to algu alguma ma flexibil flex ibilidade idade em relação a funcionalidade a ser implementada implementada n a Sprint.

estimation on method re comm commended ended by Scrum is: [Código de referência: 7038] 16) The estimati

A) Planning Poker B) T-Shirt Sizing C) Yesterday’s weather D) None of the above JUSTIFICATIVA: Embora estudado neste curso, o Scrum não prescreve qualquer técnica de estimativa específica. O planning poker é totalmente opcional.

mandatory that the definition of "Done" includes “Release to Production”. [Código de 17) It is mandatory referência: 7039]

A) True B) False JUSTIFICATIVA: Cada Sprint inclui a produção de um Incremento Incremento potencialmente liberável. No No entanto, é o Product Owner que tem a decisão de libera-lo em produção

Team is more active in planning and 18) Under this part of the Sprint Planning, the Development Team 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 Planejam Planejamento ento 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 kn owledge of a product

that is requ ired 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 togethe r some guidelines on testing appro ach. 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 tra balho. O Scrum Guide menciona que o todo o Time Scrum participa, logo inclui o dono de pr oduto, scrum master e equipe de desenvolvimento. Convém que todos participem desta reunião.

23) Sprint Backlog is modified througho ut the Sprint. What d oes Development Team need to do

as soon a s 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 th e 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 produ ct, 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

Um único produto deve ter um único Product Backlog e, p ortanto, um único proprietário, um Product

Owner. O Product Owner pode delegar algumas das suas respo nsabilidades para a equipe, no entanto ele ainda é re sponsá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 o ne works on a different product. Wh at 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 to dos estão trabalhando em produtos diferentes, há possibilidade muito mínima de trabalho em equipe, colaboração e equ ipe 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 agre gadas ao framework, mas não sua a sua base.

32) Scrum Master forecasts the the d ate of release of product d uring 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 r esolver sozinha o problema e encontrar tra balho em torno de preservar a con clusã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 th e 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 par a completar e alcançar o Objetivo da Sprint. O Scrum não prescreve qu alquer 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? [Código de referência: 7058]

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 ger encia pessoa . Ele encorajar a auto-o rganização da equipe pa ra 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 d esenvolvimento só d eve trabalhar e m tarefas relacionadas com a Sprint Goal. Quando há uma violação, o Scrum Master ativamente atua para tre inar 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 ne xt 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 p oderia 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 capa city 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 n a sprint atua l.

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 gu ardião do framework Scrum e, consequentemente, as suas regra s.

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 n ovos 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 de termina como a reunião diária deve ser realizada. As únicas regr as explícitas são: - Ser um timebox de 15 minutos - Deve ser mantida no mesmo horário e local todo dia par a 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 sequ er participar da reunião, ele precisa ape nas garantir que ela ocor ra. 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 arte fatos definidos pelo Scrum, especialmente em relação a transparência que é um pilar importante.

43) Three De velopment Teams are working as part of a big project to develop a produ ct. 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 se u próprio Backlog de Sprint, mas o Backlog de Produto será único.

44) In empiricism, the decisions are base d 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 byproduct of self-organization JUSTIFICATIVA: Não há Sprint exclusiva apenas para finalizar o design. Cada Sprint deve se r usada para produ zir, 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. T he 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

e pr n

ann ng s 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 de ve falar com Product Owner. Para o Product Owner ter sucesso, toda a o rganização deve respe itar 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 ensur es that all the work associated with each Product Backlog item are identified and su fficiently decomposed. Th e 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 p lanejamento. Se ele ensinar a fazer isto, o time terá condições de realizar a reunião d e 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, entre tanto, não e xiste 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 preparad os "ready" para ser em puxados para den tro da Sprint. Para que a reunião de planejamento da Sprint possa ser re alizada com sucesso den tro 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 de talhado o suficiente para que ele possa ser entend ido e estimado. Se isto não for fe ito 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 capa cidade para fazer esse grooming.

48) Middle of the Sprint, the Development Team finds that some of the Product Backlog Items

forecast for th is Sprint cannot be finished becau se they nee d significant additional effort. However, the Development Team can still meet Sprint Goal with rest of the items. What is the next thing to do? [Código de referência: 7070]

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 obso leto . 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 accep ted as complete by Product Owner? [Código de referência: 7071]

A) Acceptance Criteria B) Definition of ready C) Definition of “Done” JUSTIFICATIVA: Definição de " pronto" define as nor mas 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 interessad as 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 quan do 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 guar dião do proce sso Scrum e o time-box e é uma regra fundamental do Scrum . Então, Scrum Master treina a equipe pa ra 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 de sign. [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 Dese nvolvimento define diretrizes arquitetônicas q ue 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 p roduction 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 coach ing 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 D) None of the above JUSTIFICATIVA: Um dos itens re vistos na retrosp ectiva é a " implementação do framework Scrum". Considerando que Scrum Master é o proprietário disto, ele participa como qualquer membro da eq uipe.

57) A Scrum Team is in the process of defining Product Backlog items. The Scrum Master notices

that the tea m 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 thr ee. 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 pod em encontrar limitações de co nhecimento durante a Sprint, fazendo com ue a e ui e de desenvolvimento se a inca az de entre ar um incremento otencialmente

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 equ ipe de desenvolvimento.

60) During a Sprint Review, the stakeholders notice that the p roduct development progress is not

very clearly visible and lacked transparen cy. Moreover, they are not able to understan d the ne xt 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 add ed 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 de finição de "pronto " para o seu trabalho combinado que será potencialmente liberável. Isso envolve algum trabalho de sobrecarga na sincronização e, p ortanto, 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 pe lo 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 traba lho 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 co mplexidade.

64) The work left ag ainst 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 g ráfico de Burndown é o gr áfico utilizado pelas equipes Scrum para representar diariamente o progresso do trabalho e m desenvolvimento. Ou seja, após ca da dia de trabalho o gráfico apresenta a p orção de traba lho finalizada em comparação com o trabalho total planejado. Também é possível ver o trabalho que falta e o tempo que r esta na sprint.

65) In Sprint Review, along with the review of the product Increment and pr ogress, “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 adap tar-se. "O que fazer a seguir " é sobre a adap tação do Product Backlog se necessário. O e scopo 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” p ara 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 de finição de “pro nto” 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 pod erá 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 ue não for ossível detalhar em termos de atividades ara desenvolver os itens selecionados

PSM.pdf

Recommend Documents