Practice Free PSPO-I Exam Online Questions
Question #11
What is the timebox for the Sprint Review? (choose the best answer)
- A . 2 hours for a one-month Sprint.
- B . 1 day.
- C . 4 hours for a one-month Sprint.
- D . As long as needed.
Correct Answer: C
C
Explanation:
The timebox for the Sprint Review is four hours for a one-month Sprint.
This is because:
The Sprint Review is an event where the Scrum Team and stakeholders inspect the Increment and adapt the Product Backlog if needed. The purpose of the Sprint Review is to elicit feedback and foster collaboration.
The timebox for each Scrum event is proportional to its frequency and duration. A one-month Sprint corresponds to a maximum calendar month.
The timebox for a one-month Sprint Review is four hours. For shorter Sprints, it is usually shorter. The timebox ensures that there is enough time to inspect what has been done in relation to what could be done next and make any necessary adaptations to optimize value.
Other options, such as two hours for a one-month Sprint, one day, or as long as needed, are not valid answers as they do not reflect the correct timebox for the Sprint Review.
Reference:
[Scrum Guide], page 17, section “Sprint Review”
[Scrum Guide], page 9, section “Sprint”
[Scrum Guide], page 9, section “Timeboxing Scrum Events”
C
Explanation:
The timebox for the Sprint Review is four hours for a one-month Sprint.
This is because:
The Sprint Review is an event where the Scrum Team and stakeholders inspect the Increment and adapt the Product Backlog if needed. The purpose of the Sprint Review is to elicit feedback and foster collaboration.
The timebox for each Scrum event is proportional to its frequency and duration. A one-month Sprint corresponds to a maximum calendar month.
The timebox for a one-month Sprint Review is four hours. For shorter Sprints, it is usually shorter. The timebox ensures that there is enough time to inspect what has been done in relation to what could be done next and make any necessary adaptations to optimize value.
Other options, such as two hours for a one-month Sprint, one day, or as long as needed, are not valid answers as they do not reflect the correct timebox for the Sprint Review.
Reference:
[Scrum Guide], page 17, section “Sprint Review”
[Scrum Guide], page 9, section “Sprint”
[Scrum Guide], page 9, section “Timeboxing Scrum Events”
Question #12
Which of the following practices might help the Product Owner minimize waste in developing and sustaining the Product Backlog? (Choose the best two answers)
- A . Avoid distracting the Scrum Team by maintaining newly gathered Product Backlog items in a separate Product Backlog until they are fully understood.
- B . Remove items from the Product Backlog that have not been addressed in a longtime.
- C . Hand off ownership of the Product Backlog to someone else.
- D . Only fully describe Product Backlog items when it seems likely they will be implemented.
Correct Answer: B,D
Question #13
The length of a Sprint should be: (choose the best answer)
- A . Short enough to keep the business risk acceptable to the Product Owner.
- B . Short enough to be able to synchronize the development work with other business events.
- C . No more than one calendar month.
- D . All of the above.
Correct Answer: D
D
Explanation:
The length of a Sprint is the timebox within which the Scrum Team creates a potentially releasable product Increment. The Sprint is a container for all the other Scrum events, such as the Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective. The Sprint is also a feedback loop that allows the Scrum Team and the stakeholders to inspect and adapt the product and the process.
The length of a Sprint should be no more than one calendar month. This is the maximum duration allowed by Scrum, as longer Sprints can increase the complexity and risk of the product development. Longer Sprints can also reduce the agility and responsiveness of the Scrum Team to changing customer needs and market conditions.
The length of a Sprint should also be short enough to keep the business risk acceptable to the Product Owner. 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. The length of a Sprint affects how frequently and effectively the Product Owner can validate, verify, and deliver value to the customers and users.
The length of a Sprint should also be short enough to be able to synchronize the development work with other business events. The Scrum Team operates within a broader organizational context that may have other events, cycles, or deadlines that affect or depend on product development. For example, there may be marketing campaigns, sales promotions, regulatory compliance, or contractual obligations that require coordination and alignment with the product delivery. The length of a Sprint affects how well and timely the Scrum Team can synchronize their work with these other business events.
Reference: Scrum Guide: https://www.scrumguides.org/scrum-guide.html
Sprint: https://www.scrum.org/resources/what-is-a-sprint-in-scrum
Product Owner: https://www.scrum.org/resources/what-is-a-product-owner
D
Explanation:
The length of a Sprint is the timebox within which the Scrum Team creates a potentially releasable product Increment. The Sprint is a container for all the other Scrum events, such as the Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective. The Sprint is also a feedback loop that allows the Scrum Team and the stakeholders to inspect and adapt the product and the process.
The length of a Sprint should be no more than one calendar month. This is the maximum duration allowed by Scrum, as longer Sprints can increase the complexity and risk of the product development. Longer Sprints can also reduce the agility and responsiveness of the Scrum Team to changing customer needs and market conditions.
The length of a Sprint should also be short enough to keep the business risk acceptable to the Product Owner. 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. The length of a Sprint affects how frequently and effectively the Product Owner can validate, verify, and deliver value to the customers and users.
The length of a Sprint should also be short enough to be able to synchronize the development work with other business events. The Scrum Team operates within a broader organizational context that may have other events, cycles, or deadlines that affect or depend on product development. For example, there may be marketing campaigns, sales promotions, regulatory compliance, or contractual obligations that require coordination and alignment with the product delivery. The length of a Sprint affects how well and timely the Scrum Team can synchronize their work with these other business events.
Reference: Scrum Guide: https://www.scrumguides.org/scrum-guide.html
Sprint: https://www.scrum.org/resources/what-is-a-sprint-in-scrum
Product Owner: https://www.scrum.org/resources/what-is-a-product-owner
Question #14
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
Question #15
True or False: All planned work for the Product done by the Scrum Team must originate from the Product Backlog.
- A . TRUE
- B . FALSE
Correct Answer: A
Question #16
When is the Sprint Backlog created? (choose the best answer)
- A . Prior to Sprint Planning.
- B . During refinement.
- C . During the Sprint Retrospective.
- D . During Sprint Planning.
Correct Answer: D
D
Explanation:
The Sprint Backlog is created during Sprint Planning, where the Developers select the Product Backlog items that they can deliver in the Sprint and create a plan for how to do the work. The Scrum Guide states that "The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how)."1 The Sprint Backlog is owned and managed by the Developers, who can update it throughout the Sprint as more is learned.
Reference:
1: The Scrum Guide2, page 15
2: The Scrum Guide
D
Explanation:
The Sprint Backlog is created during Sprint Planning, where the Developers select the Product Backlog items that they can deliver in the Sprint and create a plan for how to do the work. The Scrum Guide states that "The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how)."1 The Sprint Backlog is owned and managed by the Developers, who can update it throughout the Sprint as more is learned.
Reference:
1: The Scrum Guide2, page 15
2: The Scrum Guide
Question #17
What does it mean for a Scrum Team to be cross-functional? (Choose the best answer)
- A . The Scrum Team is a virtual team drawing from separate teams of business analysts, architects, developers, and testers.
- B . The Scrum Team includes skilled individuals who together have all the skills necessary to create value each Sprint.
- C . The Scrum Team includes not only developers but also business analysts, architects, and testers.
- D . Developers on the Scrum Team work closely with business analysts, architects, developers, and testers who are not on the team.
Correct Answer: B
Question #18
If Product Backlog refinement is needed, when is the ideal time for refinement to take place and who should participate? (choose the best two answers)
- A . The Product Owner must do this as essential work in Sprint O.
- B . The Scrum Team on an ongoing basis, defining Product Backlog items into smaller more precise items that are ready for selection.
- C . The Product Owner takes the time between the end of one Sprint and the start of the next Sprint to complete refinement.
- D . Business analysts in the organization should do this work for the Scrum Team 1-2 Sprints ahead of the development Sprints.
- E . The Scrum Team during the current Sprint, if they have been unable during preceding Sprints to define Product Backlog items with enough precision to begin work.
Correct Answer: B, E
Question #19
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
AC
Explanation:
Non-functional requirements are the criteria that define the quality, performance, security, usability, and other aspects of a product 1. 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 non-functional 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.
Reference:
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
AC
Explanation:
Non-functional requirements are the criteria that define the quality, performance, security, usability, and other aspects of a product 1. 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 non-functional 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.
Reference:
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 #20
Which of the following is required by Scrum? (choose the best answer)
- A . Sprint Retrospective.
- B . Developers must stand up at the Daily Scrum.
- C . Sprint Burndown Chart.
- D . Release Planning.
- E . All of the above.
Correct Answer: A
A
Explanation:
The Sprint Retrospective is one of the five events defined by Scrum. It is a formal opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The purpose of the Sprint Retrospective is to adapt the way of working so that it becomes more effective and enjoyable. The other options are not required by Scrum, but may be useful practices depending on the context. Developers do not have to stand up at the Daily Scrum, they can choose any format that works for them. A Sprint Burndown Chart is a common way to visualize the remaining work in a Sprint, but it is not mandated by Scrum. Release Planning is a topic that falls under the broader competency of Managing Products with Agility, but it is not a prescribed event in Scrum.
Reference: The Scrum Guide
Understanding and Applying the Scrum Framework
Professional Scrum Product Owner™ I Certification
A
Explanation:
The Sprint Retrospective is one of the five events defined by Scrum. It is a formal opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The purpose of the Sprint Retrospective is to adapt the way of working so that it becomes more effective and enjoyable. The other options are not required by Scrum, but may be useful practices depending on the context. Developers do not have to stand up at the Daily Scrum, they can choose any format that works for them. A Sprint Burndown Chart is a common way to visualize the remaining work in a Sprint, but it is not mandated by Scrum. Release Planning is a topic that falls under the broader competency of Managing Products with Agility, but it is not a prescribed event in Scrum.
Reference: The Scrum Guide
Understanding and Applying the Scrum Framework
Professional Scrum Product Owner™ I Certification