Scrum Scrum Certifications PSPO-I Questions & Answers

• Question 81:

  Why does the Product Owner want the Developers to adhere to its Definition of Done?

  (choose the best answer)

  A. To predict the team's productivity over time.

  B. To have complete transparency into what has been done at the end of each Sprint.

  C. To know what the team will deliver over the next three Sprints.

  D. To be able to reprimand the team when they do not meet their velocity goal for the Sprint.

  Correct Answer: B

  Explanation: The Product Owner wants the Developers to adhere to its Definition of Done to have complete transparency into what has been done at the end of each Sprint. This is because:

  The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. It is a shared understanding among the Scrum Team and the stakeholders of what "Done" means for any

  Product Backlog item that is selected for a Sprint. The Developers are accountable for creating a "Done" Increment in every Sprint. They must ensure that every Product Backlog item they work on meets the Definition of Done before it is

  considered complete. The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. They must inspect the Increment at the end of each Sprint and assess how it delivers value and

  contributes to the Product Goal.

  Having a clear and consistent Definition of Done helps the Product Owner have complete transparency into what has been done at the end of each Sprint. It also helps them make informed decisions about releasing, adapting, or continuing

  the product development.

  Other options, such as predicting the team's productivity over time, knowing what the team will deliver over the next three Sprints, or reprimanding the team when they do not meet their velocity goal for the Sprint, are not valid reasons for

  wanting the Developers to adhere to its Definition of Done. They may reflect a misunderstanding of what a Definition of Done is or how Scrum works.

  References:

  [Scrum Guide], page 10, section "Definition of Done" [Scrum Guide], page 7, section "Developers"

  [Scrum Guide], page 6, section "Product Owner"

• Question 82:

  The timebox for a Daily Scrum is?

  (choose the best answer)

  A. 4 hours.

  B. The same time of day every day.

  C. Two minutes per person.

  D. 15 minutes.

  Correct Answer: D

  The Scrum Guide states that "The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours."1 The Daily Scrum is a quick and simple planning meeting designed

  to keep everyone in the loop with how other team members are getting on. It ensures that team members are fully aligned with each other and on track to hit the Sprint Goal.

  References:

  1: The Scrum Guide2, page 11

  2: The Scrum Guide

• Question 83:

  Which of the following might the Scrum Team discuss during a Sprint Retrospective?

  (choose the best answer)

  A. Methods of communication.

  B. The way the Scrum Team does Sprint Planning.

  C. Skills needed to improve the Developers ability to deliver.

  D. The Definition of Done.

  E. All of the above.

  Correct Answer: E

  

  Scrum During the Sprint Retrospective, the Scrum Team discusses how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done123. This includes methods of communication, the way the Scrum Team does Sprint Planning, skills needed to improve the Developers' ability to deliver, and the Definition of Done123.

• Question 84:

  During a Sprint, when is new work or further decomposition of work added to the Sprint Backlog?

  (choose the best answer)

  A. During the Daily Scrum after the Developers approve it.

  B. When the Scrum Master has time to enter it.

  C. When the Product Owner identifies new work.

  D. As soon as possible after it is identified.

  Correct Answer: D

  New work or further decomposition of work is added to the Sprint Backlog as soon as possible after it is identified because:

  It reflects the current state of the Sprint. The Sprint Backlog is a plan that the Developers create and update throughout the Sprint, based on their progress, learnings, and changes. By adding new work or further decomposition of work to the

  Sprint Backlog promptly, the Developers can ensure that the Sprint Backlog is transparent, accurate, and up-to-date.

  It enables the Developers to self-manage their work. The Developers are accountable for organizing and managing their own work, and they have the authority to change the Sprint Backlog as needed. By adding new work or further

  decomposition of work to the Sprint Backlog promptly, the Developers can exercise their autonomy and empowerment, and adjust their plan accordingly. It supports the achievement of the Sprint Goal. The Sprint Goal is a single objective that

  provides guidance and focus for the Developers throughout the Sprint. By adding new work or further decomposition of work to the Sprint Backlog promptly, the Developers can ensure that their work is aligned with and contributes to the

  Sprint Goal.

  References:

  Scrum Guide 2020, page 6: "Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint." Scrum Guide 2020, page 6: "The Developers are accountable for ... organizing and

  managing their work."

  Scrum Guide 2020, page 10: "The Sprint Goal is a single objective for the Sprint." Scrum Guide 2020, page 14: "The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team's

  current Definition of Done."

  Scrum Guide 2020, page 14: "The Sprint Backlog is composed of ... all of the work needed to deliver a product Increment that meets the Definition of Done." Scrum Guide 2020, page 14: "The Developers can change the content of the Sprint

  Backlog throughout the Sprint as more is learned."

