PSM-I Professional Scrum Master I Questions and Answers

According to the Scrum Guide1, the definition of “Done” is a formal description of the state of the Increment when it meets the quality measures required for the product. The definition guides the Development Team in creating a “Done” Increment. The definition of “Done” is created by the development organization (or Development Team if none is available from the development organization). The definition of “Done” may vary significantly per Scrum Team, depending on the context. One aspect of Scrum Teams inspecting how they work toward their Product Goal is that they improve their definition of “Done” over time. Therefore, one reason why the Product Owner wants the Development Team to adhere to its definition of “Done” is to have complete transparency into what has been done at the end of each Sprint.

References: Scrum Guide

A Product Owner releases each Increment when it makes sense, as stated in [2]: “The Product Owner decides when to release an Increment. This can be done at any time during or after a Sprint. The Product Owner may choose to release an Increment when it delivers enough value to customers or users, when it meets a market opportunity, when it reduces risk or uncertainty, or when it aligns with other business goals.”

According to the Scrum Guide, the Sprint Backlog may include any items that are a decomposition of the selected Product Backlog items, such as user stories, tasks, use cases, tests, or others. The Sprint Backlog is the Developers’ plan for the Sprint, and it contains all the work that they forecast they can do to achieve the Sprint Goal and create a “Done” Increment. The other options are not valid, as they are either too specific (such as user stories or tasks) or too vague (such as tests).

According to the Scrum Guide, multiple Scrum Teams working on the same product do not have to have the same Sprint start date. They may start their Sprints at different times, as long as they synchronize their work and integrate their Increments at least by the end of each Sprint. The other option is not valid, as it implies that having the same Sprint start date is mandatory for multiple Scrum Teams.

According to the Scrum Guide, the Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide1. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values1. The Scrum Master is accountable for establishing Scrum2. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization while serving the Scrum Team as well as the larger organization2.

Option B is incorrect because keeping track of resource allocation is not a responsibility of the Scrum Master. The Scrum Master does not manage or control the resources of the Scrum Team or the organization. The Scrum Team is self-organizing and responsible for managing its own work within a Sprint1.

Option C is incorrect because managing the performance of the Scrum Team is not a responsibility of the Scrum Master. The Scrum Master does not evaluate or appraise the performance of the Development Team or the Product Owner. The Scrum Master serves the Development Team by coaching them on self-organization and cross-functionality, and serves the Product Owner by ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team1.

Option D is incorrect because the meetings and the objectives that a Scrum Team sets for itself are not a responsibility of the Scrum Master. The Scrum Master does not dictate or prescribe what meetings or objectives a Scrum Team should have. The Scrum Master facilitates the Scrum Events as requested or needed, and ensures that they are positive, productive, and kept within the time-box1.

A cross-functional Development Team is one that includes cross-skilled individuals who are able to contribute to do what is necessary to deliver an increment of software, as stated in the Scrum Guide1: “Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.”

The correct answer is A, because the best way the Scrum Master can ensure that the Development Team communicates effectively with the Product Owner is to monitor communications between them and facilitate direct collaboration. The Scrum Guide states that “the Scrum Master serves the Product Owner in several ways, including … facilitating Scrum events as requested or needed.” Therefore, the Scrum Master should help the Development Team and the Product Owner interact regularly and productively during the Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective events.

According to the Scrum Guide, when multiple Scrum Teams are working on the same product, they should integrate their Increments every Sprint, in order to accurately inspect what is done and ensure that there is no technical debt or unfinished work at the end of each Sprint. The other options are not valid, as they imply that integration can be skipped, delayed, or done only for some teams, which is not consistent with Scrum values and principles.

A Scrum Team is a cohesive unit of professionals that consists of one Product Owner, one Scrum Master, and Developers, as stated in the Scrum Guide: “The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.”

According to the Scrum Guide, the action that the Scrum Master should take when the Team decides that a Sprint Retrospective is unnecessary is to begin facilitating productive and useful Sprint Retrospectives. The Sprint Retrospective is an essential event for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Scrum Master is responsible for ensuring that this event takes place and that positive outcomes are achieved. The other options are not valid actions, as they either imply that the Scrum Master complies with or ignores the decision of the Team (such as complying with it, calling a meeting with senior management, or consulting with the Product Owner), which is not consistent with Scrum values and principles.

