PSM II Mock Test

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. 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 not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of Sprint's work. This open-source solution discussion should be done in an additional meeting.

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. Because the requirement did not come from Product Backlog, from the available answers and theory, it should be removed from the Increment. The team should also discuss this matter in the Sprint Retrospective so that everyone is aware of this rule. Being creative and having new ideas is a good thing for the Developers, but they should discuss with the Product Owner to add ideas to the Product Backlog or re-negotiate the scope during the Sprint as long as it does not endanger the Sprint Goal.

The principles behind the agile mindset focus on delivering value to the customer. That means that the time we spend developing the product should be spent doing something that adds value to the customer, avoiding wasting time on tasks that add little to no value. This also applies to documentation. So the documentation can be created and adjusted per feature.

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

Velocity is a measure of the amount of work a Team can tackle during a single Sprint. Also, it is not a PO's responsibility to report about the progress of the development at any given time. Team artifacts (Product Backlog and Sprint Backlogs) should provide enough clarity on the team's progress. Also, progress towards completing projected work is assessed every Sprint Review. There is no "expected level of velocity" & PO is not only accountable in the scrum, but it's also the whole team including the scrum master. So the option of discussing impediments and collaborating to remove those implements is the best option.

The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team's current Definition of Done. Time-boxing allows Scrum events to better use the time to be short enough to reduce the chances of off-topic discussions and increase focus, and long enough to work on concrete actions and to get a valuable outcome.

There's no point in finishing out the feature if the work the team is doing won't be useful. The Developers modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Developers work through the plan and learn more about the work needed to achieve the Sprint Goal. The best thing to do is to tell the team about the priority change right away so that they can help determine the best way to deal with it. The sooner they can get working on the next high-priority feature, the better. A few scenarios under which a Sprint can be canceled are if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be canceled if it no longer makes sense given the circumstances. But in this situation, only the main feature is no longer needed but if other features which are complete can be accepted by the Product Owner. So even if PO decides to cancel this sprint all the stories should not be sent back to the product backlog.

The Scrum values are commitment, courage, focus, openness, and respect. Openness allows a member of the team to ask for help without fear of being punished or judged and offer assistance to each other thus facilitating teamwork and allowing for better and more efficient productivity. Openness also enables team members to share their ideas and opinions without feeling intimidated or left out. It gives the entire "part of a team" vibe as one is able to make suggestions, reel out perspectives, and make contributions thereby allowing each and every member of the team to be part of general team decisions. The Scrum framework itself entails elements that promote openness.

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.

If requested the Scrum Master can even facilitate conversations through openended questions in order to help the team members make the best possible decisions according to what is known at the time. He/she does not approve or reject team decisions but ensures the team stays within the boundaries of the Scrum framework.

When working on complex problems in complex environments, it cannot be guaranteed that applying a specific process or tool will fix the problem. Although process and tools are important it’s more important that people collaborate and try to find different solutions together and not rely solely on a tool to fix the problem.

Product Backlog Items are not clear. The highest-order Product Backlog Items refers to the Items at the top of the Product Backlog. So Continuing the meeting with what is given and trying to make the best forecast and discuss this problem at the Sprint Retrospective. This scenario cannot lead to canceling the Sprint. The Sprint Planning meeting is never suspended or held twice. It is also not allowed to go over the time-box.

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. In Sprint planning by the end of this event, the Developers should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

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 ones that will be doing the work are the best ones to decide on what Developer's structures work best.

Changes in teams and membership always affect productivity. Gradually feature teams will become more productive as people from the different layers and components will get used to delivering unified functionality together, as one Scrum Team. The Business Value is also likely to increase. The Scrum Master should not reorganize people but let them decide how to re-arrange teams to cover all the skills as self-managing teams.

The Scrum Team resolves team conflicts internally. The Scrum Team never relies on managers to help them with team conflicts. One Product has one PO, one Product Backlog, and one Product Goal at any given time. The primary objective of a Sprint is the Sprint Goal. Ken should be updating the Product Backlog instead of the Sprint Backlog.

If the PO is surprised with the increment (the work the developers did during the Sprint) that means he or she hasn't been actively interacting with the Developers. It is not up to the Developers to choose how much time the PO should spend with them. Yes, the PO should be available to answer questions but there are no rules around that.
The PO is not required to attend Daily Scrum. The event is used by the Developers to inspect and adapt toward the Sprint Goal.

Maintainability is directly related to technical debt, if technical debt increases then it will decrease the maintainability of the product. So, make sure that the maintainability quality attribute is addressed. Rest all options are incorrect e.g. there are no separate testers everybody is a developer in a scrum team. Here the Technical Subject Matter Expert is not a role, it's an engagement. Technical debt will lead to slippage in delivery and unhappy customers.

Adding more teams will likely slow the effort down due to the learning curve. Sticking to your own plan while ignoring external realities is not adaptation. It creates non-transparency, tension, and does not solve the issue.

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. 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” to have a shared understanding of what it means for work to be complete, to ensure transparency. Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

The Daily Scrum is an internal meeting for the Development Team to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a selforganizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.
Reducing the frequency of the event will increase the length of the feedback loop and add risk if the team deviates too far off-course.

The Scrum Master needs to serve the Developers and coach the Product Owner on effective ways to communicate this concern.

One of the responsibilities of the Product Owner is to ensure the Developers understand items in the Product Backlog to the level needed. So in this situation discuss with the Product Owner the validity of the scenario. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

The trendline is based on the team’s average velocity and the projective completion to zero is based on the team’s velocity. A burn-down chart is a helpful tool for Developers to self-manage BUT it is not mandatory as the teams will decide the best way to manage their own progress and promote transparency.

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.

When a Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means. This is the definition of "Done" for the Scrum Team and is used to assess when work is complete on the product Increment. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team's current definition of "Done".

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.

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.