Scrum PSM-II Professional Scrum Master level II (PSM II) Exam Practice Test

Scrum is a framework for addressing complex adaptive problems, such as product development, that require empirical process control and frequent inspection and adaptation. Scrum helps to mitigate the risks of:

• The timescale of the planned work (A), by delivering potentially releasable increments of value at the end of each Sprint, which is a fixed time-box of one month or less.
• The stability and complexity of the technology (B), by allowing the Development Team to self-organize and choose the best way to create a “Done” increment that meets the Definition of Done.
• The complexity and unpredictability of the requirements ©, by enabling the Product Owner to manage the Product Backlog, which is an ordered list of what is needed in the product and can change as more is learned about the product, users, market, and technology.
• The skills and working relationships of the people on the teams (D), by fostering a culture of collaboration, transparency, and accountability among the Scrum Team members and stakeholders.

References: : [Scrum Guide], Introduction : [Scrum Guide], The Sprint : [Scrum Guide], The Development Team : [Scrum Guide], The Product Backlog : [Scrum Guide], Scrum Values

• This is a good option because the Scrum Master’s role is to help the Scrum Team understand and apply the Scrum framework and its principles12. The Scrum Master should also facilitate and enable the team’s self-organization and collaboration12. By coaching the Scrum Team, the Scrum Master can help them realize that the Daily Scrum is not a status update or a performance review, but a time to inspect and adapt their progress toward the Sprint Goal3 . D. Tell the Product Owner your concerns about how his behavior may impact the Developers, and ask him to stop attending the Daily Scrum for some time.
• This is another good option because the Scrum Master’s role is to protect the Scrum Team from external interference and distractions12. The Scrum Master should also coach the Product Owner on how to maximize the value of the product and collaborate effectively with the Developers12. By telling the Product Owner your concerns, you can help him understand that his behavior may create pressure, dependency, or resentment among the Developers, which can harm their motivation, creativity, and autonomy . By asking him to stop attending the Daily Scrum for some time, you can give the Developers some space to self-manage their work and communication.

References: 1: What is a Scrum Master? | Scrum.org 2: What is a scrum master? [+ Responsibilities] | Atlassian 3: What’s the role of the Product Owner at the Daily Scrum? | by Maarten Dalmijn | Serious Scrum | Medium : Scrum Guide | Scrum Guides : Product Owner’s Role in a Daily Scrum: How to Support the … - Eleken : The Power of Intrinsic Motivation - Forbes

A Product Backlog item is a description of a feature or functionality that adds value to the product. It is selected by the Scrum Team during the Sprint Planning, based on the Product Owner’s proposal and the Developers’ forecast. It is expected that the Product Backlog item will be completed by the end of the Sprint, meaning that it meets the Definition of Done, which is a formal description of the state of the Increment when it meets the quality standards required for the product.

However, if a Product Backlog item is not completed by the end of the Sprint, meaning that it does not meet the Definition of Done, then:

• The item is not included in the Increment for this Sprint (B), which is a valid option as it ensures that only “Done” work is delivered to the customer and stakeholders. The Increment is a concrete and usable outcome of a Sprint that provides value and feedback. It should not contain any undone or partially done work that may compromise its quality, usability, or value.
• It is put on the Product Backlog for the Product Owner to decide what to do with it (D), which is another valid option as it respects the authority and accountability of the Product Owner to manage the Product Backlog, which is an ordered list of what is needed in the product. The Product Owner can decide whether to re-prioritize, re-estimate, refine, or remove the incomplete Product Backlog item based on new insights and stakeholder needs.

The other options are not correct because they:

