One week passes by, and less than half of the Product Backlog (requirements) is recorded. The Product Owner believes that it's best to start the…

In Scrum, the Product Backlog is a dynamic and emergent artifact; it is never considered "complete." The framework is designed to handle uncertainty and evolving requirements. A Sprint can and should begin as long as there are enough high-priority, well-understood Product Backlog Items (PBIs) to fill the Sprint's capacity. Waiting for a fully detailed backlog contradicts the agile principles of iterative development, early value delivery, and adapting to feedback. The Product Owner's decision to start is correct as it initiates the development and learning cycle promptly.

B. No, we should wait for the whole backlog to be completed before starting the Sprints: This reflects a traditional, waterfall mindset. In Scrum, the Product Backlog is intentionally incomplete and evolves throughout the project, making this approach an anti-pattern that delays value delivery.

---

1. A Guide to the Scrum Body of Knowledge (SBOK® Guide)

3rd Edition.

Section 3.3.1

Product Backlog: "The Product Backlog is a dynamic list that is continuously updated with new User Stories and requirements... It is an ever-evolving artifact that exists as long as the product exists." This confirms the backlog is never "complete."

Section 8.3.2

Create Prioritized Product Backlog: "It is important to note that the Product Backlog is never complete. It is continuously being updated by the Product Owner to include any changes in customer requirements or other business needs." This directly refutes the idea of waiting for a "whole backlog."

Section 12.3.1

Sprint Planning: "During this meeting

the Scrum Team collaborates to select some high priority items from the Prioritized Product Backlog to be completed in the upcoming Sprint." This indicates that only a selection of items is needed to start a Sprint

not the entire backlog.