Pass the Scrum Professional Scrum Master PSM-II Questions and answers with ValidTests

The Sprint Goal is a short and clear description of what the Scrum Team wants to achieve in the Sprint. It is a commitment that provides guidance and focus for the Scrum Team throughout the Sprint. The Sprint Goal is:

Created by the Scrum Team during the Sprint Planning, based on the Product Owner’s proposal and the Developers’ forecast (A).

Respected by the Product Owner, who does not change it or add new work that endangers it during the Sprint (B).

Helpful for increasing focus, as it helps the Scrum Team align their actions and decisions with a common objective ©.

Discussed openly by the Scrum Team, who can explore different ways to reach it and adapt their plan as needed within the Sprint (D).

Fixed and immutable for the duration of the Sprint, unless a significant change occurs that makes it obsolete or invalid. In that case, the Sprint may be cancelled by the Product Owner (E).

Communicated courageously by the Developers, who inform the Product Owner as soon as possible if they encounter any impediments or risks that may prevent them from achieving it (F).

Therefore, the statement that is incorrect is that the Sprint Goal is only a forecast and may change within the Sprint as more is learned (E), because this contradicts the principle of commitment and stability that underlies the Sprint Goal.

References: : [Scrum Guide], The Sprint Goal : [Scrum Guide], The Sprint Planning : [Scrum Guide], The Product Owner : [Scrum Guide], The Developers : [Scrum Guide], Cancelling a Sprint : [Scrum Guide], Scrum Values

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.

References:

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

User documentation is part of your Definition of Done, which means that it is a requirement for delivering a potentially releasable product increment. Your Scrum Team cannot ignore or postpone this requirement, even if there are not enough technical writers for all teams. Your Scrum Team is responsible for creating and maintaining the user documentation, and the Developers are the ones who have the skills and authority to do so. The Scrum Master can help the Developers learn how to write effective user documentation, and the Product Owner can provide feedback on its quality and value.

References:

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 10: “The Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.”

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 “Quality Assurance and Release Readiness Sprint” is not a Scrum concept, but a sign of poor engineering practices and weak adherence to the Scrum values and principles. It indicates that the Scrum Team is not delivering a potentially releasable product Increment every Sprint, which is one of the core commitments of Scrum. This could be due to a weak or incomplete Definition of Done, which allows technical debt to accumulate and compromises the quality and usability of the product. It could also be due to the Developers finding it nearly impossible to create a valuable, useful product Increment in a Sprint, which could be caused by various factors such as lack of skills, tools, collaboration, feedback, or empowerment. The Definition of Done is not being met every Sprint, which means that the Scrum Team is not fulfilling its accountability for the Increment and is not transparent about the state of the product.

References:

Scrum Guide 2020, section “Commitments”, “Definition of Done”, “The Sprint”, “The Increment”.

Advanced Knowledge of Scrum, section “Definition of Done”, “Technical Debt”.

Scrum Master Accountabilities, section “Accountability for Effectiveness”.

The Product Owner is responsible for maximizing the value of the product and the work of the Developers. The Product Owner is also accountable for managing the Product Backlog, which is an ordered list of what is needed in the product. The Product Owner should collaborate with the Developers and the stakeholders to create and refine the Product Backlog, as well as to define and communicate the product vision and goals. Therefore, as a Scrum Master, you should direct the new Product Owner towards focusing on:

Building a good relationship with the stakeholders of the product (A), which is a valid option as it helps the Product Owner to understand and align with the changing organizational or market expectations, as well as to invite and receive feedback from the appropriate stakeholders during the Sprint Review, which is an event that inspects the outcome of the Sprint and determines future adaptations.

Relying on others in the Scrum Team and the stakeholders to formulate the Product Backlog (D), which is another valid option as it helps the Product Owner to leverage the functional and business insights of the Developers and the stakeholders, who are more familiar with the product and the customer needs. By questioning them and working with them, the Product Owner will quickly become more productive and effective.

The other options are not correct because they:

Inform the Product Owner that it is important that the Developers are updated on changing business priorities on a daily basis at the Daily Scrum (B), which is not a good option as it shows a misunderstanding of the purpose and format of the Daily Scrum, which is an event for the Developers to inspect their progress and plan their work for the next 24 hours, not a status report or a meeting for changing requirements or scope. The Product Owner should respect and support the Developers’ commitment to their Sprint Goal and Sprint Backlog, and only introduce changes that do not endanger them.

Tell the Product Owner to make sure that there are no ambiguities or possible misunderstandings in the items on the Product Backlog by capturing the functional requirements during an analysis phase ©, which is not a good option as it shows a misunderstanding of the nature and process of the Product Backlog, which is a dynamic and emergent artifact that can change as more is learned about the product, users, market, and technology. The Product Owner should collaborate with the Developers to refine and clarify the Product Backlog items throughout the product development, not create detailed documents that are considered as final outputs of analysis Sprints.

References: : [Scrum Guide], The Product Owner : [Scrum Guide], The Product Backlog : [Scrum Guide], The Sprint Review : [Scrum Guide], The Scrum Master : [Scrum Guide], The Developers : [Scrum Guide], The Daily Scrum

