PSM-II Professional Scrum Master level II (PSM II) Questions and Answers

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

This is the best answer because it empowers the Developers to take ownership of their own process and find a solution that works for them. The Scrum Master can facilitate the discussion and help the Developers understand the value and importance of the Daily Scrum, but not impose or dictate any specific action or rule. The Scrum Master can also support the Developers in conducting an experiment and evaluating the results, if they decide to do so.

References:

• Scrum Guide 2020, page 13: “The Scrum Master serves the Scrum Team in several ways, including coaching the team members in self-management and cross-functionality.”
• Professional Scrum Master II Course, page 14: “The Daily Scrum is a key opportunity for inspection and adaptation at the team level. It helps the team to synchronize their work, identify impediments, and collaborate on solutions.”
• Professional Scrum Master II Course, page 21: “The Scrum Master can help the team to resolve conflicts by facilitating dialogue, listening actively, asking powerful questions, and supporting collaborative decision making.”

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 Scrum values of courage, openness, and respect are touched in this situation. Courage means that the Scrum Team members have the courage to do the right thing and work on tough problems, and also to speak up when they have concerns or disagreements. Openness means that the Scrum Team members and stakeholders agree to be open about all the work and the challenges with performing the work. Respect means that the Scrum Team members respect each other to be capable, independent people, and also respect the opinions and ideas of others.

In this case, the newest developer showed courage by expressing his feelings during the Sprint Retrospective, which is an opportunity for the Scrum Team to inspect itself and create a plan for improvements. The rest of the Developers should have been more open to listening to his perspective and ideas throughout the Sprint, as they might have valuable insights or suggestions for improving the product or the process. The Developers should also have respected the newest developer as a member of the team, and given him a fair chance to contribute and collaborate with them.

References:

• The Scrum Guide, November 2020, p. 13-14
• What are the 5 Scrum Values?, Visual Paradigm, accessed on September 30, 2023
• Scrum Values Poster, Scrum.org, accessed on September 30, 2023

 Done means that the Increment is in a usable condition and meets the Scrum Team’s 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. The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. Having an Increment that could be released to end users means that it is potentially releasable, which is one of the goals of Scrum. All work performed meets the Definition of Done means that the Developers have ensured that every Product Backlog item selected for the Sprint conforms to the agreed quality standards.

References:

• The Scrum Guide, November 2020, p. 10-11
• What is a Definition of Done?, Scrum.org, accessed on September 30, 2023
• DONE Understanding Of The Definition Of "Done”, Scrum.org, December 16, 2019

 As a Scrum Master, you could help the Product Owner by suggesting working with the program manager and the project managers of the other components on the ordering and the value of your open Product Backlog items to redefine the possible delivery date. This would allow you to collaborate with the stakeholders and align on the expectations and priorities of the product. You could also inspect and adapt your integration process and communication channels with the other teams to minimize the impact of changes and dependencies.

References:

• The Scrum Guide 2020, section “The Scrum Master”
• The Scrum Master Learning Path, module “The Scrum Master as a Coach”
• The Professional Scrum Master II Course, topic “Stakeholder Management”

• A: Arrange one-on-one coaching sessions where concerns the Scrum Master has identified can be discussed. This is a good way to provide individual feedback and guidance to the Scrum Team members and other people involved in the Scrum process. The Scrum Master can help them overcome any challenges or misunderstandings they may have about Scrum.
• C: Schedule group training about Scrum. This is a good way to educate and inform a larger audience about the principles and practices of Scrum. The Scrum Master can use this opportunity to share their knowledge and experience with Scrum, and answer any questions or concerns that may arise.
• E: Educate stakeholders and customers about Scrum. This is a good way to ensure that the people who have a stake in the product or service understand the benefits and expectations of Scrum. The Scrum Master can help them appreciate the value of empirical feedback, transparency, and collaboration that Scrum provides.

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.”
• Professional Scrum Master II Course, page 8: “The role of the Scrum Master is to help everyone involved in creating products with Scrum to understand, apply, and improve upon the use of the framework.”