According to the Scrum Guide, two valid actions that the Developers can take when they realize that the workload may be greater than their capacity to complete the work are ensuring that the Scrum Team is aware, starting the Sprint, and monitoring progress, and removing or changing selected Product Backlog items. These actions are consistent with Scrum values and principles, such as transparency, adaptation, and collaboration. The other options are not valid actions, as they are either wasteful (such as recruiting additional Developers or canceling the Sprint) or unsustainable (such as working overtime).

According to the Scrum Guide1, 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. The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Product Owner is part of the Scrum Team and should participate as a Scrum Team member in the Sprint Retrospective.

References: Scrum Guide

The correct answer is B, because when multiple teams work together on the same product, they should not maintain separate Product Backlogs. The Scrum Guide states that “multiple Scrum Teams often work together on the same product. One product goal unites them. Therefore, they must mutually define and comply with a definition of ‘Done’ that applies to their combined work product. … Multiple Scrum Teams working on the same product use the same Product Backlog.”

The correct answer is B, because the Sprint Backlog is created during the Sprint Planning meeting. The Scrum Guide states that “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.”

According to the Scrum Guide1, 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. The Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together.

References: Scrum Guide

According to the Scrum Guide1, during each Daily Scrum, each Developer answers three questions:

What did I do yesterday that helped meet our Sprint Goal?

What will I do today to help meet our Sprint Goal?

Do I see any impediment that prevents me or our Development Team from meeting our Sprint Goal?

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward achieving their Sprint Goal and producing a usable Increment. The other options are not relevant or appropriate for the Daily Scrum.

References: Scrum Guide

According to the Scrum Guide1, an Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, an Increment must be usable. Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value. Therefore, in order to turn Product Backlog items into an Increment of potentially releasable product functionality, the Development Team should have all the skills needed.

References: Scrum Guide

The Development Team must do as much work as it has told the Product Owner will be done for every Product Backlog item it selects in conformance with the definition of “Done”, as stated in the Scrum Guide1: “The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.”

According to the Scrum Guide1, the Sprint Planning meeting has a time-box of eight hours or less for a one-month Sprint. The Scrum Master ensures that the meeting is time-boxed and keeps the Scrum Team focused on the objective. If the Development Team cannot forecast how many Product Backlog items it can complete, it should still start the Sprint and work on the most likely items to meet the Sprint Goal. The Sprint Backlog can be updated throughout the Sprint as more is learned. The Scrum Master should also support the team to discuss the reasons for the lack of clarity in the Product Backlog items and how to prevent it from happening again in the next Sprint Retrospective.

References: Scrum Guide

The correct answer is F, because all of the Scrum Values are affected by a lack of trust in the Scrum Team. Trust is essential for the Scrum Team to work effectively and deliver value. Without trust, the Scrum Team may lose focus, respect, openness, courage, and commitment.

According to the Scrum Guide1, the Daily Scrum is an event for the Developers of the Scrum Team. The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum optimizes the probability that the Developers will meet the Sprint Goal. Every day, the Developers should understand how they intend to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint. Management external to the Scrum Team is not involved in the Daily Scrum, as they may interfere with the self-management and empowerment of the Developers.

References: Scrum Guide

According to the Scrum Guide1, the definition of “Done” is a formal description of the state of the Increment when it meets the quality measures required for the product. The definition guides the Development Team in creating a “Done” Increment. The definition of “Done” is created by the development organization (or Development Team if none is available from the development organization). The definition of “Done” may vary significantly per Scrum Team, depending on the context. One aspect of Scrum Teams inspecting how they work toward their Product Goal is that they improve their definition of “Done” over time. Therefore, one good way for a Scrum Team to ensure security concerns are satisfied is to add security concerns to the definition of “Done”. Another good way is to have the Scrum Team create Product Backlog items for each concern, as they are responsible for managing and refining the Product Backlog.

References: Scrum Guide

According to the Scrum Guide1, when multiple Scrum Teams are working together on one product, they must coordinate their work with each other. One way to do this is through Nexus, a framework for scaling Scrum. Nexus helps to reduce cross-team dependencies and integration issues by making them more transparent. Multiple Scrum Teams working on one product use one Product Backlog.

