PSM-I Professional Scrum Master I Questions and Answers

The correct answer is E, because all of these topics can be discussed during a Sprint Retrospective. The Scrum Guide states that “the purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. … During each Sprint Retrospective, the Scrum Team plans ways to improve product quality by adapting the definition of ‘Done’ as appropriate.” Therefore, the Scrum Team can discuss any aspect of their process, communication, skills, or definition of ‘Done’ that may help them improve.

According to the Scrum Guide, the Scrum Team is responsible for removing a Developer from the Scrum Team if necessary, as they are self-managing and accountable for creating valuable Increments. The other options are not valid, as they imply that someone else outside the Scrum Team has the authority to remove a Developer (such as the Scrum Master, the Product Owner, or the hiring manager), which is not consistent with Scrum values and principles.

The recommended size for a Scrum Team is 10 or fewer people, as stated in the Scrum Guide: “The recommended size of a Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people.”

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

References: Scrum Guide

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

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

References: Scrum Guide

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.

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

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

References: Scrum Guide

The correct answer is B, because a Product Owner is best described as a value optimizer. 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, a Product Owner should focus on delivering value to the customers and stakeholders through the product.

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

The correct answer is D, because the Scrum Guide states that “a Sprint is a container for all other events. Each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.” Therefore, a Sprint is over when its time-box expires, regardless of whether all Product Backlog items or tasks are completed or not.

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 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 product1. If user documentation is part of the Definition of Done, then it should be completed within the Sprint by the Scrum Team1. 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 well2. The Developers on the Scrum Team are responsible for creating a plan for delivering the Increment, which includes user documentation1. They can also ask for help from other more experienced writers outside the team, or learn the skill through training or workshops2. 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.

According to the Scrum Guide, a Scrum Team must release each Increment when it makes sense to do so, based on the value and feedback obtained from stakeholders. The decision to release an Increment is made by the Product Owner, who is responsible for maximizing the value of the product and the work of the Development Team. The other options are not valid, as they imply that releasing an Increment is either mandatory (such as after every Sprint), conditional (such as when the product is free of defects), or irrelevant (such as when the Scrum Team finishes their work).

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

Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.

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 answers are A, C, and E, because these are feedback loops in Scrum. The Sprint Review is a feedback loop that allows the Scrum Team and the stakeholders to inspect the Increment and adapt the Product Backlog. The Sprint Retrospective is a feedback loop that allows the Scrum Team to inspect itself and create a plan for improvements. The Daily Scrum is a feedback loop that allows the Development Team to inspect its progress and plan its work for the next 24 hours.

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

 According to the Scrum Guide, the Daily Scrum is held at the same time and same place to reduce complexity and promote consistency. The other options are not valid reasons for holding the Daily Scrum at the same time and same place, as they are either irrelevant (such as naming the place) or incorrect (such as being demanded by the Product Owner or booking rooms in advance).

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

References: Scrum Guide, Nexus Guide

The correct answer is A, because keeping component teams while starting Scrum may cause less initial disruption than organizing into new teams. As they start using Scrum, they will discover what works best for them and how to potentially re-organize towards feature teams. However, component teams may face some challenges in delivering a working Increment of software that provides business value every Sprint, as they may depend on other teams or layers.

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, a Sprint concludes when the Sprint Retrospective is complete. This is the last event of the Sprint cycle, where the Scrum Team inspects itself and creates a plan for improvements. The other options are not valid indicators of the conclusion of a Sprint, as they are either irrelevant (such as the Product Owner deciding enough has been delivered) or incomplete (such as all tasks or Product Backlog items being done).

The Developers determine how many Product Backlog items they select for a Sprint, as stated in the Scrum Guide: “The Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.”

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 correct answer is A, because Development Team membership should change as needed, while taking into account a short term reduction in productivity. The Scrum Guide states that “development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment; 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, changing Development Team membership may affect their cross-functionality and self-organization in the short term.

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

The Sprint Backlog is the Development Team’s plan for the Sprint, as stated in the Scrum Guide1: “The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint.”

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

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 amount of work required of the Developers to complete a Product Backlog item selected during the Sprint Planning is as much as is required to meet the Scrum Team’s Definition of Done. This means that the Developers must ensure that every item they work on is in a usable condition and meets all quality standards agreed upon by the team. The other options are not valid descriptions of the amount of work required, as they are either too vague (such as all development work and some testing or a proportional amount of time) or incorrect (such as fitting as much as possible or deferring work to the next Sprint).

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.