• This is the best answer because it is consistent with the Scrum Master’s accountability to educate and coach the Scrum Team and the organization on the Scrum framework and its principles12. By coaching the Product Owner and the Developers on the purpose of Scrum events, the Scrum Master can help them understand that the Daily Scrum is not a status report or a performance review, but a time to inspect and adapt their progress toward the Sprint Goal34. By letting them figure out how to deal with this situation, the Scrum Master can also respect and enable their self-organization and collaboration12.

The Scrum Guide states that “the moment a Product Backlog item meets the Definition of Done, an Increment is born” and that “the Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints”. Therefore, to deliver a product Increment that is integrated and potentially releasable, all Scrum Teams must have a shared understanding of what “Done” means and ensure that their work meets that standard. This also enables transparency, inspection, and adaptation across the Scrum Teams.

References:

• The Scrum Guide, section 3.4 (The Increment), page 10
• The Scrum Master Learning Path, module 5 (The Increment), lesson 1 (What is an Increment?) and lesson 2 (Definition of Done)

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

 User acceptance testing is a process of verifying that the product meets the user’s needs and expectations. It is an important feedback mechanism that helps the Scrum Team validate their assumptions, inspect the value and quality of the Increment, and adapt their plans accordingly. Scrum requires that the Increment be transparent, meaning that it is observable and understandable by anyone with a stake in the outcome. Scrum also requires that the feedback loop be short, meaning that the Scrum Team can receive and respond to feedback quickly and frequently.

Therefore, it is not a good idea to have user acceptance testing done every third Sprint, because:

• The Increment will not be transparent (B), meaning that the Scrum Team and the stakeholders will not have a clear and shared understanding of what has been done and what remains to be done. This may lead to misalignment, confusion, or conflict over the product vision, scope, and quality.
• The feedback loop is too long (B), meaning that the Scrum Team will not be able to inspect and adapt based on the user’s feedback in a timely manner. This may lead to wasted effort, missed opportunities, or reduced value delivery.

The other options are not correct because:

• It does not depend on what is stated in their Definition of Done (A), which is a formal description of the state of the Increment when it meets the quality standards required for the product. The Definition of Done does not dictate how or when user acceptance testing should be done, but rather what criteria must be met for the Increment to be considered “Done”.
• The Scrum Team is a self-managing team ©, which means that they have the autonomy and authority to organize and manage their own work within the boundaries of Scrum. However, this does not mean that they can ignore or postpone user feedback, which is essential for delivering value and satisfying customer needs.
• The Scrum Team needs stability in the Sprint (D), which means that they need to have a clear and consistent Sprint Goal, Sprint Backlog, and Definition of Done throughout the Sprint. However, this does not mean that they need to avoid or resist user feedback, which is a source of learning and improvement for the product and the process.

References: : [Scrum Guide], The Increment : [Scrum Guide], Transparency : [Scrum Guide], The Definition of Done : [Scrum Guide], The Scrum Team : [Scrum Guide], The Sprint Goal

 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, such as Phil and the Product Owner.

Some reasons why the other options are not correct are:

• A: Preparing the Sprint Backlogs each day for the teams so Phil can spend some time in each team. This option is not correct because it violates the Scrum framework and the Scrum Master role. The Sprint Backlog is owned and managed by the Developers, not by the Scrum Master. The Scrum Master should not interfere with or dictate how the Developers plan and execute their work. The Scrum Master should also not impose a solution that may not be optimal or feasible for the teams or for Phil.
• B: Allocate Phil to one team per Sprint, so that over four Sprints every team will have had the support it requires. This option is not correct because it violates the Scrum framework and the Scrum Master role. The Scrum Master should not allocate resources or assign tasks to the teams or to Phil. The Scrum Master should also not impose a solution that may not be aligned with the Product Owner’s priorities or the teams’ needs.
• D: Ask Phil for a plan to hire and train additional people in his domain, and in the meantime work with the Product Owner and Developers to re-prioritize the work so that tasks not depending on Phil can be done first. This option is not correct because it violates the Scrum framework and the Scrum Master role. The Scrum Master should not ask Phil to do something that may be beyond his authority or responsibility. The Scrum Master should also not work with the Product Owner and Developers to re-prioritize the work, as this is the Product Owner’s accountability. The Scrum Master should respect the Product Owner’s decisions on what is valuable and what is not, and support the Developers in delivering that value.