• Review the item, add the done part of the estimate to the velocity and create a Story for the remaining work (A), which is not a good option as it violates the principle of commitment and transparency that underlies the Definition of Done. The Scrum Team should not count or report any work that is not “Done” as part of their progress or performance. The Scrum Team should also not split or create new Product Backlog items during or after the Sprint, as this may affect their alignment and focus on the Sprint Goal.
• Only the stakeholders decide over acceptance of undone work and whether to release it ©, which is not a good option as it violates the role and responsibility of the Product Owner and the Developers to deliver a potentially releasable Increment at the end of each Sprint. The stakeholders can provide feedback and suggestions for the product, but they cannot accept or release any work that does not meet the Definition of Done.

References: : [Scrum Guide], The Product Backlog : [Scrum Guide], The Definition of Done : [Scrum Guide], The Increment : [Scrum Guide], The Sprint Planning : [Scrum Guide], The Product Owner : [Scrum Guide], The Developers

The complexity of the problem being solved and the complexity of the requirements are both sources of uncertainty and variability that can impact the Sprint Goal and the Sprint Backlog. The skills and working relationships of the people on the Scrum Team(s) are also crucial for delivering a valuable product increment in a Sprint. The Scrum Master is accountable for establishing an environment where the Scrum Team can be effective and improving the professionalism of the Scrum Team.

References:

• Scrum Guide 2020, page 6: “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.”
• Scrum Guide 2020, page 10: “The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog items. This provides guidance to the Development Team on why it is building the Increment.”
• Scrum Guide 2020, page 11: “The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).”
• Evidence-Based Management Guide, page 9: “Uncertainty is inherent in complex work. The more complex work is, the more uncertainty there is. Uncertainty comes from two sources: variability and emergence.”

B. You explain that technical risks are best controlled when architecture and infrastructure emerge alongside the development of functionality. The additional advantage is that business value is created faster and sooner.

• This is a good option because it is consistent with the Scrum principle of empiricism, which means that the Scrum Team learns and adapts based on the actual outcomes and feedback, rather than following a predefined plan12. By allowing the architecture and infrastructure to emerge iteratively and incrementally, the Scrum Team can address the most important and uncertain aspects first, and deliver valuable and functional increments every Sprint34. D. You educate the Product Owner to add this work to the Product Backlog to uphold transparency. Ask the Developers to plan work during the first several Sprints to estimate these items, while also creating some business functionality in these early Sprints
• This is another good option because it is consistent with the Scrum value of transparency, which means that the Scrum Team and the stakeholders have a clear and common understanding of the product vision, goals, progress, and risks12. By adding this work to the Product Backlog, the Product Owner can prioritize and refine it according to the value and urgency, and communicate it to the stakeholders. By asking the Developers to plan work during the first several Sprints, they can estimate these items based on their actual experience and capacity, while also delivering some business functionality in these early Sprints34.

The Definition of Done is a formal description of the state of the Increment when it meets the quality standards required for the product. The purpose of the Definition of Done is to:

• During the Sprint, it helps the Developers identify the work remaining for an Increment to be ready for release by the end of a Sprint (B), by providing a clear and shared understanding of what “Done” means for each Product Backlog item and the Increment as a whole.
• It creates transparency into the state of the Increment when it is inspected at the Sprint Review ©, by ensuring that everyone involved in the product development has the same expectations and criteria for evaluating the value, usability, and quality of the Increment.
• It guides the Developers when creating a forecast at the Sprint Planning (D), by enabling them to estimate how much work they can realistically complete within a Sprint, based on their capacity, skills, and Definition of Done.

References: : [Scrum Guide], The Definition of Done : [Scrum Guide], The Increment : [Scrum Guide], The Sprint Review : [Scrum Guide], The Sprint Planning

Short Explanation: Scrum is a framework for delivering value to customers and stakeholders in an iterative and incremental way. Scrum does not prescribe how project budgeting and financial forecasting should be performed, but it does provide some principles and practices that can help with this process.

One of these principles is that each Sprint should produce a potentially releasable product Increment that delivers value and meets the Definition of Done. This means that several Sprints may be funded as a single release, with the result of each Sprint being releasable product12. This allows the Product Owner to decide when to release the product based on the feedback from the customers and stakeholders, and the market conditions.

