How do items flow between the Product Backlog, Sprint Backlog, and Increment?

WHAT THIS TESTS: This question tests whether you see Scrum artifacts as formal commitments to transparency and value delivery, not as generic project-management documents. Interviewers want to know if you understand the empirical flow from ordered ideas to a done, usable increment, and who owns each artifact.

A GOOD ANSWER COVERS: First, the Product Backlog is an emergent, ordered list of what is needed to improve the product, and the Product Owner is accountable for its content and ordering. Second, during Sprint Planning the Scrum Team selects a forecast of Product Backlog items it believes it can turn into a done Increment during the Sprint, and this selection plus the plan to deliver them becomes the Sprint Backlog, which is owned by the Developers. Third, the Increment is the sum of all Product Backlog items completed during a Sprint plus the value of all previous increments, and it must meet the Definition of Done to be usable. Fourth, flow is pull-based: the Product Owner orders, the Developers pull in what they forecast they can finish, and each item must reach done to count toward the Increment. Fifth, the Sprint Backlog is not a contract; it can be adjusted as more is learned, but the Sprint Goal remains.

COMMON WRONG ANSWERS: Calling the Sprint Backlog a task list assigned by the Product Owner is a major red flag because the Developers own it. Confusing the Increment with the latest deployment or unreleased code is wrong because the Increment is a concrete stepping stone toward the Product Goal and must be done. Saying items are pushed from the Product Owner to the team misses the collaborative forecast in Sprint Planning. Claiming the Sprint Backlog cannot change during the Sprint also signals a misunderstanding of empiricism.

LIKELY FOLLOW-UPS: How does the Definition of Done drive what can be pulled into a Sprint? What happens if the Developers discover they cannot finish all Sprint Backlog items? How do you handle a Product Owner who wants to add work mid-Sprint? Can multiple Increments be created within a single Sprint? How does the Sprint Goal constrain or guide changes to the Sprint Backlog?

ONE CONCRETE EXAMPLE: Imagine a team building a subscription platform. The Product Backlog contains ordered items: add annual billing, improve receipt emails, and refactor the payment gateway. In Sprint Planning the team selects annual billing and receipt emails, forecasting they can deliver both to done. These items move into the Sprint Backlog along with the team's plan to build, test, and integrate them. By the end of the Sprint, both features meet the Definition of Done and are integrated into the product; together with previous done work they form the latest Increment. The refactor remains in the Product Backlog for future ordering.