Free Scrum Professional Scrum Master II PSM-II Exam Questions

B: Ask the Developers and the Product Owner if removing regression testing from the Definition of Done allows the team to produce useful and valuable Increments at the end of every Sprint. This is a good way to challenge the decision and make them think about the consequences of lowering the quality standards. The Scrum Master can help them understand the importance of delivering a potentially releasable product increment that meets the expectations of the stakeholders and customers.

C: Ask the Developers and the Product Owner what problem they are going to solve by altering the Definition of Done during the Sprint to remove regression testing. Will this raise transparency or improve quality? This is a good way to explore the root cause of the issue and find out why they are not able to complete regression testing for all of the selected Product Backlog items in the Sprint. The Scrum Master can help them identify and remove any impediments or inefficiencies that prevent them from achieving their Sprint Goal.

Scrum Guide 2020, page 9: ''The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.''

Scrum Guide 2020, page 13: ''The Scrum Master serves the Scrum Team in several ways, including coaching the team members in self-management and cross-functionality.''

Professional Scrum Master II Course, page 12: ''The Definition of Done is a crucial aspect of transparency. If it is not clear when work is done, then stakeholders may make wrong assumptions about the state of the software.''

A Scrum Team is self-managing, meaning that they have the autonomy and authority to organize and manage their own work within the boundaries of Scrum. A self-managing Scrum Team:

Creates their own Sprint Backlog, reflecting all work that is part of the Definition of Done , which is a valid option as it shows that the Developers are responsible for planning and executing the work needed to deliver a potentially releasable Increment at the end of each Sprint.

Collaboratively selects and re-plans their work during the Sprint (D), which is another valid option as it shows that the Developers are able to adapt to changing requirements, priorities, or circumstances within the Sprint, without relying on external instructions or approvals.

The other options are not correct because they:

Invite management to the Daily Scrum for a progress update and subsequently work with the Scrum Master to optimize the plan for the next day (A), which is not a good option as it shows that the Scrum Team is not self-managing, but rather dependent on management intervention and direction. The Daily Scrum is an event for the Developers to inspect their progress and plan their work for the next 24 hours, not a status report for management or anyone else.

Work strictly within the boundaries of their function description, and hand off work in a timely fashion to the other members within the team (B), which is not a good option as it shows that the Scrum Team is not self-managing, but rather following a rigid and siloed structure. The Developers are cross-functional, meaning that they have all the skills necessary to create a ''Done'' Increment, and they collaborate and coordinate their work as one team, not as separate individuals or roles.

Invite the right external people to the Sprint Planning to help them create a complete and detailed Sprint Backlog before the meeting timebox expires (E), which is not a good option as it shows that the Scrum Team is not self-managing, but rather relying on external assistance and input. The Sprint Planning is an event for the Scrum Team to create a Sprint Goal and a Sprint Backlog, based on the Product Owner's proposal and the Developers' forecast. The Scrum Team may invite other people to provide advice or expertise, but they are ultimately accountable for their own plan.

As a Scrum Master, you are accountable for establishing an environment where the Scrum Team can be effective and deliver valuable products1.One of the ways to do this is by supporting the Product Owner in managing the Product Backlog and engaging with the stakeholders2. In this situation, where there is a performance issue with the product, your best option is:

Encourage the Product Owner to bring the performance concerns to the rest of the Scrum Team and work together to improve the Definition of Done.This option aligns with the principle of empiricism, which is the foundation of Scrum3.Empiricism means that you make decisions based on what is known, rather than what is assumed or predicted3.By encouraging the Product Owner to bring the performance concerns to the rest of the Scrum Team, you are helping them inspect the product Increment and adapt the Product Backlog based on transparent feedback from the stakeholder4. You are also helping them collaborate on improving the Definition of Done, which is a shared understanding of what it means for a product Increment to be complete and potentially releasable. The Definition of Done should reflect the quality standards and expectations of the stakeholders, and should be updated as needed to ensure that the product meets their needs and delivers value.

The other options are not advisable because:

Wait to bring this up in the next Sprint Retrospective as this is the appropriate time for the Developers to re-consider the Definition of Done.This option is incorrect because it contradicts your accountability as a Scrum Master. The Sprint Retrospective is an opportunity for the Scrum Team to reflect on their performance and identify improvements for the next Sprint. However, it is not the only time for them to inspect and adapt their product and process.As a Scrum Master, you should promote continuous improvement and help the Scrum Team address any issues or impediments as soon as they arise1. Waiting to bring this up in the next Sprint Retrospective would mean delaying feedback and action, which can lead to waste or dissatisfaction.