References: Scrum Guide, Nexus Guide

The correct answers are B and C, because these are two responsibilities of a self-organizing Development Team. The Scrum Guide states that “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. Development Teams are structured and empowered by the organization to organize and manage their own work.” Therefore, the Development Team should pull Product Backlog items for the Sprint and do the work planned in the Sprint Backlog.

According to the Scrum Guide1, ordering Product Backlog items is solely up to the Product Owner’s discretion. The Product Owner orders items in the Product Backlog to best achieve goals and missions. To do this, they optimize value by considering various factors such as cost and benefit, risk, dependencies, date needed, etc. The Product Owner is responsible for maximizing the value of the work the Development Team does.

References: Scrum Guide

The correct answer is A, because the Product Owner does not determine how many Product Backlog items the Development Team selects for a Sprint. The Scrum Guide states that “the number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.” Therefore, the Development Team is responsible for choosing the scope of work for a Sprint.

According to the Scrum Guide1, an Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, an Increment must be usable. Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value. For the purpose of transparency, when does Scrum say a new increment of working software must be available? At the end of every Sprint.

References: Scrum Guide

The Definition of Done serves the following three purposes:

A. Create a shared understanding of when work is complete.

The Definition of Done is a commitment to the quality of the product increment that is part of Scrum. It is a formal description of the state of the product backlog item or the increment when it meets the quality measures required for the product. The Scrum team must have a shared understanding of what ‘done’ means and use it to assess when work is complete and transparent1.

C. Increase transparency.

The Definition of Done increases transparency by providing everyone a shared understanding of what work was completed and what standards were met as part of the increment. This ensures that the product increment is potentially releasable and that the stakeholders can inspect and provide feedback on it2.

D. Describe the work that must be mostly done before the Sprint is allowed to end.

The Definition of Done describes the work that must be done before the Sprint is allowed to end. Work cannot be considered part of an increment unless it meets the Definition of Done. The Definition of Done is used to guide the Developers in creating a "Done", usable, and potentially releasable product increment every Sprint3.

B and E are not purposes of the Definition of Done.

B. Guide the Developers on how many Product Backlog items to select for the Sprint.

The Definition of Done does not guide the Developers on how many Product Backlog items to select for the Sprint. The Developers select how many Product Backlog items they can complete within a Sprint based on their capacity, skills, and experience. The Definition of Done helps them ensure that the selected items are completed to a high standard of quality4.

E. Describe the purpose, Objective, and timebox Of each Scrum event.

The Definition of Done does not describe the purpose, objective, and timebox of each Scrum event. The Scrum Guide describes these aspects for each Scrum event, such as Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective5. The Definition of Done is related to the product increment, not to the Scrum events.

The best answer is C. Ensure every Increment meets them. Non-functional requirements (NFRs) are system qualities that guide the design of the solution and often serve as constraints across the relevant backlogs1. NFRs are persistent qualities and constraints typically revisited as part of the definition of done (DoD) for each Iteration, PI, or release1. The Scrum Team should ensure that every Increment meets the NFRs, as they are part of the product requirements and affect the value delivery and customer satisfaction.

According to the Scrum Guide, the Scrum Master is responsible for coaching the Scrum Team to improve its skills, tools and environment over time and adjust the Definition of Done accordingly1. The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product1. The Definition of Done should be possible to achieve given current circumstances2. Therefore, option B and E are appropriate for a Scrum Master to do, if the Scrum Team does not have the tools and environment to completely finish each selected Product Backlog item.

Option A is not appropriate because declaring the Scrum Team not ready for Scrum implies that there is a fixed set of prerequisites for using Scrum, which is not true. Scrum is a framework that can be applied to any complex product development effort1.

Option C is not appropriate because encouraging the Product Owner to accept partially done Increments until the situation improves violates the principle of transparency. Transparency requires that the Increment is a usable product that meets the current Definition of Done1. Accepting partially done Increments also increases technical debt and reduces value delivery3.

