PSM-I Questions and Answers

The correct answer is A because the Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. Product Backlog ordering should therefore be driven primarily by value, not by keeping every Developer busy at all times. Scrum does not optimize for utilization. It optimizes for value delivery, learning, and progress toward the Product Goal.

The Scrum Master should coach the Product Owner to keep the Product Backlog ordered based on what delivers the most value and best supports product outcomes. External dependencies may influence sequencing, but they should not cause the Product Owner to abandon value-based ordering just to fill capacity. In Scrum, some inefficiency may temporarily occur due to uncertainty or dependency constraints, but that is not a reason to shift toward activity-based planning.

Option B is too prescriptive and assumes a specific backlog ordering response. Option C is incorrect because maximizing utilization is not the Product Owner’s responsibility and is not a Scrum objective. Scrum encourages focus on valuable Increments, not on ensuring that everyone is always fully occupied regardless of whether the work is the most important.

The correct answers are B and E, because Scrum has no “tester” role and everyone in the Development Team is responsible for quality. 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. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.”

An example of an Increment is a valuable, useful set of product features, as stated in [4]: “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, each Increment must be usable.”

The best answers are B and C because the Scrum Master serves both the Product Owner and the Scrum Team by helping address quality concerns in a constructive, transparent, and Scrum-consistent way. Quality in Scrum is not handled outside the team or delegated only to testers. When a stakeholder raises a concern about low quality, the issue should be made visible and addressed through the Product Backlog, the Definition of Done, and direct collaboration within the Scrum Team.

Option B is correct because quality expectations and stakeholder concerns should be reflected in Product Backlog items when appropriate, and the Developers need to understand those concerns clearly. Option C is also correct because the Scrum Master helps the Product Owner find an effective way to work with the Developers and address the issue empirically.

Option A is incorrect because acceptable quality standards are not solely for Developers to decide in isolation. Option D is incorrect because Scrum does not create a separate tester role responsible for quality. Option E is too passive and delayed. A significant quality concern should be addressed promptly, not simply postponed to the Sprint Retrospective.

The Product Owner should know the most about the progress toward a business objective or a release, as stated in the Scrum Guide: “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.”

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

The correct answer is C, because as soon as possible in the Sprint, the Development Team should work with the Product Owner to remove some work or Product Backlog items if they realize they have selected too much work to finish in the Sprint. The Scrum Guide states that “the Development Team may renegotiate the selected Product Backlog items with the Product Owner. If the Development Team realizes 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.”

The correct answer is B, because the time-box for a Daily Scrum is 15 minutes. The Scrum Guide states that “the Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.”

The best answer is B. The Developers on the Scrum Team should write the user documentation. According to the Scrum Guide, the Definition of Done creates transparency and ensures that the product Increment meets the quality standards required for the product 1 . If user documentation is part of the Definition of Done, then it should be completed within the Sprint by the Scrum Team 1 . The Scrum Team should have all the skills needed to deliver the product, and if user documentation is part of the product, then that skill should be on the team as well 2 . The Developers on the Scrum Team are responsible for creating a plan for delivering the Increment, which includes user documentation 1 . They can also ask for help from other more experienced writers outside the team, or learn the skill through training or workshops 2 . The other options are not consistent with the Scrum values and principles, as they would create dependencies, delays, and waste in the product development process.

The correct answer is D because every Sprint, including the first Sprint, should result in at least one valuable and useful Increment. Scrum is based on empiricism and incremental delivery. That means the team should not spend the first Sprint only on planning, documenting, or designing future work. Instead, they should create something usable that moves the product forward and provides an opportunity for inspection and adaptation.

Option A is incorrect because Scrum does not require detailed upfront analysis and documentation for later Sprints before producing value. Option B is incorrect because while some architecture and feature thinking may happen, Scrum does not make large upfront design the objective of the first Sprint. Option C is incorrect because Scrum avoids trying to fully plan the whole project in advance in complex environments. Instead, planning evolves over time as the team learns.

