Why the Sprint is a 'container' for empiricism

WHAT THIS TESTS: Whether you understand that empiricism (transparency, inspection, adaptation) needs a fixed rhythm to work, and that the Sprint is that rhythm. The interviewer wants to hear that the timebox is a feature, not a constraint to be apologized for.

A GOOD ANSWER COVERS: First, the fixed length creates a predictable cadence: because every Sprint is the same length, the inspection points (Sprint Review, Retrospective) arrive at known intervals, so the team gets regular, comparable feedback. Second, the Sprint Goal acts as a commitment that holds for the whole Sprint; once Developers forecast the work, the scope is theirs to manage and cannot be expanded from outside mid-Sprint. Third, that protection from shifting goals is what removes context switching: Developers can go deep on one coherent objective instead of being re-prioritized daily.

COMMON WRONG ANSWERS: Saying the Sprint is just a deadline that forces output. Saying the Product Owner can swap items in and out freely during the Sprint. Confusing 'no scope change' with 'no learning' the team still adapts the plan daily, it just protects the Goal.

LIKELY FOLLOW-UPS: What happens if the Sprint Goal becomes obsolete? (The Product Owner can cancel the Sprint.) Can the scope be renegotiated? (Yes, between PO and Developers, as long as the Goal is intact.) Why not just use a continuous flow like Kanban? (Scrum chooses a cadence to force regular inspection.)

ONE CONCRETE EXAMPLE: A team commits to a two-week Sprint with the Goal 'checkout works end-to-end.' Mid-Sprint a stakeholder asks to add gift cards. Because the Goal is fixed, that request goes to the Product Backlog for the next Sprint rather than derailing the current one and the team still ships a coherent checkout flow on time.