Free Practice Questions for Scrum PSM-II Exam

B. You inform management of organizational impediments that prevent the Scrum Team from being more productive. You enlist their help to remove these impediments.

This is a good answer because it is consistent with the Scrum Master’s accountability to serve the Scrum Team and the organization by identifying and addressing the factors that hinder the team’s effectiveness12. By informing management of the organizational impediments, you can leverage their authority and influence to resolve them. By enlisting their help, you can also foster a collaborative and supportive relationship with them. C. You explain how a Scrum Team uses the velocity of a Sprint primarily to forecast work for the next Sprint, not to perfectly predict future productivity. You refer management to the Product Owner for all information concerning the progress of development.

This is another good answer because it is consistent with the Scrum Master’s accountability to educate and coach the organization on the Scrum framework and itsprinciples12. By explaining how velocity is used in Scrum, you can help management understand that it is not a reliable metric for measuring performance or comparing teams. By referring management to the Product Owner, you can also respect the Product Owner’s accountability to manage the product backlog and communicate the value and status of the product34.

References: 1: What is a Scrum Master? | Scrum.org 2: What is a scrum master? [+ Responsibilities] | Atlassian 3: What is a Product Owner? | Scrum.org 4: What is a product owner? [+ Responsibilities] | Atlassian : Scrum Guide | Scrum Guides

 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”

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

When multiple Scrum Teams work from the same Product Backlog, they need to collaborate and coordinate their work to deliver a potentially releasable Increment that meets the Definition of Done. This requires minimizing dependencies between Scrum Teams, such as technical, functional, or organizational dependencies. Dependencies can cause delays, rework, waste, and lower quality. Scrum Teams should strive to be cross-functional and autonomous, and use techniques such as feature slicing, dependency mapping, and integration testing to reduce dependencies123. References: 1: https://www.scrum.org/resources/blog/dependencies-between-scrum-teams  2: https://www.scrum.org/resources/blog/feature-slicing-how-make-it-work  3:https://www.scrum.org/resources/blog/integration-testing-scrum-projects

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

According to the Scrum Guide 2020, the Sprint Goal is a short statement that provides direction and focus for the Scrum Team throughout the Sprint1. The Sprint Goal is chosenby the Scrum Team during Sprint Planning, based on the Product Backlog items that they forecast to complete in the Sprint1. The Sprint Goal also gives Developers flexibility and creativity on how to implement functionality during the Sprint, as long as they do not endanger the Sprint Goal1. Therefore, the statements that are true about the Sprint Goal are:

During Sprint Planning, the Scrum Team crafts a Sprint Goal based on an objective that the Product Owner would like to achieve that Sprint. This statement is true because it reflects the purpose and process of creating a Sprint Goal. The Product Owner proposes an objective for the Sprint, based on the current state of the product and the stakeholders’ needs2. The Developers then select the Product Backlog items that support that objective, and craft a Sprint Goal that expresses what value they will deliver in the Sprint2.

Sprint Goals give Developers flexibility and creativity on how to implement functionality during the Sprint. This statement is true because it reflects the benefit and outcome of having a Sprint Goal. The Sprint Goal is not a fixed scope of work, but a flexible goal that guides the Developers’ decisions and actions3. The Developers can modify their Sprint Backlog during the Sprint as needed, as long as they do not endanger the Sprint Goal1. The Sprint Goal also encourages the Developers to work together rather than on separate initiatives3.

The other statements are not true because:

Sprint Goals often change during the Sprint as new insights emerge during the work. This statement is false because it contradicts the Scrum framework, which defines the Sprint Goal as a commitment by the Developers that does not change during a Sprint1. The Sprint Goal provides coherence and alignment for the Scrum Team, and helps them cope with complexity and uncertainty3. Changing the Sprint Goal during a Sprint would undermine its value and impact, and create confusion and waste.

The use of Sprint Goals is optional in the Scrum Framework. This statement is false because it contradicts the Scrum framework, which defines the Sprint Goal as a mandatory element of each Sprint1. The Scrum Guide 2020 states that “the entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint” and “the Developers commit to achieving the Sprint Goal” 1. Without a Sprint Goal, there would be no clear direction or focus for the Scrum Team, and no way to measure their progress or success.

References: 1: https://www.scrumguides.org/scrum-guide.html#sprint-goal  2: https://www.scrumguides.org/scrum-guide.html#sprint-planning  3: https://www.scrum.org/resources/blog/sprint-goal-key-element-scrum

A Scrum Team is self-managing, meaning that they have the autonomy and authority to organize and manage their own work within the boundaries of Scrum. A self-managing Scrum Team:

Creates their own Sprint Backlog, reflecting all work that is part of the Definition of Done ©, which is a valid option as it shows that the Developers are responsible for planning and executing the work needed to deliver a potentially releasable Increment at the end of each Sprint.

Collaboratively selects and re-plans their work during the Sprint (D), which is another valid option as it shows that the Developers are able to adapt to changing requirements, priorities, or circumstances within the Sprint, without relying on external instructions or approvals.

The other options are not correct because they:

Invite management to the Daily Scrum for a progress update and subsequently work with the Scrum Master to optimize the plan for the next day (A), which is not a good option as it shows that the Scrum Team is not self-managing, but rather dependent on management intervention and direction. The Daily Scrum is an event for the Developers to inspect their progress and plan their work for the next 24 hours, not a status report for management or anyone else.

Work strictly within the boundaries of their function description, and hand off work in a timely fashion to the other members within the team (B), which is not a good option as it shows that the Scrum Team is not self-managing, but rather following a rigid and siloed structure. The Developers are cross-functional, meaning that they have all the skills necessary to create a “Done” Increment, and they collaborate and coordinate their work as one team, not as separate individuals or roles.

Invite the right external people to the Sprint Planning to help them create a complete and detailed Sprint Backlog before the meeting timebox expires (E), which is not a good option as it shows that the Scrum Team is not self-managing, but rather relying on external assistance and input. The Sprint Planning is an event for the Scrum Team to create a Sprint Goal and a Sprint Backlog, based on the Product Owner’s proposal and the Developers’ forecast. The Scrum Team may invite other people to provide advice or expertise, but they are ultimately accountable for their own plan.

References: : [Scrum Guide], The Scrum Team : [Scrum Guide], The Developers : [Scrum Guide], The Sprint Backlog : [Scrum Guide], The Daily Scrum : [Scrum Guide], The Sprint Planning

A Definition of Ready (DoR) is a set of agreements that lets everyone know when a product backlog item is ready to be taken into a sprint12. A DoR can help the Scrum Team ensure that the product backlog items are clear, feasible, valuable, and testable12. However, a DoR does not necessarily maximize the team’s velocity, nor does it ensure that the sprint planning can end within its timebox. Velocity is a measure of how much work a team can complete in a sprint, and it depends on many factors, such as the team’s capacity, skills, collaboration, and quality standards3 . A DoR may help the team avoid wasting time on unclear or incomplete items, but it does not guarantee that the team can deliver more value or faster. Similarly, a DoR may help the team prepare for the sprint planning, but it does not guarantee that the team can finish the planning within its timebox. The sprint planning is an empirical and collaborative event, where the team inspects the product backlog, negotiates with the product owner, and crafts a sprint goal and a sprint backlog . A DoR may reduce some uncertainties and risks, but it does not eliminate them. The team still needs to adapt to changing requirements and expectations, and make realistic and meaningful commitments .

References: 1: What is Definition of Ready in Scrum? - Visual Paradigm 2: Walking Through a Definition of Ready | Scrum.org 3: What is Velocity in Agile? - Atlassian : Velocity in Scrum | Scrum.org : Sprint Planning | Scrum.org : Sprint planning - Atlassian

Adding a second team to work on the same product will introduce some challenges and overheads that can affect the velocity of the original team. For example, the teams will need to coordinate and communicate more frequently, integrate their work more often,resolve any dependencies or conflicts, and align their standards and practices. These activities will consume some time and effort that could otherwise be spent on delivering value. Therefore, the velocity of the original team is likely to decrease and be lower than 18, at least in the short term.

References:

Professional Scrum Master II Course, page 16: “Adding more people to a complex product development effort does not necessarily increase productivity or reduce time to market.In fact, it often has the opposite effect.”

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

A “Quality Assurance and Release Readiness Sprint” is not a Scrum concept, but a sign of poor engineering practices and weak adherence to the Scrum values and principles. It indicates that the Scrum Team is not delivering a potentially releasable product Increment every Sprint, which is one of the core commitments of Scrum. This could be due to a weak or incomplete Definition of Done, which allows technical debt to accumulate and compromises the quality and usability of the product. It could also be due to the Developers finding it nearly impossible to create a valuable, useful product Increment in a Sprint, which could be caused by various factors such as lack of skills, tools, collaboration, feedback, or empowerment. The Definition of Done is not being met every Sprint, which means that the Scrum Team is not fulfilling its accountability for the Increment and is not transparent about the state of the product.

References:

Scrum Guide 2020, section “Commitments”, “Definition of Done”, “The Sprint”, “The Increment”.

Advanced Knowledge of Scrum, section “Definition of Done”, “Technical Debt”.

Scrum Master Accountabilities, section “Accountability for Effectiveness”.