The key Scrum expectation is that each Sprint produces an Increment that meets the Definition of Done. This allows stakeholders to inspect real progress, provides early feedback, and reduces risk. The first Sprint is not an exception. It should deliver something useful, even if small, to begin empirical product development immediately.

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 Guide 1 , the Sprint Review is an informal meeting at the end of the Sprint, where 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 what to do next. 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; and the Development Team demonstrates the work that it has “Done” and answers questions about the Increment. The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning. The Sprint Review is mainly an inspect and adapt opportunity for the Scrum Team and stakeholders.

The two effective ways for the Scrum Team to make non-functional requirements visible are C and D.

C. Add them to the Definition of Done so the work is taken care of every Sprint.

The Definition of Done (DoD) is a shared understanding of what it means for a Product Backlog item to be complete and potentially releasable 1 . The DoD can include non-functional requirements that apply to the entire product or system, such as performance, security, usability, etc. By adding them to the DoD, the Scrum Team ensures that they are met every Sprint and that the quality of the product is maintained 2 .

D. Add them to the Product Backlog to ensure transparency.

The Product Backlog is an ordered list of everything that is known to be needed in the product 1 . The Product Backlog can include non-functional requirements that are specific to certain features or functionalities, such as response time, availability, scalability, etc. By adding them to the Product Backlog, the Scrum Team ensures that they are visible to all stakeholders and that they are prioritized and refined along with the functional requirements 3 .

A and B are not effective ways for the Scrum Team to make non-functional requirements visible.

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

This approach does not make non-functional requirements visible, but rather postpones them until the end of the Sprint. This can lead to incomplete or low-quality Increments that do not meet the expectations of the customers or users. Moreover, this approach does not account for any changes or feedback that may occur during the Sprint 4 .

B. Put them on a separate list on the Scrum board, available for all to see.

This approach does not make non-functional requirements transparent, but rather isolates them from the functional requirements. This can lead to confusion or inconsistency in how they are handled by the Scrum Team. Moreover, this approach does not align with the principle of having a single source of truth for the product requirements, which is the Product Backlog 5 .

The correct answer is A, because the role of management in Scrum is to facilitate the Scrum Teams with insights and resources that help them improve. The Scrum Guide states that “the organization respects their self-organization by not telling them how they should do their work.” Therefore, management should support the Scrum Teams by providing them with an environment that fosters collaboration, learning, and innovation.

Two techniques that would be most helpful in this situation are to discuss the impediments with the Development Team, and to prioritize the list and work on them in order, as stated in [3]: “The Scrum Master should facilitate a discussion with the Development Team to identify and prioritize the impediments that are blocking their progress. The Scrum Master should then work with the Development Team and other stakeholders to remove or mitigate these impediments as soon as possible.”

The correct answer is B because in Scrum, Developers are collectively accountable for creating a usable Increment every Sprint, and they share accountability for the Sprint Backlog. Scrum emphasizes self-management and collective ownership rather than assigning individual accountability for separate backlog items in the traditional sense. The Developers decide how to turn selected Product Backlog items into an Increment and how to organize their work, but the responsibility remains shared across the team.

This shared accountability supports collaboration, flexibility, and focus on the Sprint Goal. It prevents siloed behavior where individuals protect only their own tasks instead of working together to achieve the Sprint outcome. The Sprint Backlog is created by and for the Developers, and they adapt it throughout the Sprint as more is learned.

Option A is incorrect because accountability does not begin during the Daily Scrum. Option C is incorrect because capacity does not create individual ownership in Scrum. Option D is incorrect because Scrum does not require even task splitting or pre-assigned ownership at Sprint Planning. The Developers remain collectively accountable throughout the Sprint.

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

According to the Scrum Guide, 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. Users and customers are not roles on the Scrum Team, but they are stakeholders who may provide feedback and input to the product.

