This question checks whether you have a disciplined process for controlling scope changes without becoming rigid or adversarial with stakeholders.
Key Points: • Define project scope clearly at the outset with explicit stakeholder agreement. • Require any proposed scope change to go through a formal impact assessment. • Evaluate changes against effect on time, cost, and resources before approval. • Keep the process collaborative -- scope changes aren't automatically rejected, just properly evaluated.
Example: When a stakeholder requests a new feature mid-sprint, a lead might route it through a lightweight change-request process that estimates impact on the current deadline before deciding whether to accept, defer, or trade it off against existing scope.
Interview Tip: A concise interview answer is:
"I handle scope creep by clearly defining project scope up front with all stakeholders in agreement. When changes come up during the project, I make sure they're formally assessed for impact on time, cost, and resources before they're approved, so scope only grows deliberately, not by accident."