PSM-2 Practice Questions

The Scrum Master is responsible for promoting and supporting Scrum, which includes helping the

Scrum Team and the organization understand and enact Scrum values, principles, and practices. The

Scrum Master should offer guidance that:

Addresses the root cause of the conflict, not just the symptoms or the consequences.

Empowers the Scrum Team to self-organize and collaborate effectively, without relying on external

intervention or authority.

Fosters a culture of transparency, inspection, and adaptation, where feedback is welcomed and used

to improve the product and the process.

Focuses on delivering value to the customer and meeting the Sprint Goal, not on following a fixed

plan or satisfying individual p

.

Therefore, the best option is to address why requirements change during the Sprint Retrospective ©,

which is an event that allows the Scrum Team to inspect how they worked together and create a plan

for improvements. The Scrum Master should ask the Developers and the Product Owner to talk

about why the requirements are changing and consider the impact on value during this discussion.

This will help them understand each other’s perspectives, clarify their expectations, and align their

goals.

The other options are not appropriate because they:

Take everyone to a 2-day off-site event to relax and re-align (A), which may be a nice gesture, but

does not solve the underlying problem or help the Scrum Team improve their collaboration skills. It

may also be seen as a distraction or a reward for poor performance.

Ask each person’s functional manager to instruct their employees that they must collaborate better,

or be removed from the team (B), which undermines the self-organization and autonomy of the

Scrum Team and introduces a threat of punishment that may damage trust and motivation. It also

violates the Scrum value of respect and the principle of servant leadership.

Ask for a project manager or other external resource to mediate and temporarily take over for the

Product Owner (D), which creates a dependency on an outsider who may not have the necessary

knowledge, authority, or vision to manage the product. It also violates the Scrum role of the Product

Owner and the principle of single-wringable-neck.

Reference: : [Scrum Guide], The Scrum Master : [Scrum Guide], The Sprint Retrospective : [Scrum

Guide], The Product Owner : [Scrum Guide], The Developers : [Scrum Guide], Scrum Values

User acceptance testing is a process of verifying that the product meets the user’s needs and

expectations. It is an important feedback mechanism that helps the Scrum Team validate their

assumptions, inspect the value and quality of the Increment, and adapt their plans accordingly.

Scrum requires that the Increment be transparent, meaning that it is observable and understandable

by anyone with a stake in the outcome. Scrum also requires that the feedback loop be short, meaning

that the Scrum Team can receive and respond to feedback quickly and frequently.

Therefore, it is not a good idea to have user acceptance testing done every third Sprint, because:

The Increment will not be transparent (B), meaning that the Scrum Team and the stakeholders will

not have a clear and shared understanding of what has been done and what remains to be done. This

may lead to misalignment, confusion, or conflict over the product vision, scope, and quality.

The feedback loop is too long (B), meaning that the Scrum Team will not be able to inspect and adapt

based on the user’s feedback in a timely manner. This may lead to wasted effort, missed

opportunities, or reduced value delivery.

The other options are not correct because:

It does not depend on what is stated in their Definition of Done (A), which is a formal description of

the state of the Increment when it meets the quality standards required for the product. The

Definition of Done does not dictate how or when user acceptance testing should be done, but rather

what criteria must be met for the Increment to be considered “Done”.

The Scrum Team is a self-managing team ©, which means that they have the autonomy and

authority to organize and manage their own work within the boundaries of Scrum. However, this

does not mean that they can ignore or postpone user feedback, which is essential for delivering

value and satisfying customer needs.

The Scrum Team needs stability in the Sprint (D), which means that they need to have a clear and

consistent Sprint Goal, Sprint Backlog, and Definition of Done throughout the Sprint. However, this

does not mean that they need to avoid or resist user feedback, which is a source of learning and

improvement for the product and the process.

Reference: : [Scrum Guide], The Increment : [Scrum Guide], Transparency : [Scrum Guide], The

Definition of Done : [Scrum Guide], The Scrum Team : [Scrum Guide], The Sprint Goal

A Product Backlog item is a description of a feature or functionality that adds value to the product. It

is selected by the Scrum Team during the Sprint Planning, based on the Product Owner’s proposal

and the Developers’ forecast. It is expected that the Product Backlog item will be completed by the

end of the Sprint, meaning that it meets the Definition of Done, which is a formal description of the

state of the Increment when it meets the quality standards required for the product.

However, if a Product Backlog item is not completed by the end of the Sprint, meaning that it does

not meet the Definition of Done, then:

The item is not included in the Increment for this Sprint (B), which is a valid option as it ensures that

only “Done” work is delivered to the customer and stakeholders. The Increment is a concrete and

usable outcome of a Sprint that provides value and feedback. It should not contain any undone or

partially done work that may compromise its quality, usability, or value.

It is put on the Product Backlog for the Product Owner to decide what to do with it (D), which is

another valid option as it respects the authority and accountability of the Product Owner to manage

the Product Backlog, which is an ordered list of what is needed in the product. The Product Owner

can decide whether to re-prioritize, re-estimate, refine, or remove the incomplete Product Backlog

item based on new insights and stakeholder needs.