Another principle is that Scrum promotes transparency, inspection, and adaptation. This means that the budgeting and forecasting process should be revisited as frequently as each Sprint to ensure value is being delivered for the investment spent13. This allows the Scrum Team to inspect the outcomes of the delivered Sprint Increments, compare them with the expected benefits and costs, and adapt the product backlog and the release plan accordingly.

Scrum does not align with traditional accounting practices that require fixed scope, cost, and time. However, this does not mean that Scrum Teams do not need a budgeting process or that they only need to cover the run cost (time and materials) of the Scrum Teams. Scrum Teams still need to estimate the size and value of the product backlog items, forecast the delivery date and cost of the product or release, and track the actual spending and revenue of the product or release43. The difference is that these estimates and forecasts are based on empirical data from previous Sprints, rather than on upfront assumptions or guesses. They are also subject to change as new information emerges or new requirements arise.

References:

• Scrum Guide 2020, section “The Sprint”, “The Increment”, “Empiricism”.
• Tips for Effective Agile Budgeting and Forecasting | Toptal®, section “Establish Context and Set Expectations”, “Budget for Value”.
• Project forecasts and budgets | Microsoft Learn, section “Project forecasting”.
• Planning and Budgeting in Scrum Projects - PMHut, section “Budgeting in Scrum Projects”.

The best two answers are A and C.

A. Timeboxing work to allow for frequent inspection. This is a relevant boundary for self-management provided by the Scrum framework, as it helps the Scrum Team to organize their work into fixed-length Sprints and other events, such as the Daily Scrum, the Sprint Planning, the Sprint Review, and the Sprint Retrospective. Timeboxing enables the Scrum Team to inspect their progress, adapt their plan, and deliver value regularly and predictably.

C. Creating a valuable and useful Increment by the end of each Sprint. This is also a relevant boundary for self-management provided by the Scrum framework, as it guides the Scrum Team to focus on delivering a product Increment that meets the Sprint Goal and the Definition of Done. Creating a valuable and useful Increment requires the Scrum Team to collaborate, communicate, and coordinate effectively, and to apply their skills and creativity to solve complex problems.

References:

• The Scrum Guide, section 2.3 (The Scrum Team), page 7
• The Scrum Guide, section 3.1 (The Sprint), page 8
• The Scrum Guide, section 3.4 (The Increment), page 10
• The Scrum Master Learning Path, module 2 (The Scrum Framework), lesson 2 (The Sprint), lesson 3 (The Sprint Goal), lesson 4 (Sprint Planning) and lesson 5 (The Sprint Review)
• The Professional Scrum Master II (PSM II) Assessment, question 40

 As the Scrum Master, your role is to serve the Scrum Team by helping them to work effectively and deliver value. You are not responsible for managing the work or assigning tasks to the Developers. You should respect the self-organization and autonomy of the Developers, and support them in finding their own solutions to the problem. You should also facilitate collaboration and communication among the Developers and with other stakeholders.

Some reasons why option B is the correct answer are:

• Asking the Developers what value they get by having the Daily Scrum with all team members present and what might go wrong if all Developers do not attend. This action will help the Scrum Team to understand the purpose and benefits of the Daily Scrum, and to identify and address the risks and consequences of missing it. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work12. The Daily Scrum also provides an opportunity for the Developers to identify and communicate any impediments that are hindering their progress, and request help from the Scrum Master or other team members to resolve them12. The Daily Scrum improves communications, identifies impediments, promotes quick decision-making, and consequently eliminates the need for other meetings12. The Daily Scrum is not a status meeting, but a way for the Developers to collaborate and self-organize around the most important work for the next 24 hours12. If a Developer is missing the Daily Scrum, they may miss important information, feedback, or support from their peers, or they may cause delays, confusion, or conflicts for their team. The Scrum Master should encourage the Developers to share their perspectives and experiences on how the Daily Scrum helps them achieve their Sprint Goal and create a valuable Increment.
• The Scrum Master should also help the Developers to come up with their own solutions on how to ensure full attendance and participation in the Daily Scrum. The Scrum Master should not impose or dictate a solution, but rather coach and guide the Developers to find what works best for them. The Scrum Master should also help the Developers to agree on some ground rules or norms for their Daily Scrum, such as when, where, and how to conduct it, what topics to discuss, and how to handle any issues or conflicts that may arise.