Option D is not appropriate because refocusing the current Sprint on establishing the Scrum Team’s environment instead of delivering an Increment goes against the purpose of a Sprint. A Sprint is a time-boxed event that serves as a container for the other Scrum events and activities. The goal of each Sprint is to deliver a potentially releasable Increment that adheres to the current Definition of Done1.

References: 1: The Scrum Guide 2: Suggested Reading for Professional Scrum Master™ I 3: Mastering Professional Scrum

 According to the Scrum Guide, a Development Team needs a Sprint Goal because it provides guidance and focus for building an Increment that delivers value. The other options are not valid reasons for having a Sprint Goal, as they are either incorrect (such as giving purpose only to Sprint 0 or ensuring implementation of all Product Backlog items) or irrelevant (such as knowing everything from the Product Backlog).

When many Development Teams are working on a single product, the definition of “Done” must be shared by all Development Teams and make their combined work potentially releasable, as stated in [4]: “When multiple teams work together on one product they must mutually define and comply with the same Definition of Done. This makes sure all Increments adhere to a consistent quality level.”

The correct answer is C, because a Development Team should deliver an increment of working software that is “done” by the end of a Sprint. The Scrum Guide states that “the Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be ‘Done,’ which means it must be in useable condition and meet the Scrum Team’s definition of ‘Done’.”

According to the Scrum Guide, two actions that the Scrum Master should support in this scenario are forecasting the Product Backlog items that are most likely to meet the Sprint Goal and creating the Sprint Backlog, and discussing why this happened and what changes will make it less likely to recur during the next Sprint Retrospective. These actions are consistent with Scrum values and principles, such as empiricism, adaptation, and continuous improvement. The other options are not valid actions, as they are either wasteful (such as canceling the Sprint or continuing the Sprint Planning past its timebox) or ineffective (such as asking everyone to take more time to analyze the Product Backlog).

According to the Scrum Guide1, the definition of “Done” is a formal description of the state of the Increment when it meets the quality measures required for the product. The definition guides the Development Team in creating a “Done” Increment. The definition of “Done” is created by the development organization (or Development Team if none is available from the development organization). The definition of “Done” may vary significantly per Scrum Team, depending on the context. One aspect of Scrum Teams inspecting how they work toward their Product Goal is that they improve their definition of “Done” over time. Therefore, if a Product Backlog item worked on during the Sprint does not meet the definition of “Done”, two things that should happen with the undone Product Backlog item are:

Put it on the Product Backlog for the Product Owner to decide what to do with it, as they are accountable for effective Product Backlog management and ordering.

Do not include the item in the Increment this Sprint, as it does not meet the quality standards and may compromise value.

The other options are not appropriate, as they may compromise transparency, inspection, or adaptation.

References: Scrum Guide

The correct answers are D and E, because these are two activities that a Product Owner can engage in during a Sprint. The Scrum Guide states that “the Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” Therefore, the Product Owner can answer questions from the Development Team about items in the current Sprint, and work with the stakeholders to understand their needs and expectations.

According to the Scrum Guide1, ordering Product Backlog items is solely up to the Product Owner’s discretion. The Product Owner orders items in the Product Backlog to best achieve goals and missions. To do this, they optimize value by considering various factors such as cost and benefit, risk, dependencies, date needed, etc.

According to the Scrum Guide, the Developers are accountable for tracking the remaining work toward the Sprint Goal, as they are responsible for creating a valuable Increment that meets the Definition of Done and the Sprint Goal. The other options are not valid, as they imply that someone else outside the Development Team (such as the Scrum Master, the Product Owner, or the Project Manager) is accountable for tracking the remaining work, which is not consistent with Scrum values and principles.

According to the Scrum Guide, an Increment does not have to be released to customers or users at the end of each Sprint. However, it must be in a usable condition and meet the Definition of Done. The decision to release an Increment is made by the Product Owner, based on the value and feedback obtained from stakeholders. The other option is not valid, as it implies that releasing an Increment is mandatory at the end of each Sprint.

Sprint Backlog is owned by the Development Team. The Scrum Guide states that “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 Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.”

According to the Scrum Guide, a Development Team is cross-functional if it has all the skills to create a potentially releasable Increment by the end of every Sprint. The other options are not indicators of cross-functionality, as they are either specific practices (such as pair programming or test driven development) or irrelevant factors (such as conflicts within the team or ability to perform every task).