The correct answer is B, because the guideline that a Scrum Master should give is that estimates are made by the Development Team. 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 should estimate the work in Scrum, using any method or unit they prefer.

 According to the Scrum Guide, the time-boxed events in Scrum are Sprint Retrospective, Sprint Planning, and Daily Scrum. These events have a maximum duration that cannot be exceeded. The other options are not time-boxed events in Scrum, as they are either not part of Scrum (such as Release Planning, Release Retrospective, Sprint Testing, and Sprint 0) or not events at all (such as Definition of Done).

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, 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 security is part of product quality and should be addressed within the Scrum Team’s ongoing work, not delegated away or deferred to a later phase. Option B is correct because security concerns can and should be made visible in the Product Backlog when there is specific work needed to address them. This ensures transparency and allows the team to inspect, prioritize, and act on those concerns as part of product development.

Option C is also correct because if security is necessary for an Increment to be complete and releasable, it belongs in the Definition of Done. This ensures that security expectations are consistently applied every Sprint rather than treated as optional or postponed.

Option A is incorrect because Scrum does not rely on handing responsibility to a separate department. Option D is incorrect because delaying security work undermines transparency and increases risk. Option E is incorrect because security should not be isolated into one future Sprint as a separate cleanup effort. Scrum promotes integrating quality, including security, continuously into development so each Increment is usable and meets appropriate standards.

The correct answer is C, because if necessary, the Development Team is responsible for removing a team member who is creating a hostile environment. The Scrum Guide states that “development Teams 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.” Therefore, the Development Team should manage its own composition and dynamics, and may need help from the Scrum Master to facilitate this process.

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 Scrum Master and Product Owner may attend as observers, but only if it is useful for the Developers.

According to the Scrum Guide, the Product Owner can cancel a Sprint, as he or she is responsible for maximizing the value of the product and the work of the Development Team. The other roles do not have this authority, although they may provide input and suggestions to the Product Owner.

The correct answer is B, because the Development Team is responsible for managing the progress of work during a Sprint. The Scrum Guide states that “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.”

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

According to the Scrum framework, the Product Owner is responsible for managing the Product Backlog, which includes prioritizing and adding new items1. However, when a new item is introduced during a Sprint, it is crucial to involve the entire Scrum Team in the decision-making process. This ensures that the team can assess the impact of the new item on the current Sprint goals, capacity, and workload1. By discussing the item with the team, they can collectively decide whether to include it in the current Sprint, defer it to a future Sprint, or handle it in another way1. This collaborative approach aligns with the principles of transparency, inspection, and adaptation, which are core to Scrum.

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

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

The correct answer is C, because the Development Team should inform the Product Owner so he/she can work with the CEO. The Scrum Guide states that “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.” Therefore, if the CEO wants to add a “very important” item to a Sprint that is in progress, he or she should communicate with the Product Owner, who can then decide whether to cancel or continue the current Sprint.

The correct answer is C, because the Scrum Guide states that “the Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.” Therefore, enough work should be defined during the Sprint Planning event so that the Development Team can create its best forecast of what it can do, and to start the first several days of the Sprint.

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

According to the Scrum Guide, the Product Owner has the final say on the order of the Product Backlog, as he or she is responsible for maximizing the value of the product and the work of the Development Team. The other roles do not have this authority, although they may provide input and suggestions to the Product Owner.

The correct answer is B, because the Product Owner does not make sure the team selects enough from the Product Backlog for a Sprint to satisfy the stakeholders. 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 Guide, the Developers are accountable for managing the progress of work during a Sprint, 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 the Product Owner, the Scrum Master, or the most junior member of the team are accountable for managing the progress of work, which is not consistent with Scrum.

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

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 Scrum Master should talk to the IT manager and explain that progress in Scrum comes from inspecting an Increment at the Sprint Review, as stated in [5]: “The Scrum Master should educate the IT manager about how Scrum works and how progress is measured. The Scrum Master should invite the IT manager to attend the Sprint Review where the Development Team demonstrates what was accomplished during the Sprint. The Scrum Master should also explain that status reports are not necessary in Scrum, as transparency is ensured by using artifacts such as Product Backlog, Sprint Backlog, and Increment.”