The other options are not correct because they:

Review the item, add the done part of the estimate to the velocity and create a Story for the

remaining work (A), which is not a good option as it violates the principle of commitment and

transparency that underlies the Definition of Done. The Scrum Team should not count or report any

work that is not “Done” as part of their progress or performance. The Scrum Team should also not

split or create new Product Backlog items during or after the Sprint, as this may affect their

alignment and focus on the Sprint Goal.

Only the stakeholders decide over acceptance of undone work and whether to release it ©, which is

not a good option as it violates the role and responsibility of the Product Owner and the Developers

to deliver a potentially releasable Increment at the end of each Sprint. The stakeholders can provide

feedback and suggestions for the product, but they cannot accept or release any work that does not

meet the Definition of Done.

Reference: : [Scrum Guide], The Product Backlog : [Scrum Guide], The Definition of Done : [Scrum

Guide], The Increment : [Scrum Guide], The Sprint Planning : [Scrum Guide], The Product Owner :

[Scrum Guide], The Developers

The Scrum values of courage, openness, and respect are touched in this situation. Courage means

that the Scrum Team members have the courage to do the right thing and work on tough problems,

and also to speak up when they have concerns or disagreements. Openness means that the Scrum

Team members and stakeholders agree to be open about all the work and the challenges with

performing the work. Respect means that the Scrum Team members respect each other to be

capable, independent people, and also respect the opinions and ideas of others.

In this case, the newest developer showed courage by expressing his feelings during the Sprint

Retrospective, which is an opportunity for the Scrum Team to inspect itself and create a plan for

improvements. The rest of the Developers should have been more open to listening to his

perspective and ideas throughout the Sprint, as they might have valuable insights or suggestions for

improving the product or the process. The Developers should also have respected the newest

developer as a member of the team, and given him a fair chance to contribute and collaborate with

them.

Reference:

The Scrum Guide, November 2020, p. 13-14

What are the 5 Scrum Values?, Visual Paradigm, accessed on September 30, 2023

Scrum Values Poster, Scrum.org, accessed on September 30, 2023

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.

Reference:

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 Definition of Done is a formal description of the state of the Increment when it meets the quality

standards required for the product. The purpose of the Definition of Done is to:

During the Sprint, it helps the Developers identify the work remaining for an Increment to be ready

for release by the end of a Sprint (B), by providing a clear and shared understanding of what “Done”

means for each Product Backlog item and the Increment as a whole.

It creates transparency into the state of the Increment when it is inspected at the Sprint Review ©,

by ensuring that everyone involved in the product development has the same expectations and

criteria for evaluating the value, usability, and quality of the Increment.

It guides the Developers when creating a forecast at the Sprint Planning (D), by enabling them to

estimate how much work they can realistically complete within a Sprint, based on their capacity,

skills, and Definition of Done.

Reference: : [Scrum Guide], The Definition of Done : [Scrum Guide], The Increment : [Scrum Guide],

The Sprint Review : [Scrum Guide], The Sprint Planning

As the Scrum Master, your role is to serve the Scrum Team by helping them to work effectively and

deliver value. You are not responsible for managing the work or assigning tasks to the Developers.

You should respect the self-organization and autonomy of the Developers, and support them in

finding their own solutions to the problem. You should also facilitate collaboration and

communication among the Developers and with other stakeholders.

Some reasons why option B is the correct answer are:

Asking the Developers what value they get by having the Daily Scrum with all team members present

and what might go wrong if all Developers do not attend. This action will help the Scrum Team to

understand the purpose and benefits of the Daily Scrum, and to identify and address the risks and

consequences of missing it. The Daily Scrum is a 15-minute event for the Developers of the Scrum

Team to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting

the upcoming planned work12. The Daily Scrum also provides an opportunity for the Developers to

identify and communicate any impediments that are hindering their progress, and request help from

the Scrum Master or other team members to resolve them12. The Daily Scrum improves

communications, identifies impediments, promotes quick decision-making, and consequently

eliminates the need for other meetings12. The Daily Scrum is not a status meeting, but a way for the

Developers to collaborate and self-organize around the most important work for the next 24 hours12.

If a Developer is missing the Daily Scrum, they may miss important information, feedback, or support

from their peers, or they may cause delays, confusion, or conflicts for their team. The Scrum Master

should encourage the Developers to share their perspectives and experiences on how the Daily

Scrum helps them achieve their Sprint Goal and create a valuable Increment.

The Scrum Master should also help the Developers to come up with their own solutions on how to

ensure full attendance and participation in the Daily Scrum. The Scrum Master should not impose or

dictate a solution, but rather coach and guide the Developers to find what works best for them. The

Scrum Master should also help the Developers to agree on some ground rules or norms for their

Daily Scrum, such as when, where, and how to conduct it, what topics to discuss, and how to handle

any issues or conflicts that may arise.

Some reasons why the other options are not correct are:

A: You do not intervene. The Developers own the Daily Scrum, so they should deal with any issues

with attendance. This option is not correct because it violates the Scrum Master role. The Scrum

Master is accountable for establishing Scrum as defined in the Scrum Guide1, causing change that

