Scrum Professional Scrum Master II PSM-II Exam Practice Test

Answer : A

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.

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)

Answer : B

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 .

Answer : B, C, D

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.

Answer : A, D

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.

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)

Answer : A, C

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.

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

Answer : D

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.

What is an Increment? | Scrum.org

What Is a Daily Standup? | A Guide to Running Effective Standup Meetings | Atlassian

Answer : C, D

A self-managing Scrum Team is one that internally decides who does what, when, and how. It does not need external direction or supervision to accomplish its work. A self-managing Scrum Team can resolve conflicts and continue working, as this shows that the team members can collaborate effectively and handle disagreements without escalating them. Creativity flourishes and new possibilities are explored, as this shows that the team members are empowered to experiment and innovate, rather than following a fixed plan or process.

The Scrum Guide 20201, section ''The Scrum Team''

The Scrum Master Learning Path2, module ''The Self-Managing Scrum Team''

The Professional Scrum Master II Course3, topic ''Self-Management''