Free Scrum PSM-II Practice Exam with Questions & Answers

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. They discuss in the upcoming Sprint Retrospective why this happened and what changes will make it less likely to recur. This is a good action to take, as it shows that the Scrum Team is willing to inspect and adapt their process and improve their collaboration and communication. The Sprint Retrospective is an opportunity for the Scrum Team to identify the root causes of the problem and create a plan for implementing improvements in the next Sprint.

D. The Developers forecast the most likely Product Backlog items to meet the business objective and create a Sprint Backlog based on a likely initial design and plan. Once the timebox for the Sprint Planning event is over, they start the Sprint and continue to analyze, decompose, and create additional functionality during the Sprint. This is also a good action to take, as it shows that the Scrum Team is flexible and adaptive, and does not let uncertainty or ambiguity prevent them from delivering value. The Developers can use the Sprint Goal as a guide to select and refine the Product Backlog items during the Sprint, and collaborate with the Product Owner to ensure that they are meeting the expectations and needs of the stakeholders.

References:

• The Scrum Guide, section 3.1 (The Sprint), page 8
• The Scrum Guide, section 3.3 (The Sprint Goal), page 9
• The Scrum Guide, section 3.5 (The Sprint Planning), page 10
• The Scrum Guide, section 3.7 (The Sprint Retrospective), page 12
• 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 6 (The Sprint Retrospective)

C. Timeboxes encourage the people who are closest to the problem to create the best possible result in the time allotted, given the current context.

• This is true because timeboxes limit the amount of time that can be spent on an activity, which forces the Scrum Team to focus on the most valuable and feasible outcomes. Timeboxes also empower the Scrum Team to make decisions based on their own expertise and experience, rather than relying on external authorities or instructions12. D. Timeboxes help everyone focus on the same problem at the same time.
• This is true because timeboxes create a shared sense of urgency and alignment among the Scrum Team and the stakeholders. Timeboxes also enable frequent feedback and inspection, which help the Scrum Team adapt to changing requirements and expectations12.

References: 1: What Is Timeboxing in Scrum? - Visual Paradigm 2: What Is Timeboxing in Scrum and What Are the Benefits? Scrum Alliance

The possible explanations for why this Scrum Team is struggling to craft a Sprint Goal are B, D, and E.

B. The Sprints are too long. A four-week Sprint is the maximum duration allowed by the Scrum Guide, and it may not be suitable for complex and uncertain work that requires frequent feedback and adaptation. A shorter Sprint may help the Scrum Team to focus on a clear and coherent Sprint Goal that aligns with the Product Goal and delivers a valuable Increment.

D. The Product Owner is not communicating the Product Goal that they want to achieve in upcoming Sprints. The Product Goal is a long-term objective for the Scrum Team that provides direction and purpose for their work. The Product Owner is responsible for communicating the Product Goal to the Developers and collaborating with them to create Sprint Goals that move them closer to the Product Goal. Without a clear Product Goal, the Scrum Team may lack a shared vision and end up working on unrelated items.

E. The Scrum Team is too big. The Scrum Guide recommends that the Scrum Team consists of 10 or fewer people, including the Scrum Master and the Product Owner. A larger team may have difficulties in collaborating effectively, self-organizing, and creating a meaningful Sprint Goal that reflects the collective commitment of the Developers. A smaller team may improve the communication, coordination, and cohesion among the Developers and help them to create and achieve a Sprint Goal.

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.3 (The Sprint Goal), page 9
• The Scrum Guide, section 4.1 (The Product Backlog), page 11
• The Scrum Master Learning Path, module 2 (The Scrum Framework), lesson 2 (The Sprint) and lesson 3 (The Sprint Goal)

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

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

 When multiple Scrum Teams work on the same product, they share one Product Backlog that contains all the requirements for the product. The Product Owner isresponsible for ordering and refining the Product Backlog items, but does not assign them to specific teams. Instead, the Scrum Teams pull in work from the Product Backlog in agreement with the Product Owner and the other teams, based on their capacity, skills, dependencies, and Sprint Goals. This way, the Scrum Teams can self-organize and collaborate to deliver a coherent and valuable product Increment.

References:

• The Scrum Guide, November 2020, p. 7-8
• Can two teams work on one product backlog?, Scrum.org, January 6, 2020

 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”

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

The Scrum Master is responsible for promoting and supporting Scrum, which includes helping the Scrum Team and the organization understand and enact Scrum values, principles, and practices. The Scrum Master should offer guidance that:

• Addresses the root cause of the conflict, not just the symptoms or the consequences.
• Empowers the Scrum Team to self-organize and collaborate effectively, without relying on external intervention or authority.
• Fosters a culture of transparency, inspection, and adaptation, where feedback is welcomed and used to improve the product and the process.
• Focuses on delivering value to the customer and meeting the Sprint Goal, not on following a fixed plan or satisfying individual preferences.

Therefore, the best option is to address why requirements change during the Sprint Retrospective ©, which is an event that allows the Scrum Team to inspect how they worked together and create a plan for improvements. The Scrum Master should ask the Developers and the Product Owner to talk about why the requirements are changing and consider the impact on value during this discussion. This will help them understand each other’s perspectives, clarify their expectations, and align their goals.

The other options are not appropriate because they:

• Take everyone to a 2-day off-site event to relax and re-align (A), which may be a nice gesture, but does not solve the underlying problem or help the Scrum Team improve their collaboration skills. It may also be seen as a distraction or a reward for poor performance.
• Ask each person’s functional manager to instruct their employees that they must collaborate better, or be removed from the team (B), which undermines the self-organization and autonomy of the Scrum Team and introduces a threat of punishment that may damage trust and motivation. It also violates the Scrum value of respect and the principle of servant leadership.
• Ask for a project manager or other external resource to mediate and temporarily take over for the Product Owner (D), which creates a dependency on an outsider who may not have the necessary knowledge, authority, or vision to manage the product. It also violates the Scrum role of the Product Owner and the principle of single-wringable-neck.

References: : [Scrum Guide], The Scrum Master : [Scrum Guide], The Sprint Retrospective : [Scrum Guide], The Product Owner : [Scrum Guide], The Developers : [Scrum Guide], Scrum Values