How do you handle a sprint where requirements keep changing?

Volatile sprints are a real working condition. The interviewer wants to see steady-state competence, not a story about heroic last-minute saves.

STAR walkthrough — sample answer:

Situation: A previous sprint I worked on was for a beta launch of a customer-facing dashboard. The product spec changed several times during the two-week sprint as we learned from internal demos and partner feedback — three significant scope changes plus a handful of smaller tweaks.

Task: Land the beta with reasonable test coverage despite the moving target.

Action: Three habits kept it manageable:

1. Tracked changes explicitly. I kept a running "scope changes this sprint" list pinned in the team channel. Each change had a timestamp, what changed, and what test impact (existing tests retired, new tests needed, areas re-tested). This made the volatility visible to PM and engineering — not as a complaint but as a record. By the end of the sprint, the list itself was useful evidence in the sprint retro.

2. Re-prioritised testing on every meaningful change. I didn't try to maintain a fully-up-to-date test plan — that's impossible during volatile work. Instead, I had a "must-test this release" core (login, save, load, the headline workflow) that didn't depend on the spec details, and a "varies-with-scope" layer that I updated when changes landed.

3. Communicated impact when changes had real cost. When a late change effectively invalidated two days of testing I'd already done, I flagged it clearly: "this change costs us about 2 days of re-test, here are options." Either we accepted that, descoped, or pushed the change to the next sprint. The conversation made the cost visible.

4. Protected a stable smoke layer. I'd built a 90-second smoke check at the start of the sprint that exercised the dashboard's bones — could it open, render the right user, persist a change. That smoke didn't care about cosmetic or feature-level changes, and it ran on every staging deploy. It caught two issues introduced by late refactors that the volatile higher-level tests missed.

Result: Beta launched on time with one minor known issue documented and accepted. The change log fed into the next sprint's planning conversation — PM agreed to a "scope freeze" two days before sprint end going forward.

What I learned: volatile requirements aren't QA's problem to absorb silently. Tracking the changes and surfacing their cost reframes the volatility as a team problem, which usually leads to less of it.

Why this works: shows operational competence (tracking, layered tests, smoke), surfaces costs to the team, and ends with a process change that reduced the volatility going forward.