Some reasons why the other options are not correct are:

• A: You do not intervene. The Developers own the Daily Scrum, so they should deal with any issues with attendance. This option is not correct because it violates the Scrum Master role. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide1, causing change that increases the productivity of the Scrum Team1, and working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization1. The Scrum Master should not ignore or avoid a problem that affects the performance or well-being of the Scrum Team, but rather help them address it in a constructive and respectful way. The Scrum Master should also not assume that the Developers know how to deal with any issues with attendance, but rather teach them how to do so effectively.
• C: Talk to the Developer who is missing the Daily Scrum and ask her to always attend the Daily Scrum. This option is not correct because it violates the Scrum framework and the Scrum Master role. The Daily Scrum is an event for and by the Developers12, not for reporting or accountability to anyone else. The Scrum Master should not interfere with or dictate how the Developers conduct their Daily Scrum, or make unilateral decisions on behalf of them. The Scrum Master should also not single out or confront a Developer who is missing the Daily Scrum, but rather involve all Developers in finding a solution that works for everyone.
• D: Teach the Developers how to deal with this situation by attending the Daily Scrum yourself. This option is not correct because it violates the Scrum framework and the Scrum Master role. The Daily Scrum is an event for and by the Developers12, not for anyone else’s inspection or intervention. The Scrum Master should not attend or participate in the Daily Scrum unless they are actively working on items in the Sprint Backlog12. The presence of an outsider may disrupt or influence the dynamics of the Developers’ communication and collaboration. The Scrum Master should also not teach by doing, but rather by coaching and facilitating.

References:

• What is a Daily Scrum? | Scrum.org
• What Is a Daily Standup? | A Guide to Running Effective Standup Meetings | Atlassian

• B: Productivity, in terms of lines of code or story points, will probably suffer during the transition, although even then delivery of business value is still likely to increase. This is a realistic expectation, as the teams will need to learn new skills, collaborate more effectively, and adapt to changing requirements. However, the benefit of feature teams is that they can deliver working software that provides value to the customers and stakeholders every Sprint, rather than waiting for the integration of different components.
• C: Feature teams will require time to become productive as people from the different layers and components become accustomed to working and delivering unified functionality together, as one Scrum Team. This is a natural consequence of changing the team structure and culture, as the teams will need to overcome some challenges and conflicts, build trust and rapport, and establish a shared vision and goal. The Scrum Master can help the teams with this transition by facilitating communication, coaching, and mentoring.

References:

• Professional Scrum Master II Course, page 17: “Feature teams are cross-functional teams that can deliver end-to-end functionality for a product. They have all the skills and competencies needed to work on multiple layers of the system.”
• Professional Scrum Master II Course, page 18: “Component teams are teams that specialize in one layer or component of the system. They often depend on other teams to deliver a complete functionality for a product.”
• Professional Scrum Master II Course, page 19: “Feature teams have many advantages over component teams, such as faster feedback, higher quality, lower complexity, and more customer value.”

C. They are added to the Product Backlog and addressed throughout the next Sprints, combined with creating the business functionality in those Sprints, no matter how small that business functionality.