A. They discuss in the upcoming Sprint Retrospective why this happened and what changes will make it less likely to recur. This is a good action to take, as it shows that the Scrum Team is willing to inspect and adapt their process and improve their collaboration and communication. The Sprint Retrospective is an opportunity for the Scrum Team to identify the root causes of the problem and create a plan for implementing improvements in the next Sprint.

D. The Developers forecast the most likely Product Backlog items to meet the business objective and create a Sprint Backlog based on a likely initial design and plan. Once the timebox for the Sprint Planning event is over, they start the Sprint and continue to analyze, decompose, and create additional functionality during the Sprint. This is also a good action to take, as it shows that the Scrum Team is flexible and adaptive, and does not let uncertainty or ambiguity prevent them from delivering value. The Developers can use the Sprint Goal as a guide to select and refine the Product Backlog items during the Sprint, and collaborate with the Product Owner to ensure that they are meeting the expectations and needs of the stakeholders.

References:

The Scrum Guide, section 3.1 (The Sprint), page 8

The Scrum Guide, section 3.3 (The Sprint Goal), page 9

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

The Scrum Guide, section 3.7 (The Sprint Retrospective), page 12

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 6 (The Sprint Retrospective)

Splitting a team into two teams is a major decision that should not be taken lightly. It may have implications for the product vision, the product backlog, the sprint goal, the sprint backlog, the definition of done, and the team dynamics. It may also reduce the effectiveness of the Scrum Team by creating dependencies, communication overhead, and coordination challenges. Therefore, before considering such a drastic measure, it is advisable to explore other options to improve the quality and efficiency of the Daily Scrum. One option is to ask for help from another Scrum Master who can observe the Daily Scrum and provide feedback and suggestions.

References:

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

The Scrum Master Learning Path, module 4 (The Daily Scrum), lesson 4 (Common Challenges) and lesson 5 (Tips for an Effective Daily Scrum)

Explanation: 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, andshould 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.

References: 1: https://www.scrum.org/resources/what-is-a-scrum-master  2: https://www.scrum.org/resources/blog/scrum-master-supporting-product-owner  3: https://www.scrum.org/resources/what-is-empiricism-and-why-is-it-important-to-scrum  4: https://www.scrum.org/resources/what-is-a-sprint-review : https://www.scrum.org/resources/blog/definition-done : https://www.scrum.org/resources/what-is-a-sprint-retrospective : https://www.scrum.org/resources/blog/facilitation-scrum-masters-superpower : https://www.scrum.org/resources/blog/quality-shared-responsibility : https://www.scrum.org/resources/blog/coaching-scrum-masters-superpower : https://www.scrum.org/resources/what-is-a-product-owner

B: The Scrum Master coaches the Scrum Team and the organization how to work empirically. This is a true statement, as the Scrum Master is responsible for helpingeveryone understand and apply the principles and practices of Scrum, which is based on empirical process control. The Scrum Master can teach the Scrum Team and the organization how to use transparency, inspection, and adaptation to deliver valuable products in a complex environment.

C: The Scrum Master facilitates Scrum events as requested or needed. This is a true statement, as the Scrum Master is responsible for ensuring that all Scrum events take place and are positive, productive, and kept within the timebox. The Scrum Master can facilitate the communication and collaboration among the Scrum Team and the stakeholders during the Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.

References:

Scrum Guide 2020, page 6: “The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.”

Scrum Guide 2020, page 13: “The purpose of each event in Scrum is to create an opportunity for inspection and adaptation. These events are specifically designed to enable critical transparency and inspection.”

Professional Scrum Master II Course, page 13: “The Scrum Master serves the Scrum Team by facilitating the Scrum events and ensuring that they are effective and valuable.”

A. The stakeholders have not been using the Sprint Reviews to actively engage, and inspect and evaluate progress. This is a possible factor that may have led to the disappointment and anger of the stakeholders. The Sprint Review is an event where the Scrum Team and the stakeholders collaborate to inspect the product Increment and adapt the Product Backlog based on feedback and new insights. If the stakeholders do not participate actively in the Sprint Review, they may miss the opportunity to provide input, voice their concerns, and influence the direction of the product development.

D. The Scrum Master has not ensured transparency. This is another possible factor that may have led to the disappointment and anger of the stakeholders. The Scrum Master is accountable for establishing and promoting transparency among the Scrum Team and the stakeholders, by ensuring that everyone has a clear and common understanding of the product vision, the Product Goal, the Product Backlog, the Sprint Goal, the Sprint Backlog, and the Definition of Done. Without transparency, there may be misalignment, confusion, or unrealistic expectations among the stakeholders regarding the product being built.

E. The Product Owner has not been interacting frequently with the stakeholders and kept them aware of the progress of the project. This is also a possible factor that may have led to the disappointment and anger of the stakeholders. The Product Owner is responsible for engaging with the stakeholders regularly and communicating the value, scope, and status of the product development. The Product Owner should also seek feedback from the stakeholders and incorporate it into the Product Backlog refinement and ordering. If the Product Owner does not interact frequently with the stakeholders, they may feel disconnected, ignored, or dissatisfied with the product being built.

References:

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

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

The Scrum Guide, section 4.1 (The Product Backlog), page 11

The Scrum Master Learning Path, module 2 (The Scrum Framework), lesson 5 (The Sprint Review) and lesson 6 (The Sprint Retrospective)