According to the Scrum Guide 1 , 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. Therefore, a good way to continue is for the Development Team to make sure that all of the selected scope per Sprint is as “Done” as possible. The undone work is estimated and added to the Sprint Backlog of the next Sprint, so it doesn’t mess up the Product Backlog.

The correct answers are B and D, because these are the most appropriate responses for the Scrum Master. The Scrum Master should coach the team on why the Daily Scrum is important as an opportunity to update the plan, inspect the progress, and synchronize the activities of the Development Team. The Scrum Master should also learn why the Development Team wants this and work with them to improve the outcome of the Daily Scrum, rather than imposing a decision or accepting their request without question.

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 Guide 1 , each Sprint is a project with no more than a one-month horizon. The Sprint Goal gives guidance to why the Scrum Team is building an Increment. 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. Therefore, in the first Sprint, as in any other Sprint, the Development Team should develop at least one piece of functionality and create an increment of potentially releasable software. The other options are not consistent with Scrum values and principles.

According to the Scrum Guide, the Product Owner must participate in the Daily Scrum when he or she is actively working on items on the Sprint Backlog; however, they participate as a Developer, not as an authority figure. This means that the Product Owner can share progress, plans, and impediments with the other Developers and collaborate with them on delivering value. The other options are not valid reasons for the Product Owner to participate in the Daily Scrum, as they are either irrelevant (such as representing stakeholders or discussing impediments) or inappropriate (such as being asked by the Scrum Master).

According to the Scrum Guide, the Product Owner is accountable for clearly expressing Product Backlog items, as he or she is responsible for managing and prioritizing the Product Backlog. The other options are not valid, as they imply that the Product Owner can be replaced by a business analyst, or that the Scrum Master or the Developers can express the Product Backlog items.

When a Development Team determines that it will not be able to finish the complete forecast, both the Product Owner and the Development Team have to be present when reviewing and adjusting the Sprint work selected, as stated in [6]: “If there is not enough work remaining for all members of a Development Team then they can renegotiate scope with their Product Owner. If there is too much work remaining then they can also renegotiate scope with their Product Owner.”

The correct answer is A, because the Scrum Guide states that “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.” Therefore, a Development Team cannot cancel a Sprint by itself.

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

 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 required 1 2 .  The Scrum Team’s goal is to deliver a “Done” Increment that meets the Definition of Done and the Sprint Goal 3 .

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

The correct answers are B, C, and D, because moving away from component teams toward feature teams may involve some challenges and trade-offs. Productivity may suffer when making this kind of move, as teams need to learn new skills, coordinate with other teams, and deal with legacy code. Getting support from the business side first helps, as they can provide the vision, value, and feedback for the features. Feature teams have less communication overhead, as they can deliver end-to-end functionality without depending on other teams.

According to the Scrum Guide 1 , the Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization. The Scrum Master serves the Developers in several ways, including:

Coaching them in self-management and cross-functionality;

Helping them to create high-value products;

Removing impediments to their progress;

Facilitating Scrum events as requested or needed; and,

Coaching them in organizational environments in which Scrum is not yet fully adopted and understood.

The Scrum Master serves the Product Owner in several ways, including:

Helping find techniques for effective Product Goal definition and Product Backlog management;

Helping the Scrum Team understand the need for clear and concise Product Backlog items;

Helping establish empirical product planning for a complex environment; and,

Facilitating stakeholder collaboration as requested or needed.

The Scrum Master serves the organization in several ways, including:

Leading, training, and coaching the organization in its Scrum adoption;

Planning and advising Scrum implementations within the organization;

Helping employees and stakeholders understand and enact an empirical approach for complex work; and,

Removing barriers between stakeholders and Scrum Teams.

Therefore, two things that are true about the Scrum Master role are:

The Scrum Master teaches the Development Team to keep the Scrum meetings to their time-box, as they help everyone understand Scrum theory and practice.

The Scrum Master helps those outside the team interact with the Scrum Team, as they serve both the Product Owner and the organization.