The correct answers are B and D, because the length of the Sprint should be chosen based on the level of uncertainty over the technology to be used and the risk of being disconnected from the stakeholders. The Scrum Guide states that “Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase.”

The correct answers are A, B, and D, because these techniques would be most helpful in this situation. Consulting with the Development Team may help identify the root causes of the impediments and possible solutions. Prioritizing the list and working on them in order may help reduce the backlog and focus on the most important or urgent issues. Alerting management to the impediments and their impact may help escalate the problems and get support from the organization.

According to the Scrum Guide, the Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product1. The Definition of Done is created by the Developers and it is used to assess when work is complete on the product Increment1.

The Scrum Guide also states that the Definition of Done may vary significantly per Scrum Team, depending on the context. The Definition of Done evolves over time and becomes more stringent as the Scrum Team matures1. Therefore, it is important for the Scrum Team to regularly inspect and adapt the Definition of Done to reflect their current situation and needs.

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 Sprint1. The Sprint Retrospective focuses on three questions: What went well in the Sprint? What could be improved? What will we commit to improve in the next Sprint?1 These questions can help the Scrum Team identify potential changes to the Definition of Done that would increase the quality and value of the product.

Option A is incorrect because Product Backlog refinement is not a formal Scrum event, but rather an ongoing activity that can happen at any time during the Sprint1. Product Backlog refinement is mainly concerned with adding detail, estimates, and order to Product Backlog items1. Changing the Definition of Done during Product Backlog refinement could cause confusion and inconsistency among the Developers and the Product Owner.

Option C is incorrect because Sprint Planning is a time-boxed event that initiates a Sprint by defining a Sprint Goal and selecting Product Backlog items that deliver one coherent function1. Sprint Planning is based on the current state of the Product Backlog and the latest Definition of Done1. Changing the Definition of Done during Sprint Planning could disrupt the flow of the event and affect the scope and feasibility of the Sprint.

Option D is incorrect because prior to starting a new project is not a specific time in Scrum. Scrum does not prescribe any phases or stages for a project, but rather an empirical approach that relies on frequent inspection and adaptation of both the product and the process1. Changing the Definition of Done before starting a new project could be premature and irrelevant, as the Scrum Team may not have enough information or experience to define what ‘Done’ means for their product.

References: 1: The Scrum Guide

According to the Scrum Guide, estimates are made by the people doing the work, which is the Development Team. The Development Team is responsible for all estimates in the Product Backlog and the Sprint Backlog. The other options are not valid guidelines for estimating work in Scrum, as they are either too prescriptive (such as requiring story points or relative units), incorrect (such as forbidding estimating or having the Product Owner make estimates), or unnecessary (such as checking estimates with the Development Team).

 Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required12. The Scrum Team’s goal is to deliver a “Done” Increment that meets the Definition of Done and the Sprint Goal3.

References: 1: The Scrum Team | Scrum.org 2: The Professional Scrum™ Competencies | Scrum.org 3: The 2020 Scrum Guide | Scrum.org

The correct answer is B, because there is no role called “Project Manager” in Scrum. The Scrum Guide states that “Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule.” Therefore, Scrum has only three roles: Product Owner, Scrum Master, and Developer.

According to the Scrum Guide, two things that the Scrum Team should do during the first Sprint are building at least one piece of valuable functionality and creating at least one valuable, useful Increment. These are the goals of every Sprint, regardless of its order. The other options are not things that the Scrum Team should do during the first Sprint, as they are either out of scope (such as defining major product features and a release plan architecture or making a plan for the rest of the project) or unnecessary (such as analyzing, describing, and documenting requirements for subsequent Sprints).

According to the Scrum Guide, the Product Backlog is an ordered list of everything that is known to be needed in the product. It is allowed to grow and change as more is learned about the product and its customers. The other options are not accurate descriptions of the Product Backlog, as they are either too restrictive (such as providing just enough information or baselining to follow change management processes) or too comprehensive (such as containing all foreseeable tasks and requirements or enabling a complete project plan).

