PSM II Mock Test

The team should be made aware of their responsibility in delivering working software. The Sprint Retrospective is a good time to dig deeper, and it directly follows the Sprint Review. Let the team self-organize instead of providing possible answers.

Here "do nothing" is incorrect because the developers are okay with this behavior.
Explaining to the PO that he should not attend DS is a quite misleading answer. The answer implies that the SM tells people (PO) what to do (to attend or not events). Which may be associated with some bad stances of the SM.
To facilitate the event is also misleading. Yes, "facilitator" is one of the good stances of a Scrum Master, but in this situation, there is no need for that.

The best answer is to coach (another good stance) the members of the Scrum Team and give them a chance to do better in the future.

Developers are structured and empowered by the organization to organize and manage their own work. This includes deciding how to form teams when multiple teams are needed. The resulting synergy optimizes the Developer’s overall efficiency and effectiveness. They are self-managing. No one (not even the Scrum Master) tells the Developers how to turn the Product Backlog into Increments of potentially releasable functionality.

Empiricism will be the first to suffer. Having a Sprint Review and Retrospective every 60 days suggests that the product will most likely stray, there will be less frequent reviews and feedback with Stakeholders and the team will have lees instances to improve itself. Transparency is lowered as a whole.

The Sprint length has a direct correlation with feedback loops such, as inspection and adaption, sprint reviews, sprint retrospective improvements, and breaking scrum rules of maximum length of one month sprint.
From Scrum Guide:
- Scrum combines four formal events for inspection and adaptation within a containing event, the Sprint. These events work because they implement the empirical Scrum pillars of transparency, inspection, and adaptation.
- Sprints are fixed-length events of one month or less to create consistency. While implementing only parts of Scrum is possible, the result is not Scrum. Therefore, a team with a two-month sprint is no longer doing Scrum.
Therefore, because inspection and adaption are affected by the Sprint length, transparency will deteriorate too.

There is not a direct correlation between Sprint length and Scrum Values or technical debt. These additional difficulties stated as answers may or may not arise. However, they are not directly related to the Sprint length.

A new Sprint starts immediately after the conclusion of the previous Sprint. Delaying the start of the next Sprint interrupts progress and can reduce the Time-to-Market. Shortening the Sprint length allows the team to respond quickly to changes outside of the Sprint plan and while still allowing delivery of business value. Adding user feedback to the Product Backlog helps the Product Owner with ordering the backlog to maximize the flow of value. During the Sprint no changes are made that would endanger the Sprint Goal.

Think about the concept of Emergent Architecture and the rule that every Sprint should produce business functionality, no matter how small. Also, what do we do with non-functional requirements? In most cases, we add them to the Definition of Done and the Product Backlog.

There are no pauses or postponements between Sprints. The Scrum Team is crossfunctional, they should not rely on a component team to do non-functional requirements for them.

Reminder: Non-functional requirements are things like security, scalability, maintainability, speed, and more.

The initial phase of forming a new team could cause short-term disruption as they need time to discover how to best work together. Because all the skills and competencies are inside the team the communication overhead is reduced. Having an environment that supports the Scrum values reduces complexity.

As a self-managed team, they will decide for themselves how to best manage communication between team members. The Scrum Master will only take action if requested OR if he/she observes that there is a potential problem.

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.

Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. Scrum employs an iterative, incremental approach to optimize predictability and control risk.

Developers are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Developers' overall efficiency and effectiveness. Developers have the following characteristics: They are self-managing. No one (not even the Scrum Master) tells the Developers how to turn Product Backlog into Increments of potentially releasable functionality; Developers are cross-functional, with all the skills as a team necessary to create a product Increment; Scrum recognizes no titles for Developers, regardless of the work being performed by the person; Scrum recognizes no sub-teams in the Developers, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and, Individual Developers may have specialized skills and areas of focus, but accountability belongs to the Developers as a whole.

One of the primary responsibilities of a Scrum Master is the ability to facilitate regardless of the context or setting.

This situation clearly indicates the product backlog is prioritized without considering dependencies. Also, the backlog is not refined well enough, so the primary concern is the flow of value reflected in the ordering of the Product Backlog. The timeline of the flow might be influenced by such dependencies but doesn't necessarily change the ordering.