The other options are not true about the Scrum Master role, as they imply that they have authority or responsibility over things that are not within their accountability.

According to the Scrum Guide, the Scrum Team should make sure that everyone on the team does their tasks for the Sprint, as they are collectively accountable for creating valuable Increments that meet stakeholder needs and expectations. The other options are not valid, as they imply that someone else outside the Scrum Team (such as a project manager) or another role on the Scrum Team (such as the Product Owner or the Scrum Master) is responsible for making sure that everyone does their tasks for the Sprint.

According to the Scrum Guide, a Scrum Team is cross-functional if it includes skilled individuals who together have all the skills necessary to create value each Sprint. This means that the Developers can work on any aspect of the product without depending on others outside the team. The other options are not valid descriptions of cross-functionality, as they either imply that the Developers work in silos or rely on external people (such as business analysts, architects, testers, or separate teams).

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 backlogs 1 .  NFRs are persistent qualities and constraints typically revisited as part of the definition of done (DoD) for each Iteration, PI, or release 1 . 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 1 , 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.

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

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.

 According to the Scrum Guide 1 , 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. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization. Therefore, an appropriate action for the Scrum Master to take if the Product Owner is struggling with ordering the Product Backlog is to offer the Product Owner help in understanding that the goal of ordering the Product Backlog is to maximize value.

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 correct answer is A, because if two Scrum Teams are added to the development of a product that previously had only one Scrum Team, the immediate impact on the productivity of the original Scrum Team is likely to decrease. This is because adding more teams may introduce some challenges and trade-offs, such as increased communication and coordination overhead, reduced alignment and cohesion, and potential conflicts or dependencies.

According to the Scrum Guide 1 , Scrum promotes self-organization by giving autonomy and empowerment to the Developers who decide how to do their work within a Sprint. The Developers have no titles other than Developer, regardless of their specialization or skills. Scrum is a lightweight framework that minimizes prescription and maximizes flexibility and adaptability.

The best answer is B. A valuable, useful Increment that meets the Definition of Done.

According to the Scrum Guide 1 , “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.” The Scrum Guide also states that “work cannot be considered part of an Increment unless it meets the Definition of Done. The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.”

Therefore, a Scrum Team should deliver a valuable, useful Increment that meets the Definition of Done at the end of each Sprint. This ensures that the product is potentially releasable and that the stakeholders can inspect and provide feedback on it.

A, C, and D are not correct answers.

A. A single document, if that is what management asked for.

This answer does not reflect the Scrum values of commitment, focus, and respect 1 . A Scrum Team should not deliver a single document just because management asked for it, but rather deliver an Increment that provides value to the customers and users. A document may be part of an Increment, but it is not an Increment by itself.

C. Failing unit tests, to identify acceptance tests for the next Sprint.

This answer does not reflect the Scrum principle of empiricism 1 . A Scrum Team should not deliver failing unit tests, but rather deliver an Increment that is thoroughly verified and meets the quality standards. Failing unit tests indicate that the work is not done and that there are defects or errors in the product. A Scrum Team should use unit tests to ensure that the product works as expected and to identify and fix any issues before delivering the Increment.

D. An Increment of software with minor known bugs in it.

This answer does not reflect the Scrum value of openness 1 . A Scrum Team should not deliver an Increment of software with minor known bugs in it, but rather deliver an Increment that meets the Definition of Done and is free of any known defects or issues. Delivering an Increment with bugs in it can compromise the trust and satisfaction of the stakeholders and can lead to technical debt or rework in the future. A Scrum Team should strive to deliver high-quality products that meet or exceed the expectations of the customers and users.

If the Development Team cannot complete its work by the end of the Sprint, then the Sprint length holds and the Development Team continuously learns what is actually possible to do within a Sprint of this length, as stated in [7]: “If a Development Team determines it has overcommitted itself for a Sprint, one option is to collaborate with the Product Owner to negotiate removing or reducing scope. Another option is to simply work hard and do its best, without cutting quality or pressuring individuals. In either case, the Development Team learns from its experience and uses this learning when planning future Sprints.”

