In complex software development, changing requirements is part of the process. Hence, the Agile Manifesto values say "Responding to change over following a plan".

In a previous project, we were in the middle of a Sprint when our main client came in with an urgent new requirement due to a market change. It was a big deal because it meant we had to pivot quickly and adjust our current work.

First, I called an impromptu meeting with the team and the Product Owner to discuss the new priority. We used this time to understand the importance of the new requirement and how it aligned with our overall Sprint Goal and Product Goal. Next, we assessed the impact of the change on our current Sprint progress, given the available capacity and progress we have made toward the Sprint. We used MoSCoW method (Must have, Should have, Could have, Won't have) to prioritize the new requirement alongside the existing work. This helped us decide what could be pushed to the next Sprint and what needed to be done now.

In a few instances in my experience, after internal prioritization, it appeared the new requirement conflicted with the Sprint Goal and was not of the most important and could wait for the next Sprint.

Once we had a clear plan, we updated our Sprint backlog and communicated the changes to all stakeholders. I emphasized the importance of flexibility and teamwork to the team, reminding them that adapting to change is a key part of Agile.