According to the Scrum Guide, management external to the Scrum Team is not involved in the Daily Scrum at all. The Daily Scrum is an internal event for the Development Team to inspect their progress toward the Sprint Goal and plan their work for the next 24 hours. The other options are not valid ways for management to be involved in the Daily Scrum, as they are either intrusive (such as giving an update or speaking on behalf of others) or unnecessary (such as being represented by the Product Owner or the Scrum Master).

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.

The correct answer is D, because if a new Development Team decides that a Sprint Retrospective is unnecessary, the Scrum Master should begin facilitating productive and useful Sprint Retrospectives. The Scrum Guide states that “the purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. … During each Sprint Retrospective, the Scrum Team plans ways to improve product quality by adapting the definition of ‘Done’ as appropriate.” Therefore, the Scrum Master should help the Development Team understand the value and importance of the Sprint Retrospective, and make it an engaging and constructive event.

According to the Scrum Guide, every Scrum Team should have the competencies and skills needed to deliver an Increment in a 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 what every Scrum Team should have, as they either imply that the Developers work in silos or rely on external people (such as a lead developer or representatives from different departments).

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

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

According to the Scrum Guide, a self-organizing Development Team chooses how to best accomplish its work, rather than being directed by others outside the team. The other options are not choices that a self-organizing Development Team makes, as they are either determined by the Scrum framework (such as Sprint length and Product Backlog ordering) or by collaboration with other roles (such as stakeholders for the Sprint Review and when to release).

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

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, 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 Developers can start with any one person and proceed in any order.

References: Scrum Guide

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf

Scrum is a framework for developing, delivering, and sustaining complex products. Scrum has three roles: the Product Owner, the Scrum Master, and the Developers. The Developers are the people in the Scrum Team who are committed to creating any aspect of a usable Increment in each Sprint. The Developers are not limited by titles such as programmer, designer, tester, architect, engineer, etc. The Developers are responsible for all aspects of quality, including finding and fixing bugs, tracking quality metrics, and verifying the work of other Developers. Therefore, Scrum has no “tester” role, and the Developers are responsible for quality.

The Product Owner is responsible for engaging the stakeholders, as stated in the Scrum Guide1: “The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.”

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.

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, implementation of a Product Backlog item is considered complete when the item has no work remaining in order to be potentially released.

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

The correct answer is D, because the recommended size for a Development Team is 3 to 9 members. The Scrum Guide states that “fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to be useful.”

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

References: Scrum Guide

The correct answer is B, because the time-box for the Sprint Planning meeting is 8 hours for a monthly Sprint. The Scrum Guide states that “Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.”

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

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.

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

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.

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

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

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

 According to the Scrum Guide1, Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.

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 Scrum Master should ask the person to share the issue with the team as soon as possible, as stated in [5]: “The Scrum Master should encourage transparency and collaboration within the team and with other stakeholders. If there is a concern about data security issues, it should be brought up to the team and discussed openly. The team can then decide how to handle it, whether by creating a Product Backlog item, updating the definition of “Done”, or taking some other action.”

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

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.

According to the Scrum Guide, the Product Owner has the final decision about the order of items in 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.

All of the above topics should be discussed in the Sprint Review, as stated in [4]: "The purpose of this meeting is to inspect what was delivered during this sprint and adapt what we want to deliver next. This means we will discuss three things:

What did we do this sprint?

How did we do it?

What do we want to do next?"

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

Correct Answer: C and E

Short Explanation: According to the Scrum Guide 20201, the product has one Product Backlog, which is the single source of work undertaken by the Scrum Team. The Product Backlog is ordered by the Product Owner, who is accountable for maximizing the value of the product resulting from the work of the Scrum Team. There should be only one Product Owner per product, who may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner1. Having multiple Product Owners or Product Backlogs would create confusion, inconsistency, and waste in the Scrum process.

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.

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.

According to the Scrum Guide1, one aspect of Scrum Teams inspecting how they work toward their Product Goal is that they improve their definition of “Done” over time. 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. Therefore, it is most appropriate for a Development Team to change the definition of “Done” during the Sprint Retrospective.

References: Scrum Guide

A Developer is accountable for creating a plan for the Sprint, the Sprint Backlog, and organizing the work required to meet the Sprint Goal, as stated in the Scrum Guide: "Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:

Creating a plan for the Sprint, the Sprint Backlog;

Instilling quality by adhering to a Definition of Done;

Adapting their plan each day toward the Sprint Goal; and,

Holding each other accountable as professionals."

The correct answer is D, because there is no gap between Sprints in Scrum. The Scrum Guide states that “a new Sprint starts immediately after the conclusion of the previous Sprint.” Therefore, there is no time required after a Sprint to prepare for the next Sprint.