• Question 85:

  True or False: An Increment must be released to customers or users at the end of each Sprint.

  A. True

  B. False

  Correct Answer: B

  An Increment is a concrete stepping stone toward the product vision. It is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be "Done", which means it meets the Definition of Done and is usable. The Scrum Team decides when and how to release an Increment to customers or users. The Product Owner is responsible for maximizing the value of the product and the work of the Developers, and may decide to release an Increment at any time during or after a Sprint. The Developers are responsible for creating a potentially releasable Increment each Sprint, and may collaborate with the Product Owner and the stakeholders to determine the best way to deliver value. Releasing an Increment to customers or users is not mandatory at the end of each Sprint. The Scrum Team may choose to release an Increment more or less frequently, depending on the product goals, market conditions, customer feedback, or technical feasibility. However, releasing an Increment regularly can provide many benefits, such as: References: Scrum Guide: https://www.scrumguides.org/scrum-guide.html Increment: https://www.scrum.org/resources/what-is-an-increment Releasing Value: https://www.scrum.org/resources/blog/releasing-value

• Question 86:

  What are two effective ways for the Scrum Team to make non-functional requirements visible?

  (choose the best two answers)

  A. Add them to the Product Backlog to ensure transparency.

  B. Run the integration and regression tests before the end of the Sprint, and capture the open work for the Sprint Backlog of the next Sprint.

  C. Add them to the Definition of Done so the work is taken care of every Sprint.

  D. Put them on a separate list on the Scrum board, available for all to see.

  Correct Answer: AC

  Non-functional requirements are the criteria that define the quality, performance, security, usability, and other aspects of a product1. They are often implicit or assumed, but they are important to make visible and explicit, as they affect the value and satisfaction of the product2. One effective way to make non-functional requirements visible is to add them to the Product Backlog, which is an ordered list of everything that is known to be needed in the product[3][3]. By adding nonfunctional requirements to the Product Backlog, the Product Owner and the Developers can prioritize, refine, and estimate them, and make them transparent to the stakeholders4. Another effective way to make non-functional requirements visible is to add them to the Definition of Done, which is a shared understanding of what it means for work to be complete, and ensures transparency of the quality of the work done5. By adding non-functional requirements to the Definition of Done, the Developers can ensure that every Product Backlog item and Increment meets the expected quality standards, and that the work is taken care of every Sprint. References:

  1: Non-functional requirement, Wikipedia, accessed on December 16, 2023

  2: Managing Products with Agility, Scrum.org, accessed on December 16, 2023 [3][3]: The Scrum Guide, November 2020, p. 6

  4: The Scrum Guide, November 2020, p. 7

  5: The Scrum Guide, November 2020, p. 13 Understanding and Applying the Scrum Framework, Scrum.org, accessed on December 16, 2023

• Question 87:

  A Product Backlog is:

  (choose the best three answers)

  A. An exhaustive list of upfront approved requirements to be implemented.

  B. Managed by the Product Owner.

  C. An inventory of things to be done for the Product.

  D. Ordered based on priority, value, dependencies, and risk.

  E. Only visible to the Product Owner and stakeholders.

  Correct Answer: BCD

  Explanation: A Product Backlog is:

  Managed by the Product Owner. The Product Owner is the sole person responsible for managing the Product Backlog, which is an emergent, ordered list of what is needed to improve the product. They must ensure that the Product Backlog

  is transparent, visible, and understood by everyone who needs to work on it.

  An inventory of things to be done for the Product. The Product Backlog contains all the features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. The Product Backlog

  items have a description, an order, an estimate, and a value. Ordered based on priority, value, dependencies, and risk. The Product Owner orders the Product Backlog items based on various factors that affect their importance and urgency

  for the product. These may include customer needs, business value, stakeholder feedback, technical dependencies, or market opportunities.

  Other options, such as an exhaustive list of upfront approved requirements to be implemented or only visible to the Product Owner and stakeholders, are not valid descriptions of a Product Backlog. They may reflect a misunderstanding of

  what a Product Backlog is or how Scrum works.

  References:

  [Scrum Guide], page 6, section "Product Owner"

  [Scrum Guide], page 11, section "Product Backlog" [Professional Scrum Product OwnerTM Training], page 7, section "Product Backlog Management"

