PSM II Mock Test

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.

Withholding information is not a good option. This reduces transparency. So the PO should not wait for the Sprint Retrospective. The best thing to do is to share the concern with the team now.
Having a "serious talk" and blaming the developers is never a good option. This goes against the Scrum Values.
Also, the PO or the SM cannot just tell the Developers to add more points to the Definition of Done. A decision has to be taken collaboratively.

In self-managed teams creativity thrives, conflicts can be resolved, and new possibilities are explored.

Scrum Teams are self-managing and cross-functional. Self-managing teams internally decide who does what, when, and how., rather than being directed by others outside the team. Cross-functional teams have had all the skills necessary to create value for each Sprint. Phil does not belong to any team so Developers with an interest in Phil's domain step up to take on this work in their respective teams.

Outcomes of the Scrum Team are affected by the Product Owner's participation and availability. During a Sprint he/she is responsible for answering questions from the Developers about items in the current Sprint and optimizing the value of the work the Developers do. He/she doesn't always need to be with the team but he/she should to be available when needed. The Sprint Review is not a meeting for Product Owner approval but rather a collaboration effort between the Scrum Team and Stakeholders.

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values. The Scrum Master coaches the Product Owner and Developers and facilitates as requested or needed. The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Scrum Master's job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn't occur overnight but is a path.

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 Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be "Done," which means it must be in useable condition and meet the Scrum Team's definition of "Done. The increment must be in useable condition regardless of whether the Product Owner decides to release it.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. Clearly expressing Product Backlog items and interaction with stakeholders are the two primary responsibilities of the Product Owner.

Rest all options are incorrect as Daily Scrum is for developers and it is used to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. If the Product Owner is actively working on items in the Sprint Backlog, then he/she can participate in Daily Scrum as Developers. But this meeting is not used to adapt to scope change on a daily basis as it will impact the sprint goal. There is no need to keep updated Developers on daily basis.

There are no separate analysis phases or sprints and helping stakeholders understand and enact an empirical approach for complex work is scrum master’s responsibility.

Scrum Master’s responsibility is to help employees and stakeholders understand and enact an empirical approach for complex work. Here the question is what you recommend to the product owner.

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

During the Sprint, the Scrum Team commits to achieving the Sprint Goal. The initial forecast may change as more is learned. The team may add or remove PBIs from the Sprint Backlog.
This is not an adequate reason to involve the HR department.
As a Scrum Master, you understand that meeting the Sprint Goal is the primary objective of the Scrum Team and NOT meeting the initial forecast.

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

Adding new teams will almost certainly slow down the effort owing to the learning curve and is not good for the short timeframe. Sticking to your own strategy while disregarding external facts, and stakeholders' needs and failing to validate with real users demonstrates a lack of inspection and adaptation. Keep in mind that Sprints are Scrum's heartbeat, where ideas are transformed into value, and value can only be evaluated by people who use the product. Example of Time to Market: Reducing the number of features in a product release can dramatically improve T2M; the smallest release possible is one that delivers at least some incremental improvement in value to some subset of the customers/users of the product. Many organizations also focus on removing non-value-added activities from the product development and delivery process to improve their T2M.

The Scrum Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end of each Sprint. Scrum Teams are structured and empowered by the organization to organize and manage their own work. 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. So Scrum Master should include the current developers in the hiring decision. They should know what skills they need for their team and have a chance to evaluate potential additions to the team.

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.

Courage is a very important value in Scrum. Every team member must have the courage to say NO if something is outside the rules of Scrum.

The activities required to complete the Product Backlog items to a "done" state should be completely within the ownership and influence of the Scrum Team.

One of the key pillars that support the empirical process control is Transparency. Transparency will help manage stakeholder expectations and allow the teams to effectively adapt if and when needed.

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. In other words, it can be defined as the long-term consequences of poor design decisions. Technical debt is a real risk that can genuinely be incurred. It compromises the long-term quality of the Product. So it creates a greater percentage of the product's budget to be spent on maintenance of the product and the velocity gets reduced.

At the end of a Sprint, the new Increment must be ‘Done’, which means it must be in useable condition and meet the Scrum Team’s definition of ‘Done’. 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 it is used to assess when work is complete on the product Increment.

When a Product Backlog item or an Increment is described as 'Done', everyone must understand what 'Done' means. Scrum Team members must have a shared understanding of what it means for work to be complete, to ensure transparency and is used to assess when work is complete on the product Increment. This Definition of Done provides the team guidance on what it takes to make the Increment shippable.

Scrum does manage risk, with the early delivery of a valuable product and allows inspection and adaption with frequent reviews and feedback.

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.

In this scenario, the Product Owner needs help in product backlog management & empirical product planning.

The Scrum Master serves the Scrum Team. The Scrum Master helps the Scrum Team understand which of their interactions are helpful and which are not. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

At the end of a Sprint, the new Increment must be 'Done', which means it must be in useable condition and meet the Scrum Team's Definition of Done.

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.

One of the key responsibilities of the scrum masters is removing impediments to the Developers' progress. Here clarity of items in Product Backlog is the impediment and Product Owner not showing up or canceling meeting are the impediments which Scrum Master should remove by coaching Product Owner on his or her responsibility and ensuring clarity for the items that are high in priority in the product backlog and his or her responsibility to work with the team on backlog refinement. If the issue still persists Scrum Master should escalate this to senior management.

The bug represents work to be done to make the increment shippable $&$ if it is critical or easy to fix there is no need to put it in the product backlog. e.g. for an easy bug, it will take much time to put it in backlog and reprioritize compare to fixing this within the increment. But if it is non-critical then put it on product backlog so that it can be prioritized.

Scrum uses empiricism to improve predictability, whilst framing variability in terms of the people involved and the practices they follow. So how the organization discusses and plans the work of creating software will be reflected in the implementation of that software.

All Scrum Teams agree on a shared Definition of Done. At the end of every Sprint, one Increment must be "Done," which means it must be in useable condition and meet the Scrum Team's Definition of Done. The Sprint Review is held at the end of the Sprint to provide feedback on the Integrated Increment that all the Scrum Teams have built over the Sprint. During the Sprint Review, the entire Integrated Increment is the focus for capturing feedback from stakeholders. Scrum recognizes no sub-teams in the Developers, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis. Individual Developers may have specialized skills and areas of focus, but accountability belongs to the Developers as a whole. Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. Multiple Scrum Teams for 1 Product $=>1$ Product Backlog $=>1$ Product Owner.