References:

• What is a Scrum Master? | Scrum.org
• What is a Sprint Backlog? | Scrum.org
• Who is responsible for dependency management? | Scrum.org
• [Managing Dependencies in Scrum - Scrum Alliance]

 The Product Owner is responsible for maximizing the value of the product resulting from the work of the Scrum Team1. One of the ways to do this is to order the Product Backlog in a way that reflects the flow of value to the stakeholders and customers2. The Product Owner can use various factors to order the Product Backlog, such as value, risk, dependencies, learning opportunities, and feedback loops3.

However, sometimes the Product Owner may face challenges or constraints that affect the ordering of the Product Backlog, such as external dependencies, market changes, technical issues, or stakeholder requests4. In such cases, the Product Owner needs to balance between delivering value and managing risks. The Product Owner may need to adjust the Product Backlog ordering to account for these factors, but not at the expense of compromising the value delivery5.

In this scenario, the Developers are waiting for an external supplier to deliver a specific product component that they need to integrate and use. Without that component there will not be enough work in the next Sprint to occupy the full team. They ask their Product Owner to re-order the Product Backlog. The Product Owner asks the Scrum Master for help. A good advice for the Product Owner would be to tell them that their primary concern is the flow of value reflected in the ordering of the Product Backlog. Timeline of the flow might be influenced by such dependencies and require some level of Product Backlog re-ordering.

This advice would help the Product Owner to focus on delivering value while also considering the impact of the external dependency. The Product Owner could work with the Developers and stakeholders to identify and prioritize other valuable work that can be done in the next Sprint without relying on the external component. The Product Owner could also communicate with the external supplier and try to minimize or eliminate the dependency as much as possible.

The other options are not good advice for the Product Owner. Telling them that they need to re-order the Product Backlog to maximize utilization of the Developers would imply that keeping productivity high is more important than delivering value. This would go against the Scrum values of focus and respect. Telling them to remove all work involving the external component from the Product Backlog and create a new backlog for it would imply that they are ignoring or avoiding the dependency rather than managing it. This would go against the Scrum values of courage and openness.

References:

• The Scrum Guide 2020, section “The Product Owner”
• What is a Product Backlog? | Scrum.org, section “Ordering”
• Product Backlog Ordering - Zen Ex Machina, section “Ordering by Value”
• Product Backlog Ordering - Zen Ex Machina, section “Ordering by Risk”
• Ordered Not Prioritized | Scrum.org, section “Ordering by Dependencies”
• [The Scrum Values | Scrum.org], section “The Scrum Values”

According to the Large-Scale Scrum (LeSS) framework, one of the principles for scaling agile development is to descale the organization, which means simplifying the structure and reducing dependencies and handoffs. A well-structured Product Backlog can help achieve this by enabling feature teams, which are cross-functional and cross-component teams that can deliver a complete customer-centric feature. Feature teams minimize and often eliminate Developers working on multiple Scrum Teams during a Sprint, as they can focus on one Product Backlog item at a time. This also improves productivity, quality, and learning, as Developers can avoid context switching and multitasking, which are known to reduce efficiency and effectiveness. A person working on multiple Scrum Teams at the same time is often less productive than when that person can focus on the Sprint Backlog of a single Scrum Team.

The Large-Scale Scrum (LeSS) framework also states that Scrum does not change when scaling up to multiple teams. The core Scrum framework remains intact, with one Product Owner, one Product Backlog, and potentially releasable Increments every Sprint. The only changes are adding a few coordination practices to cope with the increased complexity and interdependencies. Therefore, changes to the core Scrum framework are not needed to be successful with Scrum at large scale.

Scrum Team members do not have to be working full time on a team, as long as they are committed to the Sprint Goal and deliver a Done Increment every Sprint. However, it is recommended that they spend as much time as possible with their team, as this fosters collaboration, communication, and alignment.

