Scrum Professional Scrum Master II PSM-II Exam Questions

Answer : A, E

One of the ways to do this is by facilitating the Scrum events, such as the Sprint Review, where the Scrum Team and the stakeholders inspect the product Increment and adapt the Product Backlog2. In this situation, where there is a conflict among the stakeholders about the budget and the funding, your two best options are:

Encourage the stakeholders to focus on delivering the highest value items for the next Sprint. This option aligns with the purpose of the Sprint Review, which is to collaborate on what was done in the Sprint and what to do next2. By encouraging the stakeholders to focus on delivering value, you are helping them prioritize the most important features or functionalities that can maximize the return on investment and reduce risk3. This can also help them align their expectations and goals, and create a shared understanding of the product vision.

Ask for a short break for people to calm down and be objective. This option aligns with your role as a facilitator, who helps the participants have constructive and respectful conversations4. By asking for a short break, you are giving them a chance to cool off and regain their composure. This can also help them be more objective and rational, and avoid emotional reactions that can escalate the conflict or damage the relationship.

The other options are not advisable because:

It is the Product Owner's meeting, so do nothing. This option is incorrect because it contradicts your accountability as a Scrum Master. The Sprint Review is not only the Product Owner's meeting, but a collaborative event that involves the whole Scrum Team and the stakeholders2. As a Scrum Master, you have a responsibility to facilitate this event and ensure that it is productive and valuable1. Doing nothing would mean neglecting your duty and allowing the conflict to persist or worsen.

Defend the budget, asking the stakeholders to support the funding of the work. This option is incorrect because it goes beyond your scope as a Scrum Master. The budget and the funding are not your primary concerns, but rather the value and quality of the product that you deliver1. Defending the budget would mean taking sides in the conflict, which can compromise your neutrality and credibility as a facilitator. It can also create more tension and resentment among the stakeholders, who may feel that you are not listening to their perspectives or interests.

Argue that the Scrum Team needs to be kept busy while the funding is confirmed. This option is incorrect because it contradicts the principle of empiricism, which is the foundation of Scrum5. Empiricism means that you make decisions based on what is known, rather than what is assumed or predicted5. Arguing that the Scrum Team needs to be kept busy while the funding is confirmed would mean ignoring or denying the reality of the situation, which can lead to waste or inefficiency. It can also undermine the trust and collaboration between the Scrum Team and the stakeholders, who may feel that you are not transparent or accountable.

Answer : E

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.

Answer : A, D

A: There is one Product Owner for each product (five in total). Each Product Owner may delegate to others for specific value, capabilities, and functionality within their product. The five Product Owners share and align work via Product Backlog. This is a reasonable alternative, as it allows each Product Owner to focus on one product and its vision, value proposition, and stakeholder needs. The Product Owner can also leverage the expertise and input of other people who can help with the product development, such as business analysts, domain experts, or user representatives. The five Product Owners can coordinate and collaborate with each other through the Product Backlog, which is a single source of truth for the product requirements and priorities.

D: There is one Product Owner responsible for all five products. This person may delegate work to others for specific value, capabilities, and functionality within each product to scale their accountability. This is another reasonable alternative, as it allows one Product Owner to have a holistic view of the five products and their interdependencies, synergies, and trade-offs. The Product Owner can also delegate some of the work to other people who can act as proxies or representatives for the different aspects of the products, such as features, modules, or components. The Product Owner can still maintain the ultimate authority and responsibility for the Product Backlog and the product value delivery.

Scrum Guide 2020, page 7: ''The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.''

Scrum Guide 2020, page 8: ''The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.''

Professional Scrum Master II Course, page 22: ''The Product Owner may delegate some of their work to others who can help them with the product development, such as business analysts, domain experts, or user representatives. However, the Product Owner remains accountable for the Product Backlog and its content.''

Professional Scrum Master II Course, page 23: ''The Product Owner may scale their role by working with other Product Owners who are responsible for different products, features, modules, or components. However, there should be only one Product Owner per product who has the final say on the product vision and value proposition.''

Answer : A

Coach the Product Owner that achieving the Sprint Goal is the Scrum Team's objective. A forecast is only used to initially estimate the effort required to reach the Sprint Goal.

