PSM II Mock Test

The Product Owner is responsible for maximizing the value of the product resulting from the work of the Developers. The Product Owner is the sole person responsible for managing the Product Backlog.

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 does not accept or reject decisions.
When the team does changes to the DoD, the SM knows the right questions to ask:
-Why are we making the change and what do we want to achieve?
-Will this change reduce transparency in some way?
-Will we still be able to create valuable increments every Sprints?

The ones that will be doing the work are the best ones to decide on what Developer's structures work best.

Technical practices need to be introduced early in an agile team and one of the critical practices is continuous integration. If the process is time-consuming or difficult, the team must figure out a way to reduce the time and complexity. Continuous integration $(mathrm{Cl})$ is the practice of merging all developer working copies to shared mainline several times a day. The main aim of $mathrm{Cl}$ is to prevent integration problems. The practice aims to reduce rework and thus reduce cost and time. So Investigate how to reduce the time taken for integration and build.

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

The relationship between cause and effect can become more clear when more information emerges.

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 timebox. The Scrum Master serves the Product Owner in several ways, including Helping find techniques for effective Product Goal definition and Product Backlog management; Helping the Scrum Team understand the need for clear and concise Product Backlog items; Helping establish empirical product planning for a complex environment; and, Facilitating stakeholder collaboration as requested or needed. From the options provided, Coaching is the best option as the main objective of Scrum Master is to make the team self-managed & Cross-Functional. Although the Scrum Master knows that testing would make the increment not releasable, he or she needs to coach the Scrum Team to understand why

If there are multiple Scrum Teams working on the system or product release, the Developers on all the Scrum Teams must mutually define the Definition of Done.

Multiple Scrum Teams for 1 Product =>1 Product Backlog =>1 Product Owner. Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. The Product Owner is the sole person responsible for managing the Product Backlog. The Product Owner is one person, not a committee. Just like the membership changes within a Scrum Team, adding or removing additional Scrum Teams to the same Product Development will impact productivity in the initial stages. Scrum Teams are crossfunctional, with all the skills as a team necessary to create a product Increment. Scrum recognizes no titles for Scrum team members, regardless of the work being performed by the person; Scrum recognizes no sub-teams, 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.

There is no information provided about work getting added or removed to the sprint and even if that did happen (it is not allowed), the planned trajectory will also be changed. The most plausible explanation is that either they actually relax in the middle of the sprint or they do not update the hours. Since they seem to be getting stuff completed regularly, the most likely scenario is hours not getting updated.

The Manifesto for Agile Software Development values "working software over comprehensive documentation". This core value asks us to think about how much and which kinds of documents are needed and when they need to be written. The goal in Agile should be to find the right balance between documentation and discussion.

The number of items selected from the Product Backlog for the Sprint is solely up to Developers. Only they can assess what it can accomplish over the upcoming Sprint. The Sprint Goal is an objective set for the Sprint that can be met through the implementation of the Product Backlog. It provides guidance to the Developers on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Developers some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Developers to work together rather than on separate initiatives.

The lack of transparency is best served by joining inspection during Sprint Review. As a stakeholder, the CEO should work with the Product Owner to make his expectations known.

Working software is the primary measure of progress as per the Agile principles, therefore the team must find a way to show a working system. Further, the coach should avoid dictating to the team how they should schedule their work but gently suggest to them that they need to find a way to showcase their work.

It is likely that unknown errors will be released into production. This may result in instability issues with the product and lower customer satisfaction. The developers are professionals. It would be unprofessional to knowingly release poor-quality products.

The team member should politely decline and explain to the manager about his ownership and accountability for the Scrum Team. Other than the backlog refinement, the developers should work on the tasks related to the sprint goal. If any external authority brings different work, the team should explain how they self-manage their work in Scrum way. After that, the team can refer them to speak with the Product owner if the external authority still wants to add this new work.

Sam should discuss his concerns with the product owner; if the product owner is unable to clarify then the item should not be chosen for the current sprint until the item can be clarified.

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value for each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how. Java specialist does not belong to Scrum Team so Developers from Scrum Team with an interest in the Java domain step up to take on this work in their respective teams.

The fact that it cannot deliver everything, is not a reason for canceling the Sprint. Sprints are only canceled when they don't make sense anymore. For example, the customer doesn't need the Sprint Backlog items anymore. When developers realize that they won't be able to deliver a high percentage of the items, it's a good idea for the Product Owner to check the sprint Backlog and make changes in the priorities (if needed), since items at the bottom of the Sprint Backlog will probably stay incomplete.
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how). The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.

Usually Scrum master considers the large estimate but in this case, it's 22 which should not be considered under a sprint. So you should seek the team's support to decide on this, as if it is large then it should be broken down to fit in a sprint.

The Scrum Master needs to coach the Developers to work in a way that they don't depend on Mary and they can take ownership of this issue by themselves.

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.

Architecture emerges during the Sprints. It will likely need more attention in early sprints. A few of the other answers are somewhat right but do not explain the way Scrum looks at emergent architecture.

As stated in the Scrum Guide an Increment is a concrete stepping stone toward the Product Goal. The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. The increment is something that meets the Definition of Done. It's not Kleopatra's fault, if her work meets the Definition of Done, then it's part of the Increment. The issue is with the Definition of Done, it's not strong enough.

The Product Backlog refinement process was insufficient for producing Product Backlog items that could be readily understood and forecasted for a Sprint. Cancel the Sprint Planning meeting and ask everyone to spend as much time as needed analyzing the Product Backlog before reconvening for another Sprint Planning meeting.

If there are multiple Scrum Teams working on the system or product release, the Developers on all the Scrum Teams must mutually define the Definition of Done. Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

Product Backlog items should be clear enough and have enough information for the Product Owner and Development to understand the work that needs to be done and to create a forecast of Product Backlog items to implement the Sprint Goal. Nothing stops the flow of Sprints, for example, we do not delay the Sprint because the items are not ready. In such cases, the “unready” items would be selected for the Sprint anyway and refined during the Sprint. In the case that the Product Backlog items are not clear enough, the Developers forecasts the most likely Product Backlog items to meet the goal and create a Sprint Backlog based on a likely initial design and plan. Once the timebox for the Sprint Planning meeting is over, start the Sprint and continue to analyze, decompose, and create additional functionality during the Sprint. At the end of the Sprint, the Scrum Team can discuss in the upcoming Sprint Retrospective why this happened and what changes will make it less likely to recur.

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers. Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management. Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.

The Scrum Master serves the organization by helping employees and stakeholders understand and enact Scrum and empirical product development and causing a change that increases the productivity of the Scrum Team. So in this scenario, he/she should explain the use of velocity in the context of Scrum which is to forecast work rather than increase productivity. Also, the scrum master’s primary responsibility is to remove impediments and if it is at the organizational level then he/she should raise those to the appropriate authority and make it transparent to all stakeholders.