Scrum is founded on empirical process control theory or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. The Sprint Backlog is a forecast by the Developers about what functionality will be in the next Increment and the work needed to deliver that functionality into a ‘Done’ Increment. The Developers modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Developer work through the plan and learns more about the work needed to achieve the Sprint Goal. The other options are incorrect: The Developers does not commit to finishing all items in the Sprint Backlog. Committing to completing all items would be fixed scope and fixed time leaving no room to adapt. They commit to the Sprint Goal and do the right thing. It’s also incorrect for the Product Owner to focus on completing the entire Sprint Backlog. Finishing everything should not be his main focus. Having a shippable increment that meets the Sprint Goal is more important than trying to finish everything.

Scrum Guide: Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

The Scrum Master is responsible for removing impediments within the current context of the situation and boundaries defined by the Scrum framework. So the options of Scaling Scrum, Self-manage Cross-functional Scrum Team & Product Backlog management comes into the picture.

The ones closest to the problem are the best ones to understand and solve the problems. The Scrum Master can remove members (if empowered). The question is focused on the ownership of the root problem. The Developers are responsible for addressing internal conflicts and may request help from the Scrum Master if needed. Because this is a localized issue, they are the ones that must initiate the actions for the results they desire.

The Scrum Master serves the Scrum Team in several ways, including:

• Coaching the team members in self-management and cross-functionality;
• Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
• Causing the removal of impediments to the Scrum Team’s progress; and,
• Ensuring that all Scrum events take place and are positive, productive, and kept within the time-box.

It is the Scrum Master’s responsibility to teach the Scrum Team the value and objective of each Scrum event in order to help them maximize the benefits of each event in accordance with the Scrum values and theory.

None of the other answers fit with the characteristics of the Scrum Master. Sometimes, the best thing for the Scrum Master is to do nothing. There is no rule that all Developers should be in the Product Backlog Refinement. The scenario is described as the Developers are very matured and self-managing so it must have been their decision and agreement to work like this in refining items with the Product Owner very clear about who will do what. No one (not even the Scrum Master) tells the Developers how to organize their work. They are accountable and in control of how they do things.

Architecture and infrastructure can be an attribute of either product quality or product scope. So it should be added and ordered on the Product Backlog accordingly. It should be treated equally importance and implemented along with the functional development of the product.

Scrum Guide: - Product Backlog items that can be done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. - Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team. The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. - Topic Two: What can be done this Sprint? Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence. Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.

It is the Product Owner's responsibility, but he/she is aware of this. Pointing that out again is not helpful advice. Management is unlikely to know end-users their exact wishes and expectations.

Infrastructure and tools are not prepared upfront, because it requires a complete understanding of the whole project and product, which is usually not the case, so we need to hold on to the adaptation pillar. The required infrastructure and tools will be prepared gradually through the project because they depend on the product we're going to create, which in turn is defined through the project. Make sure you have noticed the "least appropriate" in the question.

The Scrum Master not only a servant-leader to the Scrum Team but also to the organization. The Scrum Master helps everyone improve their interactions to maximize the value created by the Scrum Team. Value for the business and value for customers. The Scrum Master leads by example, by respect, and by the ability to influence the organization for the Scrum Team and its effectiveness. The Scrum Master should also lead by values, by helping everyone embody the values of commitment, courage, focus, openness, and respect.

During the Sprint no changes are made that would endanger the Sprint Goal. As the Developers work, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Developers expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint. So Mark should work more closely with the developers; items should not be added to the sprint backlog unless the developers can commit to completing the items within the sprint.

The risk is monitored and audited on an ongoing basis throughout each iteration and exposed during iteration planning, execution, review, and retrospective.

During Sprint Planning the number of items selected from the Product Backlog for the Sprint is solely up to the Developers regardless of the number of teams working from the same Product Backlog. Only the Developers can assess what it can accomplish over the upcoming Sprint.

Conflict is not always bad for a team, however, members must respect each other. Team members must express their points of view and have a constructive discussion. When a Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the Definition of Done for the Scrum Team and is used to assess when work is complete on the product Increment. In self-organized teams creativity, thrives and conflicts can be resolved.

In order to ensure transparency, work that must be done to the product must be visible in either the Product Backlog or the Definition of Done.

The CEO is acting as a Stakeholder. We need to see him as a Stakeholder, probably a key one. The lack of openness is best served by participating in the Sprint Review inspection. The CEO, as a stakeholder, should collaborate with the Product Owner to communicate his expectations.
The CEO is acting as a Stakeholder of the Product. The Product Owner must understand his or her arguments, and possibly create experiments to evaluate the impact and potential value along with other Product Backlog items. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.