• This is a good way because it is consistent with the Scrum principle of empiricism, which means that the Scrum Team learns and adapts based on the actual outcomes and feedback, rather than following a predefined plan12. By adding these security concerns to the Product Backlog, the Product Owner can prioritize and refine them according to the value and urgency, and communicate them to the stakeholders. By addressing them throughout the next Sprints, the Scrum Team can deliver valuable and functional increments that also meet the security requirements34. D. During the Sprint Retrospective, the Scrum Team assesses how to add these expectations to the Definition of Done so every future Increment will live up to these requirements. If needed they can work with external specialists to better understand the requirements
• This is another good way because it is consistent with the Scrum value of openness, which means that the Scrum Team and the stakeholders have a clear and common understanding of the product vision, goals, progress, and risks12. By adding these expectations to the Definition of Done, the Scrum Team can ensure that every future Increment meets the quality standards and satisfies the stakeholder needs. By working with external specialists, the Scrum Team can also leverage their expertise and experience to better understand and implement the security requirements34.

References: 1: Scrum Values | Scrum.org 2: Scrum Values - Atlassian 3: Scrum Guide | Scrum Guides 4: Scrum - What is it, how it works, & how to start - Atlassian

User documentation is part of your Definition of Done, which means that it is a requirement for delivering a potentially releasable product increment. Your Scrum Team cannot ignore or postpone this requirement, even if there are not enough technical writers for all teams. Your Scrum Team is responsible for creating and maintaining the user documentation, and the Developers are the ones who have the skills and authority to do so. The Scrum Master can help the Developers learn how to write effective user documentation, and the Product Owner can provide feedback on its quality and value.

References:

• Scrum Guide 2020, page 9: “The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.”
• Scrum Guide 2020, page 10: “The Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.”
• Professional Scrum Master II Course, page 12: “The Definition of Done is a crucial aspect of transparency. If it is not clear when work is done, then stakeholders may make wrong assumptions about the state of the software.”

During the Sprint Review of a scaled development effort, the Scrum Teams should demonstrate the integrated Increment that they have collectively delivered, not their individual Increments separately. This ensures that the stakeholders can provide feedback on the value and quality of the product as a whole, and that the Scrum Teams can inspect their alignment and collaboration.

References:

• Scrum Guide 2020, page 14: “The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.”
• Nexus Guide 2020, page 7: “The Nexus Sprint Review is an event where appropriate stakeholders review the Integrated Increment that has been built throughout the Sprint by all Scrum Teams in a Nexus.”

The Scrum Master should do this because it is the most effective way to ensure that the Scrum Teams are self-organizing, cross-functional, and collaborative. The Scrum Master can help the Scrum Teams to understand the benefits of working together as one integrated team, rather than as separate component teams. The Scrum Master can also facilitate the communication and coordination among the Scrum Teams, and support them in resolving any dependencies or conflicts that may arise.

References:

• Scrum Guide 2020, page 7: “Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value in each Sprint.”
• Scrum Guide 2020, page 7: “Scrum Teams are self-managing, meaning they internally decide who does what, when, and how.”
• Nexus Guide 2020, page 5: “When multiple Scrum Teams are working together on the same product, there are additional complexities that arise. These complexities can be reduced by having the teams adhere to a common definition of “Done” and a single Product Backlog.”

Splitting a team into two teams is a major decision that should not be taken lightly. It may have implications for the product vision, the product backlog, the sprint goal, the sprint backlog, the definition of done, and the team dynamics. It may also reduce the effectiveness of the Scrum Team by creating dependencies, communication overhead, and coordination challenges. Therefore, before considering such a drastic measure, it is advisable to explore other options to improve the quality and efficiency of the Daily Scrum. One option is to ask for help from another Scrum Master who can observe the Daily Scrum and provide feedback and suggestions.

References:

• The Scrum Guide, section 3.2 (The Daily Scrum), page 9
• The Scrum Master Learning Path, module 4 (The Daily Scrum), lesson 4 (Common Challenges) and lesson 5 (Tips for an Effective Daily Scrum)

 The best way to determine if the Product Owner is interacting with the Developers enough throughout a Sprint is to observe whether both parties are satisfied with the Increment. The Increment is a concrete stepping stone toward the Product Goal1. It must be usable and meet the Definition of Done1. The Product Owner is accountable for maximizing the value of the product resulting from the work of the Developers1. The Developers are accountable for creating a valuable, useful, and potentially releasable Increment every Sprint1. Therefore, if both the Product Owner and the Developers are happy with the quality and value of the Increment, it means that they have communicated and collaborated effectively throughout the Sprint.

Some reasons why the other options are not correct are:

• A: The Developers should determine the percentage of time the Product Owner is required to be present and monitor whether the Product Owner’s average presence is around this figure. This option is not correct because it implies that there is a fixed or optimal amount of time that the Product Owner should spend with the Developers, which may not be true. The Product Owner’s interaction with the Developers may vary depending on the context, complexity, and uncertainty of the product and the Sprint. The Scrum Guide does not prescribe any specific time or frequency for the Product Owner’s involvement with the Developers1. The Product Owner should be available to provide guidance and feedback to the Developers as needed, but not interfere with their self-organization and autonomy1.
• B: Check the Daily Scrum reports to see whether the Product Owner was present at the majority of the Daily Scrum meetings. This option is not correct because it assumes that the Daily Scrum is a meeting where the Product Owner should be present, which is not true. The Daily Scrum is an event for and by the Developers12, not for reporting or accountability to anyone else. The Product Owner may attend as an observer or a collaborator, but only if invited by the Developers12. The presence or absence of the Product Owner at the Daily Scrum does not indicate how much they interact with the Developers throughout the Sprint.
• C: Observe whether the Developers need to ask the Product Owner questions at times other than during the Daily Scrum. This option is not correct because it implies that asking questions is a sign of insufficient interaction, which may not be true. Asking questions is a natural and healthy part of communication and collaboration between the Product Owner and the Developers. It shows that they are engaged, curious, and willing to learn from each other. It also helps them to clarify requirements, expectations, and feedback, and to resolve any ambiguities or conflicts. Asking questions does not necessarily mean that there is a lack of interaction, but rather that there is a need for more information or clarification.

References:

• What is an Increment? | Scrum.org
• What Is a Daily Standup? | A Guide to Running Effective Standup Meetings | Atlassian

The Product Owner is responsible for maximizing the value of the product and the work of the Developers. The Product Owner is also accountable for managing the Product Backlog, which is an ordered list of what is needed in the product. The Product Owner should collaborate with the Developers and the stakeholders to create and refine the Product Backlog, as well as to define and communicate the product vision and goals. Therefore, as a Scrum Master, you should direct the new Product Owner towards focusing on:

• Building a good relationship with the stakeholders of the product (A), which is a valid option as it helps the Product Owner to understand and align with the changing organizational or market expectations, as well as to invite and receive feedback from the appropriate stakeholders during the Sprint Review, which is an event that inspects the outcome of the Sprint and determines future adaptations.
• Relying on others in the Scrum Team and the stakeholders to formulate the Product Backlog (D), which is another valid option as it helps the Product Owner to leverage the functional and business insights of the Developers and the stakeholders, who are more familiar with the product and the customer needs. By questioning them and working with them, the Product Owner will quickly become more productive and effective.

The other options are not correct because they:

• Inform the Product Owner that it is important that the Developers are updated on changing business priorities on a daily basis at the Daily Scrum (B), which is not a good option as it shows a misunderstanding of the purpose and format of the Daily Scrum, which is an event for the Developers to inspect their progress and plan their work for the next 24 hours, not a status report or a meeting for changing requirements or scope. The Product Owner should respect and support the Developers’ commitment to their Sprint Goal and Sprint Backlog, and only introduce changes that do not endanger them.
• Tell the Product Owner to make sure that there are no ambiguities or possible misunderstandings in the items on the Product Backlog by capturing the functional requirements during an analysis phase ©, which is not a good option as it shows a misunderstanding of the nature and process of the Product Backlog, which is a dynamic and emergent artifact that can change as more is learned about the product, users, market, and technology. The Product Owner should collaborate with the Developers to refine and clarify the Product Backlog items throughout the product development, not create detailed documents that are considered as final outputs of analysis Sprints.