References:

• The Large-Scale Scrum (LeSS) framework | Atlassian, accessed on September 30, 2023
• Overview - Large Scale Scrum (LeSS), accessed on September 30, 2023
• Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Craig Larman and Bas Vodde, 2010
• Leading Large Scale Product Development with Large-Scale Scrum (LeSS), Kamlesh Ravlani, 2015

The situation described in the question indicates that there are multiple problems in the Scrum Team that have led to the increase of technical debt and the dissatisfaction of the Product Owner. These problems include:

• The Scrum Team has not used the past Sprint Retrospectives effectively to inspect and adapt. The Sprint Retrospective is an opportunity for the Scrum Team to reflect on their performance and identify improvements for the next Sprint. If the Scrum Team has not been using this event properly, they may have missed some issues or opportunities that could have improved their quality and value delivery.
• The Developers have not been paying enough attention to quality. The Developers are accountable for creating a potentially releasable product increment that meets the Definition of Done and the Sprint Goal. If the Developers have not been focusing on quality, they may have introduced defects, errors, or inefficiencies that compromise the functionality and usability of the product.
• The Scrum Team is not having conversations around technical debt. Technical debt is the accumulation of work that needs to be done to ensure that a product is maintainable and extensible in the future. If the Scrum Team is not discussing and managing technical debt, they may be neglecting some important aspects of the product architecture, design, or code that could affect its scalability, performance, or security.
• The Scrum Master has not ensured that the Scrum Team is being transparent. The Scrum Master is responsible for establishing an environment where transparency, inspection, and adaptation can occur. If the Scrum Master has not ensured that the Scrum Team is being transparent, they may have allowed some hidden problems or assumptions to persist that could affect the quality and value of the product.

References:

• Scrum Guide 2020, page 13: “The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.”
• 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: “Technical debt is a metaphor for expressing how doing things in a suboptimal way can accumulate over time and make it harder to change or improve a product in the future.”
• 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.”

A Scrum Master is not a management position in the traditional sense of the word. A Scrum Master does not have authority over the team members, the product, or the project. A Scrum Master is a servant leader who helps the team self-organize, collaborate, and deliver value. A Scrum Master is accountable for managing the Scrum process, ensuring that the team follows the Scrum values and principles, and facilitating the team’s interactions with stakeholders and the organization. A Scrum Master is also accountable for removing organizational impediments that limit the team’s progress and productivity, such as bureaucracy, silos, or conflicts. A Scrum Master is not accountable for reporting on the performance of a team, managing the project plan and the project deliverables, or managing the capacity and utilization of the Developers. These are responsibilities of the Product Owner, the Developers, or other roles in the organization.

References:

• Scrum Guide 2020, section “The Scrum Master”, “The Scrum Team”.
• What is a scrum master? [+ Responsibilities] | Atlassian, section “Scrum master responsibilities”.
• Scrum Master Roles and Responsibilities [2023] | Simplilearn, section “What Does a Scrum Master Do?”, “Scrum Master Responsibilities”.

• B: The Scrum Master coaches the Scrum Team and the organization how to work empirically. This is a true statement, as the Scrum Master is responsible for helping everyone understand and apply the principles and practices of Scrum, which is based on empirical process control. The Scrum Master can teach the Scrum Team and the organization how to use transparency, inspection, and adaptation to deliver valuable products in a complex environment.
• C: The Scrum Master facilitates Scrum events as requested or needed. This is a true statement, as the Scrum Master is responsible for ensuring that all Scrum events take place and are positive, productive, and kept within the timebox. The Scrum Master can facilitate the communication and collaboration among the Scrum Team and the stakeholders during the Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.

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 13: “The purpose of each event in Scrum is to create an opportunity for inspection and adaptation. These events are specifically designed to enable critical transparency and inspection.”
• Professional Scrum Master II Course, page 13: “The Scrum Master serves the Scrum Team by facilitating the Scrum events and ensuring that they are effective and valuable.”