increases the productivity of the Scrum Team1, and working with other Scrum Masters to increase

the effectiveness of the application of Scrum in the organization1. The Scrum Master should not

ignore or avoid a problem that affects the performance or well-being of the Scrum Team, but rather

help them address it in a constructive and respectful way. The Scrum Master should also not assume

that the Developers know how to deal with any issues with attendance, but rather teach them how

to do so effectively.

C: Talk to the Developer who is missing the Daily Scrum and ask her to always attend the Daily Scrum.

This option is not correct because it violates the Scrum framework and the Scrum Master role. The

Daily Scrum is an event for and by the Developers12, not for reporting or accountability to anyone

else. The Scrum Master should not interfere with or dictate how the Developers conduct their Daily

Scrum, or make unilateral decisions on behalf of them. The Scrum Master should also not single out

or confront a Developer who is missing the Daily Scrum, but rather involve all Developers in finding a

solution that works for everyone.

D: Teach the Developers how to deal with this situation by attending the Daily Scrum yourself. This

option is not correct because it violates the Scrum framework and the Scrum Master role. The Daily

Scrum is an event for and by the Developers12, not for anyone else’s inspection or intervention. The

Scrum Master should not attend or participate in the Daily Scrum unless they are actively working on

items in the Sprint Backlog12. The presence of an outsider may disrupt or influence the dynamics of

the Developers’ communication and collaboration. The Scrum Master should also not teach by doing,

but rather by coaching and facilitating.

Reference:

What is a Daily Scrum? | Scrum.org

What Is a Daily Standup? | A Guide to Running Effective Standup Meetings | Atlassian

This is a good option because the Scrum Master’s role is to help the Scrum Team understand and

apply the Scrum framework and its principles12. The Scrum Master should also facilitate and enable

the team’s self-organization and collaboration12. By coaching the Scrum Team, the Scrum Master

can help them realize that the Daily Scrum is not a status update or a performance review, but a time

to inspect and adapt their progress toward the Sprint Goal3 . D. Tell the Product Owner your concerns

about how his behavior may impact the Developers, and ask him to stop attending the Daily Scrum

for some time.

This is another good option because the Scrum Master’s role is to protect the Scrum Team from

external interference and distractions12. The Scrum Master should also coach the Product Owner on

how to maximize the value of the product and collaborate effectively with the Developers12. By

telling the Product Owner your concerns, you can help him understand that his behavior may create

pressure, dependency, or resentment among the Developers, which can harm their motivation,

creativity, and autonomy . By asking him to stop attending the Daily Scrum for some time, you can

give the Developers some space to self-manage their work and communication.

Reference: 1: What is a Scrum Master? | Scrum.org 2: What is a scrum master? [+ Responsibilities] |

Atlassian 3: What’s the role of the Product Owner at the Daily Scrum? | by Maarten Dalmijn | Serious

Scrum | Medium : Scrum Guide | Scrum Guides : Product Owner’s Role in a Daily Scrum: How to

Support the … - Eleken : The Power of Intrinsic Motivation - Forbes

A Definition of Ready (DoR) is a set of agreements that lets everyone know when a product backlog

item is ready to be taken into a sprint12. A DoR can help the Scrum Team ensure that the product

backlog items are clear, feasible, valuable, and testable12. However, a DoR does not necessarily

maximize the team’s velocity, nor does it ensure that the sprint planning can end within its

timebox. Velocity is a measure of how much work a team can complete in a sprint, and it depends on

many factors, such as the team’s capacity, skills, collaboration, and quality standards3 . A DoR may

help the team avoid wasting time on unclear or incomplete items, but it does not guarantee that the

team can deliver more value or faster. Similarly, a DoR may help the team prepare for the sprint

planning, but it does not guarantee that the team can finish the planning within its timebox. The

sprint planning is an empirical and collaborative event, where the team inspects the product

backlog, negotiates with the product owner, and crafts a sprint goal and a sprint backlog . A DoR may

reduce some uncertainties and risks, but it does not eliminate them. The team still needs to adapt to

changing requirements and expectations, and make realistic and meaningful commitments .

Reference: 1: What is Definition of Ready in Scrum? - Visual Paradigm 2: Walking Through a

Definition of Ready | Scrum.org 3: What is Velocity in Agile? - Atlassian : Velocity in Scrum |

Scrum.org : Sprint Planning | Scrum.org : Sprint planning - Atlassian

Using Scrum does not ensure that adding more resources to a project proportionally increases the

value delivered. In fact, adding more resources may have the opposite effect, as it can introduce

more complexity, communication overhead, coordination challenges, and integration

issues12. Scrum values quality over quantity, and focuses on delivering the most valuable and

feasible outcomes in a given timebox3 . Scrum also encourages teams to be self-organizing and

cross-functional, which means that they can work autonomously and collaboratively without relying

on external resources or dependencies3 .

Reference: 1: Adding more resources in Scrum will proportionally increase the value … 2: The

Mythical Man-Month - Wikipedia 3: Scrum - What is it, how it works, & how to start - Atlassian : How

Scrum Teams can Complement Scrum by Adding Practices, Tools and …