Free Practice Questions for Scrum PSM-II Exam

Scrum is a framework for addressing complex adaptive problems, such as product development, that require empirical process control and frequent inspection and adaptation. Scrum helps to mitigate the risks of:

The timescale of the planned work (A), by delivering potentially releasable increments of value at the end of each Sprint, which is a fixed time-box of one month or less.

The stability and complexity of the technology (B), by allowing the Development Team to self-organize and choose the best way to create a “Done” increment that meets the Definition of Done.

The complexity and unpredictability of the requirements ©, by enabling the Product Owner to manage the Product Backlog, which is an ordered list of what is needed in the product and can change as more is learned about the product, users, market, and technology.

The skills and working relationships of the people on the teams (D), by fostering a culture of collaboration, transparency, and accountability among the Scrum Team members and stakeholders.

References: : [Scrum Guide], Introduction : [Scrum Guide], The Sprint : [Scrum Guide], The Development Team : [Scrum Guide], The Product Backlog : [Scrum Guide], Scrum Values

The Scrum Value of openness can easily impact all of the aspects listed in the question. Openness means that the Scrum Team and the stakeholders agree to be transparent about their work, their challenges, their learnings, and their progress. This fosters a culture of collaboration, trust, feedback, and continuous improvement. Openness also helps to ensure that the product quality meets the expectations of the customers and the stakeholders, and that the product is delivered in a timely manner. Openness also contributes to employee satisfaction, as it allows the Scrum Team members to express their opinions, share their ideas, and learn from each other.

References:

The Scrum Guide, section 2.2 (Scrum Values), page 6

The Scrum Master Learning Path, module 1 (Scrum Theory), lesson 3 (Scrum Values)

When scaling Scrum, it is important to have multiple Scrum Teams working from one Product Backlog, because this ensures that they are aligned on the same product vision, goal, and value12. Having one Product Backlog also helps to reduce duplication, inconsistency, and waste, and to optimize the flow of work and feedback12. The Product Owner is accountable for managing the Product Backlog and ensuring that it is transparent, ordered, and refined for the multiple Scrum Teams3 . The Scrum Teams collaborate with the Product Owner and each other to deliver a single integrated product Increment every Sprint3 .

References: 1: What is Scaling Scrum? | Scrum.org 2: Scaling Scrum with Nexus | Scrum.org 3: Scrum Guide | Scrum Guides : The Nexus Framework for Scaling Scrum: Continuously Delivering an Integrated Product with Multiple Scrum Teams

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

B. Developers with an interest in Stella’s domain could volunteer to take on this work in their respective Scrum Teams.

This is a good solution because it is consistent with the Scrum value of commitment, which means that the Scrum Team members are willing to learn new skills and take on new challenges to deliver value12. By volunteering to take on this work, the Developers can reduce the dependency on Stella, increase their cross-functionality, and collaborate more effectively within and across the Scrum Teams34. F. Ask Stella for a plan to hire and train additional people in her domain, and in the meantime work with the Product Owner and Scrum Teams to re-prioritize the work so that tasks not depending on Stella can be done first

This is another good solution because it is consistent with the Scrum principle of empiricism, which means that the Scrum Team learns and adapts based on the actual outcomes and feedback, rather than following a predefined plan12. By asking Stella for a plan to hire and train additional people, the Scrum Master can help address the root cause of the dependency and create more capacity and diversity in Stella’s domain. By working with the Product Owner and Scrum Teams to re-prioritize the work, the Scrum Master can also help optimize the value and feasibility of the product backlog items, and enable the Scrum Teams to deliver valuable and functional increments every Sprint34. G. Create a team with Stella and identify people from the Scrum Teams to temporarily work in Stella’s domain to learn to better serve the existing teams

This is also a good solution because it is consistent with the Scrum value of respect, which means that the Scrum Team members appreciate and value eachother’s skills and perspectives12. By creating a team with Stella, the Scrum Master can acknowledge and leverage Stella’s expertise and experience in her domain. By identifying people from the Scrum Teams to temporarily work in Stella’s domain, theScrum Master can also facilitate knowledge transfer and skill development among the team members, which can improve their self-organization and collaboration34.

References: 1: Scrum Values | Scrum.org 2: Scrum Values - Atlassian 3: Scrum Guide | Scrum Guides 4: Scrum - What is it, how it works, & how to start - Atlassian

Technical debt is the implied cost of rework caused by choosing an easy solution now instead of a better approach that would take longer1. Reducing the Definition of Done for the next three Sprints will create technical debt, which will have negative impacts on the product quality, value, and delivery. Two ways to explain these impacts to the Product Owner are:

Releasing the version creates false assumptions about the actual state of the system. This is likely to result in interruptions during future Sprints in order to react to unforeseen problems arising from not having met the Definition of Done2. This will reduce the transparency, predictability, and adaptability of the Scrum process, and compromise the trust and satisfaction of the customers and stakeholders.

As development progresses and functionality is added upon the reduced Definition of Done, unknown errors will creep in. The system becomes more difficult to stabilize. Work for the actual release as well as future releases will be slowed down in unpredictable ways3. This will increase the complexity, risk, and cost of the product development, and lower the value and quality of the product.

References:

What is Technical Debt in Scrum?| StarAgile, section “The technical debt is created when”.

Technical Debt & Scrum: Who Is Responsible?| Scrum.org, section “What Is Technical Debt?”.

Managing Technical Debt in a Scrum Project | SCRUMstudy Blog, section “Technical debt accrues”.

 Respect is one of the Scrum values that means recognizing the value of each individual and their contribution, trusting them to fulfill their tasks, listening to and considering their ideas, and acknowledging their accomplishments. Respect also means honoring the diversity of people, their experiences, and their opinions. Respect facilitates collaboration, learning, and creativity in the Scrum Team.

Some statements that demonstrate respectful behavior in the Scrum Team are:

Respect the accountabilities of the Scrum Team members. This means that each role in the Scrum Team has a clear set of responsibilities and expectations, and that other team members respect those boundaries and do not interfere with or undermine them. For example, the Product Owner is accountable for maximizing the value of the product and the work of the Developers, and the Developers respect that by following the Product Owner’s guidance on what to work on and what not to work on. The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide, causing change that increases the productivity of the Scrum Team, and working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization. The Developers respect that by adhering to the Scrum framework, being open to feedback and improvement, and collaborating with other Scrum Teams when needed.

Respect people, their experience, diversity, and difference in opinion. This means that each person in the Scrum Team is valued as a skilled professional who brings unique perspectives and insights to the team. The team members respect each other’s expertise, skills, and ideas, and are willing to learn from each other and from their stakeholders. They also respect that people may have different opinions or preferences on how to approach a problem or a solution, and they seek to understand those differences rather than dismiss or ignore them. They engage in constructive dialogue and respectful disagreement when necessary, and they support team decisions even if they are not their personal choices.

Some statements that do not demonstrate respectful behavior in the Scrum Team are:

Respect the Product Owner by letting them change the Sprint Goal during the Sprint. This is not respectful because it violates the Scrum framework and undermines theDevelopers’ autonomy and commitment. The Sprint Goal is a shared objective that provides guidance to the Developers on why they are building an Increment. It is crafted by the Product Owner in collaboration with the Developers during Sprint Planning, and it remains fixed for the duration of the Sprint unless a significant change occurs that invalidates it. Allowing the Product Owner to change the Sprint Goal during the Sprint would disrupt the focus and alignment of the Developers, introduce uncertainty and confusion, and reduce transparency and accountability.

Respect stakeholder expectations that Scrum Teams will meet their forecast. This is not respectful because it implies that stakeholders have unrealistic or unreasonable expectations that are not based on empirical evidence or feedback. The forecast is a plan for what functionality will be delivered in an Increment by the end of a Sprint. It is based on what is known at Sprint Planning, but it is not a guarantee or a commitment. The forecast may change during the Sprint as new information emerges or as unforeseen challenges arise. The Scrum Team respects stakeholders by being transparent about their progress and any changes to their forecast, by delivering a valuable Increment at least by the end of every Sprint, by seeking feedback from stakeholders during Sprint Review, and by incorporating that feedback into future Sprints.

References:

The Scrum Values

Understanding the 5 Scrum Values

Top 5 Scrum Values & Principles

B: Developers can artificially increase velocity by incurring technical debt. This is a true statement, as some Developers may choose to take shortcuts or compromise on quality in order to deliver more work in a Sprint. However, this is not a sustainable or ethical practice, as it will create more problems and costs in the future. The Scrum Master can help the Developers to avoid this temptation and focus on delivering value and quality instead.

D: Velocity may unexpectedly drop when the Developers run into technical debt while attempting to complete new Product Backlog items. This is a true statement, as technical debt can act as a drag on the productivity and progress of the Developers. Technical debt can make the work more difficult, complex, or risky, and may require more time and effort to fix or refactor. The Scrum Master can help the Developers to identify and manage technical debt, and communicate its impact to the Product Owner and the stakeholders.

References:

How Technical Debt Affects Your Velocity1

Understanding the impact of technical debt on the capacity and velocity2

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.

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