Bring the concern to the quality assurance members of the Scrum Team and ask them to improve how the system is tested.This option is incorrect because it goes against your role as a facilitator, who helps the participants have constructive and respectful conversations. By bringing the concern to only a subset of the Scrum Team, you are creating silos and excluding others from contributing or learning. You are also implying that quality is only their responsibility, rather than a shared accountability of the whole Scrum Team. Moreover, you are not asking them for their input or feedback, but telling them what to do, which can undermine their autonomy and motivation.

Explain to the Product Owner that it is up to the Developers to decide on acceptable performance standards as they own the Definition of Done.This option is incorrect because it contradicts your role as a coach, who helps people grow and improve their skills and behaviors. By explaining to the Product Owner that it is up to the Developers to decide on acceptable performance standards, you are dismissing their concern and creating a gap between them and the Developers. You are also ignoring their valuable perspective and input as a stakeholder representative, who has a clear vision of what value means for the product. Instead of explaining, you should be asking questions and listening actively, and facilitating a dialogue between them and the Developers.

C: Velocity has no direct relationship with value. This is a true statement, as velocity is a measure of the amount of work done by a Scrum Team in a Sprint, not the value or quality of that work. Velocity can vary depending on many factors, such as the size, complexity, and priority of the Product Backlog items, the skills and experience of the Developers, the Definition of Done, and the Sprint length. Therefore, velocity is not a reliable indicator of value creation or team performance.

D: Velocity is the amount of business functionality that a Scrum Team creates in a Sprint. It is unique to that team and used as an input to Sprint Planning. This is a true statement, as velocity is a team-specific metric that reflects how much business functionality the Scrum Team can deliver in a Sprint. Velocity can help the Scrum Team to forecast how many Product Backlog items they can select for the next Sprint, based on their past performance and current capacity. However, velocity is not a goal or a target for the Scrum Team, and it should not be compared across teams.

Professional Scrum Master II Course, page 15: ''Velocity is a measure of how much work a team can complete in a given time period. It is usually expressed in terms of story points or function points per Sprint.''

Professional Scrum Master II Course, page 16: ''Velocity is not a measure of value or quality. It does not tell us anything about the usefulness, usability, or desirability of the product increment.''

Professional Scrum Master II Course, page 17: ''Velocity is unique to each team and depends on many factors, such as the size and complexity of the work items, the skills and experience of the team members, the definition of done, and the length of the Sprint.''

Professional Scrum Master II Course, page 18: ''Velocity can be used as an input for Sprint Planning, to help the team forecast how much work they can realistically accomplish in the next Sprint. However, velocity is not a goal or a target for the team, and it should not be used to compare or evaluate teams.''

According to the Scrum Guide 2020, the Sprint Goal is a short statement that provides direction and focus for the Scrum Team throughout the Sprint1.The Sprint Goal is chosen by the Scrum Team during Sprint Planning, based on the Product Backlog items that they forecast to complete in the Sprint1.The Sprint Goal also gives Developers flexibility and creativity on how to implement functionality during the Sprint, as long as they do not endanger the Sprint Goal1. Therefore, the statements that are true about the Sprint Goal are:

During Sprint Planning, the Scrum Team crafts a Sprint Goal based on an objective that the Product Owner would like to achieve that Sprint.This statement is true because it reflects the purpose and process of creating a Sprint Goal.The Product Owner proposes an objective for the Sprint, based on the current state of the product and the stakeholders' needs2.The Developers then select the Product Backlog items that support that objective, and craft a Sprint Goal that expresses what value they will deliver in the Sprint2.

Sprint Goals give Developers flexibility and creativity on how to implement functionality during the Sprint.This statement is true because it reflects the benefit and outcome of having a Sprint Goal.The Sprint Goal is not a fixed scope of work, but a flexible goal that guides the Developers' decisions and actions3.The Developers can modify their Sprint Backlog during the Sprint as needed, as long as they do not endanger the Sprint Goal1.The Sprint Goal also encourages the Developers to work together rather than on separate initiatives3.

The other statements are not true because:

Sprint Goals often change during the Sprint as new insights emerge during the work.This statement is false because it contradicts the Scrum framework, which defines the Sprint Goal as a commitment by the Developers that does not change during a Sprint1.The Sprint Goal provides coherence and alignment for the Scrum Team, and helps them cope with complexity and uncertainty3. Changing the Sprint Goal during a Sprint would undermine its value and impact, and create confusion and waste.

The use of Sprint Goals is optional in the Scrum Framework.This statement is false because it contradicts the Scrum framework, which defines the Sprint Goal as a mandatory element of each Sprint1.The Scrum Guide 2020 states that ''the entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint'' and ''the Developers commit to achieving the Sprint Goal''1. Without a Sprint Goal, there would be no clear direction or focus for the Scrum Team, and no way to measure their progress or success.

B) You inform management of organizational impediments that prevent the Scrum Team from being more productive. You enlist their help to remove these impediments.