The correct answer is C. Scrum defines accountabilities for product value, team effectiveness, and creating Done Increments, but it does not give the Scrum Master, Product Owner, or Scrum Team formal managerial authority to hire or fire people. Personnel decisions such as removing someone from a team are typically the responsibility of the organization and its management structure. In this case, the hiring manager or appropriate people manager would be responsible for removing the Developer if that becomes necessary.

Option A is incorrect because although the Scrum Master helps remove impediments, that does not mean they have authority over employment or staffing decisions. Option B is incorrect because the Product Owner is accountable for maximizing product value, not for personnel management. Option D is incorrect because the Scrum Team is self-managing with respect to its work, but it does not generally have organizational authority to remove employees from the team.

The Scrum Master should still help the team address the conflict by coaching, facilitating conversations, and improving collaboration. But if actual removal is required, that action belongs to the organization’s management system, not to a Scrum accountability.

According to the Scrum Guide, the purpose of a Sprint is to produce a valuable useful Increment that meets the Definition of Done and the Sprint Goal. This means that the Developers work on items from the Product Backlog that deliver value to the stakeholders and align with the product vision. The other option is not valid, as it implies that producing an Increment is not the purpose of a Sprint.

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.

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 Guide 1 , the Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.

According to the Scrum Guide 1 , 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 produce integrated Increments that are potentially releasable, the best suited structure for Development Teams is to develop functionality from beginning to end throughout all technical layers.

The correct answer is D. 10 or fewer. According to the Scrum Guide 2020 1 , “The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people.” The other options are outdated or incorrect. Option A was based on the previous version of the Scrum Guide, which suggested a range of 3 to 9 developers 2 . Option B is too vague and does not account for the upper limit of team size. Option C is too specific and does not allow for flexibility.

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

According to the Scrum Guide, the Developers do the work to make sure Product Backlog items conform to the Definition of Done, as they are responsible for creating a “Done” Increment that meets the Definition of Done. The other options are not valid, as they imply that the work is done by someone else outside the Development Team (such as Quality Assurance Team) or by another role on the Scrum Team (such as Product Owner or Scrum Master).

According to the Scrum Guide 1 , 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. The length of a Sprint should be short enough to keep the business risk acceptable to the Product Owner, short enough to be able to synchronize the development work with other business events, and no more than one calendar month.

According to the Scrum Guide 1 , 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. The key concern when multiple Development Teams are working from the same Product Backlog is minimizing dependencies between teams so that they can deliver an integrated Increment that meets the definition of “Done”.

The correct answer is B because as a Scrum Team matures, it is expected to strengthen its quality standards and improve its Definition of Done. The Scrum Guide explains that the Definition of Done creates transparency by making clear what it means for work to be complete. As the team becomes more capable, disciplined, and technically proficient, it often raises those standards to ensure higher quality, greater releasability, and more dependable Increments.

This improvement reflects empirical learning. A mature Scrum Team does not become less Scrum-like. It usually becomes more effective at applying Scrum. That means the team may refine engineering practices, strengthen testing, improve integration, and include more rigorous completion criteria in the Definition of Done.

Option A is incorrect because timeboxes do not expand simply because a team matures. Option C is incorrect because the Scrum Master remains accountable for Scrum effectiveness even with a mature team. Option D is incorrect because the Sprint remains a fixed timebox and a core element of Scrum. Option E is incorrect because Sprint Reviews continue to be essential for inspection and adaptation with stakeholders.

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 wo rk 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 the Scrum Guide states that “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.” Therefore, the main reason for the Scrum Master to be at the Daily Scrum is to ensure that it happens, but he or she does not have to be there.

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

The correct answers are B and D, because adding non-functional requirements to the Product Backlog and keeping the Product Owner posted on the expected effort helps prioritize and plan them in alignment with the product vision and goals. Additionally, adding non-functional requirements to the definition of ‘Done’ ensures that they are met every Sprint and do not accumulate technical debt.