According to the Scrum Guide, the Sprint Backlog is the Developers’ plan for the Sprint, as it contains all the Product Backlog items selected for the Sprint and a plan for delivering them. The other options are not valid descriptions of the Sprint Backlog, as they are either incorrect (such as having a designated owner, being ordered by the Product Owner, or being a complete list of all work) or unnecessary (such as estimating each task in hours).

According to the Scrum Guide1, there are five values that guide decisions within Scrum teams:

Commitment

Focus

Openness

Respect

Courage

In order to achieve the benefits of Scrum, it is important to enact these values. Two actions that demonstrate the commitment of Scrum Team members are:

Help the other Scrum Team members, as they work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.

Do your best, as they strive to deliver a potentially releasable Increment that meets the definition of “Done” and provides value to the stakeholders.

According to the Scrum Guide1, there are five values that guide decisions within Scrum teams:

Commitment

Focus

Openness

Respect

Courage

By not building Product Backlog items that have low business value, Scrum teams exhibit respect for their stakeholders and customers, as they deliver what is most valuable and relevant for them. They also exhibit focus, as they concentrate on what matters most for achieving their Product Goal and Sprint Goal. They also exhibit courage, as they are willing to say no to low-value work and face possible conflicts or disagreements.

The correct answer is E, because any of the above (or others) which are a decomposition of the selected Product Backlog items can be included in the Sprint Backlog. The Scrum Guide states that “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.” Therefore, any work items that help the Development Team achieve the Sprint Goal can be part of the Sprint Backlog.

The correct answer is B, because the Scrum Guide states that “the Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.” Therefore, new work or further decomposition of work can be added to the Sprint Backlog as soon as possible after they are identified by the Development Team.

The correct answers are B and E, because these statements are true about the length of the Sprint. It is best to have Sprints of consistent length throughout a development effort, as this helps establish a reliable rhythm and cadence for the Scrum Team and the stakeholders. All Sprints must be one month or less, as this ensures that the Scrum Team can inspect and adapt frequently and deliver value incrementally.

According to the Scrum Guide1, the Developers are self-organizing and decide how to turn Product Backlog items into an Increment of value. No one tells them how to do their work. The Developers are accountable for creating a plan for the Sprint, the Sprint Backlog. The other roles are not responsible for making sure everyone on the Development Team does their tasks for the Sprint.

References: Scrum Guide

 According to the Scrum Guide1, 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. 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. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

References: Scrum Guide

Two techniques that the Scrum Master could use when the Scrum Team gets caught in an internal disagreement about which agile practices to apply are to involve the complete Scrum Team in making a decision, and to use coaching techniques such as open questions and active listening, as stated in [3]: “The Scrum Master should facilitate a constructive dialogue among the team members and help them reach a consensus on which agile practices to use. The Scrum Master should also use coaching techniques such as open questions and active listening to understand the underlying needs and motivations of each team member and to help them find common ground.”

According to the Scrum Guide1, there is no such thing as a Release Sprint in Scrum. A Release Sprint implies that there are other Sprints that don’t produce a potentially releasable Increment, which violates the core principle of Scrum. Every Sprint should result in a “Done”, useable, and potentially releasable product Increment.

A Sprint burndown chart shows an estimate of the total work remaining for the Sprint, as stated in 3: “A sprint burndown chart tracks work remaining in a sprint. It shows how much work remains at any given point during a sprint. It helps teams monitor whether they will finish all planned tasks by the end of a sprint.”

According to the Scrum Guide, a Developer becomes accountable for the value of a Product Backlog item selected for the Sprint at the Sprint Planning event. This is when the Developers select items from the Product Backlog that they can commit to complete within a Sprint. The Developers are then responsible for creating a valuable Increment that meets the Definition of Done and the Sprint Goal. The other options are not valid, as they either imply that Developers are not accountable for value (such as never or whenever), or that they become accountable at a different time (such as during the Daily Scrum).

A Scrum Master fulfills a different role than a traditional project manager, as stated in 2: “A project manager helps manage the project timeline, resources, and scope in order to meet business requirements. A Scrum Master, however, helps ensure the Scrum Team follows Scrum theory, practices, and rules. The Scrum Master is a servant-leader who helps optimize the value created by the Scrum Team.”

The best two answers are A and C. These two ways of creating Scrum Teams are consistent with Scrum’s values because they respect the self-organization and empowerment of the people who will be working in the teams. They also foster openness and courage by allowing the people to express their preferences and opinions about the new structure.

