The correct answers are C, E, and F, because these phrases best describe the purpose of a definition of “Done”. It creates transparency over the work inspected at the Sprint Review, as it defines what it means for an Increment to be potentially releasable. It guides the Development Team in creating a forecast at the Sprint Planning, as it helps them estimate how much work they can accomplish in a Sprint. It defines what it takes for an Increment to be ready for release, as it ensures that the product meets the quality expectations of the stakeholders.

According to the Scrum Guide 1 , 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, two things that are appropriate for a Scrum Master to do if the Development Team doesn’t have the engineering tools and infrastructure to completely finish each selected Product Backlog item are:

Coach the Development Team to improve its skills, tools, and infrastructure over time and adjust the Definition of “Done” accordingly.

Have the Development Team establish a Definition of “Done” that is actually possible to achieve given current circumstances.

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

The Scrum Team consists of three roles: the Scrum Master, who coaches and facilitates the team; the Product Owner, who manages and prioritizes the Product Backlog; and the Development Team, who delivers a potentially releasable Increment at the end of each Sprint. A project manager is not part of the Scrum Team, as Scrum does not recognize titles or sub-teams. None of the above is also not a correct answer, as it implies that there is no Scrum Team at all.

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 topics that are appropriate for discussion are those that relate to how the team does its work, such as processes, tools, communication, collaboration, quality, etc. The value of work currently represented in the Product Backlog and arranging the Sprint Backlog for the next Sprint are not appropriate topics for discussion in a Sprint Retrospective, as they belong to the Sprint Review and Sprint Planning events respectively.

According to the Scrum Guide 1 , 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. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process. The time-boxed events in Scrum are:

Sprint Planning (eight hours or less for a one-month Sprint)

Daily Scrum (15 minutes or less for a one-month Sprint)

Sprint Review (four hours or less for a one-month Sprint)

Sprint Retrospective (three hours or less for a one-month Sprint)

The other options are not time-boxed events in Scrum.

The correct answers are A and B, because these are true about the Product Owner role. The Product Owner is one person, not a committee or a team, who is accountable for ordering the Product Backlog and maximizing the value of the product. The Scrum Guide states that “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. … For the Product Owner to succeed, the entire organization must respect his or her decisions.”

According to the Scrum Guide, 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 topics that are appropriate for discussion are those that relate to how the team does its work, such as team relations, Definition of Done, and processes, tools, communication, collaboration, quality, etc. The other options are not appropriate topics for discussion in a Sprint Retrospective, as they belong to other Scrum events (such as arranging the Sprint Backlog for the next Sprint in the Sprint Planning or evaluating the value of work in the Product Backlog in the Sprint Review).

The correct answers are B and C, because technical debt impacts transparency in these ways. It leads to false assumptions about the current state of the system, specifically of an Increment being releasable at the end of a Sprint, as it may contain hidden defects or incomplete functionality. It also results in future work being slowed down in unpredictable ways, as development progresses and code is added, the system becomes more difficult to stabilize and maintain.

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

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide and for helping everyone understand Scrum theory and practice. Option A is correct because Scrum events are timeboxed, and the Scrum Master helps the Scrum Team understand and properly use those timeboxes so events remain focused, productive, and effective. Teaching the team how timeboxing supports empiricism, focus, and predictability is part of the Scrum Master’s service to the team.

Option D is also correct because the Scrum Master serves the organization by helping those outside the Scrum Team understand how to interact effectively with the team. This includes removing barriers between stakeholders and Scrum Teams and coaching the organization in Scrum adoption.

Option B is incorrect because Scrum does not require the Scrum Master to maintain burndown charts. Option C is incorrect because Developers are self-managing and the Scrum Master does not assign tasks. Option E is incorrect because the Sprint Review is a collaborative inspection of the Increment, and completion is determined by whether work meets the Definition of Done, not by the Scrum Master declaring it.

In Scrum, regulatory and compliance requirements are not treated as work outside the Scrum Team or postponed until a separate phase. They must be made visible and managed as part of normal product development. Option C is correct because any work that is needed for the product, including compliance-related requirements, should be represented in the Product Backlog. The Product Backlog is the single source of work undertaken by the Scrum Team, so compliance items are handled alongside functional and technical work during Sprints.

Option D is also correct because compliance often affects whether an Increment is truly complete. Scrum requires each Increment to meet the Definition of Done, which creates transparency about quality and completeness. If regulatory conditions are necessary for releasability or completeness, they should be included in the Definition of Done and verified every Sprint.