This is a good answer because it is consistent with the Scrum Master's accountability to serve the Scrum Team and the organization by identifying and addressing the factors that hinder the team's effectiveness12. By informing management of the organizational impediments, you can leverage their authority and influence to resolve them. By enlisting their help, you can also foster a collaborative and supportive relationship with them. C. You explain how a Scrum Team uses the velocity of a Sprint primarily to forecast work for the next Sprint, not to perfectly predict future productivity. You refer management to the Product Owner for all information concerning the progress of development.

This is another good answer because it is consistent with the Scrum Master's accountability to educate and coach the organization on the Scrum framework and its principles12. By explaining how velocity is used in Scrum, you can help management understand that it is not a reliable metric for measuring performance or comparing teams.By referring management to the Product Owner, you can also respect the Product Owner's accountability to manage the product backlog and communicate the value and status of the product34.

Short Scrum is a framework for delivering value to customers and stakeholders in an iterative and incremental way. Scrum does not prescribe how project budgeting and financial forecasting should be performed, but it does provide some principles and practices that can help with this process.

One of these principles is that each Sprint should produce a potentially releasable product Increment that delivers value and meets the Definition of Done. This means that several Sprints may be funded as a single release, with the result of each Sprint being releasable product12. This allows the Product Owner to decide when to release the product based on the feedback from the customers and stakeholders, and the market conditions.

Another principle is that Scrum promotes transparency, inspection, and adaptation. This means that the budgeting and forecasting process should be revisited as frequently as each Sprint to ensure value is being delivered for the investment spent13. This allows the Scrum Team to inspect the outcomes of the delivered Sprint Increments, compare them with the expected benefits and costs, and adapt the product backlog and the release plan accordingly.

Scrum does not align with traditional accounting practices that require fixed scope, cost, and time. However, this does not mean that Scrum Teams do not need a budgeting process or that they only need to cover the run cost (time and materials) of the Scrum Teams. Scrum Teams still need to estimate the size and value of the product backlog items, forecast the delivery date and cost of the product or release, and track the actual spending and revenue of the product or release43. The difference is that these estimates and forecasts are based on empirical data from previous Sprints, rather than on upfront assumptions or guesses. They are also subject to change as new information emerges or new requirements arise.

Scrum Guide 2020, section ''The Sprint'', ''The Increment'', ''Empiricism''.

Tips for Effective Agile Budgeting and Forecasting | Toptal, section ''Establish Context and Set Expectations'', ''Budget for Value''.

Project forecasts and budgets | Microsoft Learn, section ''Project forecasting''.

Planning and Budgeting in Scrum Projects - PMHut, section ''Budgeting in Scrum Projects''.

A) Developers collaboratively select and re-plan their work during the Sprint. This situation demonstrates that the Scrum Team is self-managing, as it shows that the Developers have the autonomy and authority to decide how to best accomplish their work, without being directed by others outside the team. The Developers can also adapt their plan based on new insights, feedback, or impediments that arise during the Sprint.

C) The Developers create their own Sprint Backlog, reflecting all work that is part of the Definition of Done. This situation also demonstrates that the Scrum Team is self-managing, as it shows that the Developers have the responsibility and accountability to create a realistic and achievable plan for the Sprint, based on their understanding of the Sprint Goal and the Product Backlog items. The Developers also ensure that their work meets the quality standards defined by the Definition of Done.

The Scrum Guide, section 2.3 (The Scrum Team), page 7

The Scrum Guide, section 3.2 (The Daily Scrum), page 9

The Scrum Guide, section 3.5 (The Sprint Planning), page 10

The Scrum Guide, section 3.6 (The Sprint Review), page 11

The Scrum Master Learning Path, module 2 (The Scrum Framework), lesson 2 (The Sprint), lesson 3 (The Sprint Goal), lesson 4 (Sprint Planning) and lesson 5 (The Sprint Review)

The Professional Scrum Master II (PSM II) Assessment, question 39

This is the best answer because it empowers the Developers to take ownership of their own process and find a solution that works for them. The Scrum Master can facilitate the discussion and help the Developers understand the value and importance of the Daily Scrum, but not impose or dictate any specific action or rule. The Scrum Master can also support the Developers in conducting an experiment and evaluating the results, if they decide to do so.

Scrum Guide 2020, page 13: ''The Scrum Master serves the Scrum Team in several ways, including coaching the team members in self-management and cross-functionality.''

Professional Scrum Master II Course, page 14: ''The Daily Scrum is a key opportunity for inspection and adaptation at the team level. It helps the team to synchronize their work, identify impediments, and collaborate on solutions.''

Professional Scrum Master II Course, page 21: ''The Scrum Master can help the team to resolve conflicts by facilitating dialogue, listening actively, asking powerful questions, and supporting collaborative decision making.''

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)