This is true because the Scrum Master's role is to help the Product Owner understand the Scrum framework and its principles, such as empiricism, self-organization, and collaboration12.The Scrum Master should also remind the Product Owner that the forecast is not a commitment, but a plan that can be adjusted based on the Sprint progress and feedback3. The Scrum Master should focus on the value and outcome of the Sprint, rather than the output and scope.

Answer : C, D

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

Answer : D

The most effective way to recover is to restore transparency and trust by informing the Product Owner that the progress she has perceived to date is not correct.The Increment is not releasable because it does not meet the Definition of Done12, which is a shared understanding of what it means for work to be complete12. The Developers should give the Product Owner their estimate of the effort it would take to get the past work done, and suggest doing that work first before proceeding with new features.This way, the Developers can ensure that they deliver a valuable, useful, and potentially releasable Increment every Sprint12. The Developers should also re-estimate the effort to complete the remaining backlog, including all testing, and communicate any changes or risks to the Product Owner.In the end, it is the Product Owner's call to continue the project or to cancel it, based on the value and feasibility of the product12.

Some reasons why the other options are not correct are:

A: The Developers set the open work aside to be performed in one or more release Sprints. They remind Marian to find funding for enough Release Sprints in which this remaining work can be done. This option is not correct because it violates the Scrum framework and the Scrum values.The Scrum framework does not prescribe any release Sprints or separate phases for testing or integration12.The Scrum values include commitment, focus, openness, respect, and courage12. The Developers should commit to delivering a potentially releasable Increment every Sprint, not postpone or hide their undone work. The Developers should focus on creating value for the customers and users, not on meeting artificial deadlines or metrics. The Developers should be open and honest about their progress and challenges, not mislead or deceive the Product Owner.The Developers should respect the Product Owner's authority and accountability for maximizing the value of the product and the work of the Developers12, not shift the responsibility or blame to them. The Developers should have the courage to face their problems and seek help, not avoid or ignore them.

B: Transparency needs to be restored by adding the undone work to the Product Backlog. The Developers must figure out a way to deliver in the upcoming Sprints a velocity of not only 13 units of new work, but also two additional points to catch up undone work. It is the Scrum Master's duty to assess whether such repair is possible. If not, the Scrum Master initiates a restart with a more reliable team or cancels the project. The Scrum Master will have to inform Product Owner and the stakeholders. This option is not correct because it violates the Scrum framework and the Scrum roles.The Scrum framework does not prescribe any velocity or points as measures of progress or success12.The Scrum roles include Product Owner, Scrum Master, and Developers12.The Product Owner is accountable for maximizing the value of the product and the work of the Developers12, not for tracking or controlling their velocity or points.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, not for assessing or judging the performance of the Developers or initiating a restart or cancellation of the project.The Developers are accountable for creating a valuable, useful, and potentially releasable Increment every Sprint12, not for meeting a predetermined velocity or points target.

C: In the next Sprints, the Developers keep making sure that all of the selected scope per Sprint is as done as possible, at least at the past level of 90%. In every Sprint the undone work of the previous Sprint is estimated and added to the Sprint Backlog. It comes on top of the expected forecast of 13 units, so it does not mess up progress on the product Backlog. This option is not correct because it violates the Scrum framework and the Scrum values.The Scrum framework requires that each Sprint delivers a potentially releasable Increment that meets the Definition of Done12, not a partially done or incomplete product that accumulates technical debt or quality issues.The Scrum values include commitment, focus, openness, respect, and courage12. The Developers should commit to delivering a potentially releasable Increment every Sprint, not compromise on quality or value. The Developers should focus on creating value for the customers and users, not on meeting artificial deadlines or metrics. The Developers should be open and honest about their progress and challenges, not hide or ignore their undone work.The Developers should respect the Product Owner's authority and accountability for maximizing the value of the product and the work of the Developers12, not burden them with additional work or risk. The Developers should have the courage to face their problems and seek help, not avoid or ignore them.

What is an Increment? | Scrum.org

What is a Product Increment? | Scrum.org

Answer : A

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.

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)