Options A and B are incorrect because Scrum does not promote handing compliance to a separate team or completing all compliance analysis before Sprinting starts. Scrum uses an iterative, incremental approach where such requirements are addressed continuously.

The correct answers are B and C. According to the Scrum Guide, the Developers are accountable for creating a plan for the Sprint, which is the Sprint Backlog. That makes Option C correct. They are also accountable for organizing the work required to meet the Sprint Goal, which makes Option B correct. These are core elements of self-management in Scrum. Developers decide how to turn selected Product Backlog items into a valuable, usable Increment and how to adapt their plan throughout the Sprint.

Option A is incorrect because Scrum does not define “reporting productivity” as a Developer accountability. Scrum focuses on outcomes, transparency, and progress toward the Sprint Goal rather than traditional productivity reporting. Option D is incorrect because selecting the Product Owner is not a Developer accountability. Role assignments are determined by the organization, not by the Developers.

These accountabilities matter because Scrum relies on Developers to manage their own work rather than wait for direction from others. By creating and adapting the Sprint Backlog and organizing work toward the Sprint Goal, the Developers enable collaboration, flexibility, and accountability for producing a Done Increment each Sprint.

The best two answers are A and B. As a Scrum Team, prioritizing the list and working on them in order is a good technique to tackle the impediments. This way, the team can focus on the most urgent and important issues first and avoid being overwhelmed by the number of impediments. The Scrum Master discusses the impediments with the Scrum Team is also a helpful technique, as it allows the team to share their perspectives, identify the root causes, and come up with possible solutions. The Scrum Master can also coach the team on how to remove or prevent impediments in the future.

The correct answers are A and B. When multiple Scrum Teams work on the same product, Scrum calls for one Product Owner and one Product Backlog for that product. This ensures a single source of prioritization, clear accountability for maximizing value, and consistent product direction. One Product Owner helps avoid conflicting priorities across teams and provides one clear voice for product decisions.

One Product Backlog is equally important because it creates transparency for all work needed to develop the product. If each team had its own separate Product Backlog, the organization would risk fragmentation, duplicate work, inconsistent ordering, and confusion about the overall product direction. A single Product Backlog supports coordinated planning and alignment across all teams contributing to the same product.

Options C, D, and E are incorrect because they divide product accountability across multiple backlogs or multiple Product Owners. Scrum does not define a Chief Product Owner structure. For one product, there should be one Product Owner and one Product Backlog, even when multiple Scrum Teams are involved. This setup best supports focus, transparency, and value optimization.

Several Sprints into a project, a key stakeholder begins using the product and finds the quality lacking. The Product Owner (PO) agrees and shares this concern with the Scrum Master (SM). The Scrum Master needs to determine the best way to respond.

Scrum emphasizes empiricism , which is based on transparency, inspection, and adaptation ​. This means that if quality concerns arise, the Scrum Team must inspect the issue, adapt accordingly, and ensure quality is built into the product incrementally.

✅ A. Encourage the Product Owner to include quality specifications in the Product Backlog and to communicate the stakeholders ' concerns to the Developers.

???? Reference from the Scrum Guide :

" The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. " ​

" The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. " ​

???? Why is this Correct?

Since the Product Owner represents the stakeholders , they should translate the stakeholder’s concerns into actionable Product Backlog Items (PBIs) that reflect quality improvements.

Developers can refine and plan these PBIs in upcoming Sprints to ensure quality is systematically addressed.

The Product Backlog is the single source of work , meaning all quality requirements should be made explicit there.

This approach aligns with Scrum’s empirical process of making work transparent so that the team can inspect and adapt.

✅ C. Work with the Product Owner to understand their desired resolution and help formulate an approach for raising the concern with the Developers.

???? Reference from the Scrum Guide :

" The Scrum Master serves the Product Owner in several ways, including: Helping find techniques for effective Product Goal definition and Product Backlog management. " ​

" The Scrum Master serves the Scrum Team in several ways, including: Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done. " ​

???? Why is this Correct?

The Scrum Master is a servant leader , responsible for facilitating collaboration between the Product Owner and Developers so that the concern is effectively addressed.

Instead of dictating a solution, the Scrum Master guides discussions and enables the team to decide how best to improve quality.

The Definition of Done (DoD) should be reviewed to ensure it is clear, measurable, and includes quality standards ​.

This approach ensures that all stakeholders—Developers, Product Owner, and Scrum Master— collaborate in a self-managing way to improve quality.