• Question 88:

  The IT manager asks a Scrum Team for a status report describing the progress throughout the Sprint. The Scrum Team asks the Scrum Master for advice. The Scrum Master should:

  (choose the best answer)

  A. Tell the Developers to fit the report into the Sprint Backlog.

  B. Ask the Product Owner to send the manager the report.

  C. Create and deliver the report to the manager herself.

  D. Tell the Scrum Team to figure it out themselves.

  E. Talk to the IT manager and explain that progress in Scrum comes from inspecting an Increment at the Sprint Review.

  Correct Answer: E

  The Scrum Master should talk to the IT manager and explain that progress in Scrum comes from inspecting an Increment at the Sprint Review. This is because:

  The Scrum Team is self-managing and does not need to report to anyone outside the team1.

  The Sprint Review is an event where the Scrum Team and the stakeholders collaborate on the product and inspect the Increment2. The Increment is a concrete and usable outcome of the Sprint that provides a measure of progress and value

  delivery3.

  The IT manager can attend the Sprint Review as a stakeholder and provide feedback on the product and the process4.

  References:

  Scrum Guide, page 7, section "The Scrum Team"

  Scrum Guide, page 13, section "Sprint Review"

  Scrum Guide, page 10, section "Increment"

  Scrum Guide, page 14, section "Sprint Review"

• Question 89:

  True or False: A Product Owner with multiple teams working on one product should maintain separate Product Backlogs for each team.

  A. True

  B. False

  Correct Answer: B

  In Scrum, there is only one product and one Product Backlog for a given product. The Product Backlog is the single source of truth for the Scrum Team and the stakeholders. It contains all the requirements, features, functions, enhancements,

  fixes, and anything else that can deliver value to the customers and users of the product. The Product Backlog is ordered by the Product Owner based on the product vision, goals, and value.

  Having multiple Product Backlogs for one product would create confusion, duplication, inconsistency, and waste. It would also make it harder to align the Scrum Teams and the stakeholders on the same product direction and priorities.

  Therefore, a Product Owner with multiple teams working on one product should not maintain separate Product Backlogs for each team. The Product Owner is accountable for maximizing the value of the product resulting from the work of the

  Scrum Team. The Product Owner is responsible for managing and refining the Product Backlog, collaborating with the stakeholders and the Developers, and ordering the items in a way that best achieves goals and missions. The Product

  Owner represents the interests of everyone with a stake in the product and ensures that the Scrum Team works on the right things at the right time.

  In some cases, when there are multiple Scrum Teams working on one product, it may be necessary to have some form of scaling or coordination mechanism to ensure alignment and collaboration among the teams. However, this does not

  mean that there should be multiple Product Owners or Product Backlogs. Instead, there should be ways to facilitate communication, feedback, integration, and transparency among the teams and with the Product Owner. For example, some

  frameworks or practices that can help with scaling Scrum are Nexus, LeSS, SAFe, or Scrum of Scrums.

  References:

  Scrum Guide: https://www.scrumguides.org/scrum-guide.html Nexus: [1]

  LeSS: [2]

  SAFe: [3]

  Scrum of Scrums: [4]

• Question 90:

  True or False: A Product Owner should measure product value by the increase in the team's velocity.

  A. True

  B. False

  Correct Answer: B

  Explanation: A Product Owner should not measure product value by the increase in the team's velocity. This is because:

  Velocity is a measure of how much work a Scrum Team can deliver in a Sprint. It is based on the estimation of Product Backlog items that are selected for a Sprint and completed according to the Definition of Done. Velocity is not a measure

  of product value. It does not reflect how well the product meets the needs and expectations of the customers, users, and stakeholders. It does not reflect how much value or impact the product creates in terms of revenue, satisfaction, or

  social good.

  Velocity is not a goal or a target for a Scrum Team. It is a planning tool that helps them forecast their future work based on their past performance. It is not a metric that should be used to compare or judge teams or individuals. A Product

  Owner should measure product value by using indicators that are relevant, meaningful, and actionable for their product context. These may include metrics such as customer feedback, usage data, market share, return on investment, or

  social impact.

  References:

  [Scrum Guide], page 7, section "Developers"

  [Scrum Guide], page 10, section "Definition of Done" [Scrum Guide], page 15, section "Sprint Backlog" [Professional Scrum Product OwnerTM Training], page 5, section "Product Value" [Professional Scrum Product OwnerTM Training], page

  9, section "Business Strategy"