References: : [Scrum Guide], The Product Owner : [Scrum Guide], The Product Backlog : [Scrum Guide], The Sprint Review : [Scrum Guide], The Scrum Master : [Scrum Guide], The Developers : [Scrum Guide], The Daily Scrum

• A: There is one Product Owner for each product (five in total). Each Product Owner may delegate to others for specific value, capabilities, and functionality within their product. The five Product Owners share and align work via Product Backlog. This is a reasonable alternative, as it allows each Product Owner to focus on one product and its vision, value proposition, and stakeholder needs. The Product Owner can also leverage the expertise and input of other people who can help with the product development, such as business analysts, domain experts, or user representatives. The five Product Owners can coordinate and collaborate with each other through the Product Backlog, which is a single source of truth for the product requirements and priorities.
• D: There is one Product Owner responsible for all five products. This person may delegate work to others for specific value, capabilities, and functionality within each product to scale their accountability. This is another reasonable alternative, as it allows one Product Owner to have a holistic view of the five products and their interdependencies, synergies, and trade-offs. The Product Owner can also delegate some of the work to other people who can act as proxies or representatives for the different aspects of the products, such as features, modules, or components. The Product Owner can still maintain the ultimate authority and responsibility for the Product Backlog and the product value delivery.

References:

• Scrum Guide 2020, page 7: “The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.”
• Scrum Guide 2020, page 8: “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.”
• Professional Scrum Master II Course, page 22: “The Product Owner may delegate some of their work to others who can help them with the product development, such as business analysts, domain experts, or user representatives. However, the Product Owner remains accountable for the Product Backlog and its content.”
• Professional Scrum Master II Course, page 23: “The Product Owner may scale their role by working with other Product Owners who are responsible for different products, features, modules, or components. However, there should be only one Product Owner per product who has the final say on the product vision and value proposition.”

A. Having one Product Owner will improve the clarity of accountability to the teams and to the product management department. This is a good suggestion, as it ensures that there is a single person who is responsible for maximizing the value of the product and managing the Product Backlog. Having one Product Owner also avoids confusion, duplication, or conflict among multiple Product Owners who may have different visions, priorities, or expectations for the product.

D. A single Product Backlog should be maintained holding all requirements for the new product. This is also a good suggestion, as it ensures that there is a single source of truth for the product requirements and that they are transparent and visible to all stakeholders. Having a single Product Backlog also enables the Product Owner to order the items based on their value, risk, dependency, and urgency, and to collaborate with the Scrum Teams to select and refine the items for each Sprint.

References:

• The Scrum Guide, section 2.3 (The Scrum Team), page 7
• The Scrum Guide, section 4.1 (The Product Backlog), page 11
• The Scrum Master Learning Path, module 2 (The Scrum Framework), lesson 4 (Sprint Planning) and lesson 5 (The Sprint Review)

Coach the Product Owner that achieving the Sprint Goal is the Scrum Team’s objective. A forecast is only used to initially estimate the effort required to reach the Sprint Goal.

• This is true because the Scrum Master’s role is to help the Product Owner understand the Scrum framework and its principles, such as empiricism, self-organization, and collaboration12. The Scrum Master should also remind the Product Owner that the forecast is not a commitment, but a plan that can be adjusted based on the Sprint progress and feedback3 . The Scrum Master should focus on the value and outcome of the Sprint, rather than the output and scope.

References: 1: What is a Scrum Master? | Scrum.org 2: What is a scrum master? [+ Responsibilities] | Atlassian 3: [Scrum Guide | Scrum Guides] : What Is a Scrum Master (and How Do I Become One)? - Coursera