Incorrect Answers with Explanations

❌ B. Bring the concern to the testers to improve how the Product is verified.

???? Reference from the Scrum Guide :

" Developers are always accountable for: Instilling quality by adhering to a Definition of Done. " ​

???? Why is this Incorrect?

Scrum does not have a separate testing team ; instead, the Developers are responsible for all aspects of quality (coding, testing, integration, etc.).

Quality should not be " verified " by an external group; rather, it must be built into the Increment from the start .

Instead of passing the issue to testers, the Scrum Team should improve their Definition of Done to ensure the product meets the necessary quality standards.

❌ D. Tell the Product Owner they have noted the concern and will raise this issue at the Sprint Retrospective.

???? Reference from the Scrum Guide :

" 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. " ​

???? Why is this Incorrect?

While the Sprint Retrospective is useful for discussing improvements , waiting until the Retrospective delays the resolution of a critical issue.

The Scrum Team should act immediately by addressing quality issues in the Product Backlog and adapting their work in upcoming Sprints.

Transparency and fast feedback are key principles in Scrum— delaying discussions goes against empiricism .

❌ E. Explain to the Product Owner that it is up to the Developers to decide on acceptable quality standards.

???? Reference from 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 product. " ​

" If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. " ​

???? Why is this Incorrect?

While the Developers are responsible for meeting the Definition of Done , quality is a shared responsibility across the Scrum Team .

The Product Owner must ensure that the product delivers value to stakeholders , which includes meeting their quality expectations.

Ignoring the Product Owner’s concerns contradicts Scrum’s emphasis on collaboration and transparency.

Three statements that are true about Scrum are:

Each component of Scrum serves a specific purpose and is essential to Scrum’s success and your usage of Scrum to develop complex products.

Scrum is a framework for developing and sustaining complex products.

Scrum is based on empiricism and lean thinking.

These statements are supported by [6]: “Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. … Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage. … The rules of Scrum bind together events, roles, artifacts, and rules governing their relationships. … The three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.”

According to the Scrum Guide 1 , 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. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process. The time-box for the Daily Scrum is 15 minutes or less for a one-month Sprint. Its location and time remain constant.

The best two answers are B and D. These two ways of dealing with regulatory compliance issues are consistent with Scrum’s values and principles, as they allow the Scrum Team to deliver valuable and potentially releasable increments of the product while meeting the necessary standards and regulations. They also enable the Scrum Team to inspect and adapt their compliance strategy based on feedback and changing requirements.

A is not a good answer because it creates a separate silo of responsibility for compliance issues, which can lead to delays, conflicts, and inefficiencies. It also violates the Scrum value of transparency, as the compliance team may not have full visibility into the product development process.

C is not a good answer because it implies a waterfall approach that assumes all the compliance requirements are known and fixed upfront, which is rarely the case. It also reduces the flexibility and responsiveness of the Scrum Team, as they may have to follow a rigid plan that does not reflect the current reality of the product or the market.

According to the Scrum Guide 1 , 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. Therefore, two appropriate topics for discussion during a Sprint Retrospective are:

Identifying high priority process improvements for the next Sprint.

How the team collaborates.

The other options are not relevant or appropriate for the Sprint Retrospective.

The best answers are A, C, and E. The Definition of Done creates transparency by making everyone understand what it means for work to be complete. That makes Option C correct. It also creates a shared understanding of completion, which makes Option E correct. This is essential in Scrum because inspection is only meaningful when there is clarity about whether a Product Backlog item or Increment is actually done.

Option A is also correct because the Definition of Done helps Developers determine how much work they can realistically select during Sprint Planning. If the team understands the full quality criteria required for completion, they can make better decisions about how many Product Backlog items fit within the Sprint.

Option B is incorrect because Scrum does not support “mostly done.” Work is either done according to the Definition of Done or it is not done. Option D is incorrect because the Definition of Done does not describe Scrum events. It applies to the Increment and defines the quality measures required for completeness.

In Scrum, the Definition of Done is a critical tool for quality, transparency, and forecasting realistic Sprint scope.

According to the Scrum Guide, two intended outcomes of the Daily Scrum are a shared understanding of the most important work to be undertaken next to achieve the best possible progress toward the Sprint goal, and new impediments for the Scrum Master to take care of. The other options are not intended outcomes of the Daily Scrum, as they are either irrelevant (such as updating a Scrum board) or inappropriate (such as providing an update or a status report).

According to the Scrum Guide 1 , 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.