B, D and E are not consistent with Scrum’s values because they impose a top-down approach that does not involve the people who will be affected by the change. They also undermine the commitment and focus of the teams by assigning them to work on something they may not be interested in or passionate about.

According to the Scrum Guide1, the purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with domain, practices, and people involved. The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint. The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Scrum Master is part of the Scrum Team and should participate as a Scrum team member and facilitate as requested or needed.

References: Scrum Guide

According to the Scrum Guide1, the Daily Scrum is an event for the Developers of the Scrum Team. The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum optimizes the probability that the Developers will meet the Sprint Goal. Every day, the Developers should understand how they intend to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint. If the frequency of the Daily Scrum were to be lowered to every two or three days, some key concerns would be:

Opportunities to inspect and adapt the Sprint Backlog are lost, which may result in wasted work or missed dependencies.

Impediments are raised and resolved more slowly, which may hinder the progress and quality of the work.

The Sprint plan may become inaccurate, as changes in requirements, risks, or priorities are not reflected in a timely manner.

The other options are not valid concerns, as they are not aligned with Scrum values and principles.

References: Scrum Guide

There are no activities that a Product Owner would typically undertake in the phase between the end of the current Sprint and the start of the next Sprint, because there is no such phase. The next Sprint starts immediately after the current Sprint, without any gaps or breaks. The other options are either activities that occur during a Sprint (such as refining the Product Backlog) or activities that are not consistent with Scrum (such as working with Quality Assurance departments or updating project plans).

According to the Scrum Guide1, one aspect of Scrum Teams inspecting how they work toward their Product Goal is that they create a Sprint Goal every Sprint. 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 Developers on why it is building the Increment. It also provides a basis for inspecting and adapting during the Sprint Review and Sprint Retrospective. The Sprint Goal is created during the Sprint Planning event.

References: Scrum Guide

The next Sprint begins immediately after the conclusion of the previous Sprint, as stated in the Scrum Guide: “Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.”

According to the Scrum Guide1, 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 accountable for maximizing value resulting from work by Developers. The Product Owner is also accountable for effective Product Backlog management, which includes:

Developing and explicitly communicating the Product Goal;

Creating and clearly communicating Product Backlog items;

Ordering Product Backlog items; and

Ensuring that the Product Backlog is transparent, visible and understood.

Therefore, the Product Owner is responsible for clearly expressing Product Backlog items.

References: Scrum Guide

According to the Scrum Guide1, only people who are actively working on items in the Sprint Backlog participate in updating it during a Sprint; this includes tracking progress made on those items. This is typically done by Developers updating their remaining work every day after their Daily Scrum. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving their Sprint Goal. The Developers are self-organizing and decide how to turn Product Backlog items into an Increment of value. Therefore, the Scrum Master should allow the Development Team to self-manage and determine for itself what to do regarding the logistical challenges of meeting in different locations.

References: Scrum Guide

According to the Scrum Guide, every Scrum Team must have a Product Owner and a Scrum Master, as they are essential roles for Scrum. The outcomes of the Scrum Team are affected by their participation and availability, as they provide guidance, support, and facilitation to the Development Team and the stakeholders. The other options are false, as they imply that a Product Owner or a Scrum Master can be replaced or optional, which is not consistent with Scrum.

The correct answer is A, because a good first question for you to suggest the group thinks about when forming into teams is how will we make sure all teams have the right amount of expertise. This question helps the group consider the cross-functionality and self-organization of the Development Teams, which are essential for delivering a potentially releasable Increment every Sprint.

References: [Suggested Reading for Professional Scrum Master™ I]

According to the Scrum Guide, the best approach for Scrum Teams in order to produce valuable Increments is to have each Developer work on the component where they feel that they can contribute. This means that the Developers can self-organize and collaborate effectively to deliver a valuable Increment that meets the Definition of Done and the Sprint Goal. The other options are not valid approaches, as they either imply that the Developers work in silos or rely on external people (such as developing functionality from beginning to end, working on an independent set of components, or working only as an independent layer of the system).

According to the Scrum Guide1, an Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable. Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.

References: Scrum Guide