@Joe "We are an "Agile" shop, so I get that we are supposed to adjust and what not, but sometime the change is large and nothing trivial. "
If your process doesn't allow you to control the rate of change in requirements, your process is not agile, but haphazard. Agile does not mean "taking anything that comes my way."
To control requirement change/creep you can adopt - in your process - the notion that a requirement does not change (a notion that it's at the heart of Scrum.) Treat a requirement change as replacing an old requirement with a new one. You have to have a backlog of requirements, and you have to have the user choose which ones he/she wants to have implemented.
You wanted X and Y in two weeks, but all of the sudden you want Z. Well, then I can deliver you all three in 4 weeks. Or I can give a pair (X and Z) or (X and Y) or (Y and Z) in two weeks and deliver the remaining one later. Choose.
This is how you negotiate with customers. This is how you communicate the cost of requirement change. If your group does not have that power, you are not in an agile shop, and there is nothing that you can do about it. It sucks, but it's true.
In case where you can negotiate, you have to track (with precision) the time it takes to implement requirements and requirement changes. That is, you have to collect this data from past and present projects.
You collect the original time estimate and the actual completion time (in addition to resources like developer count) per request (or module affected by N requests). Better yet, estimate the size of the request/request change (in terms of lines of code or function points in past projects and requests.)
Say you have a metric that you can talk to the user with. You know that a new request will take, say, 1K lines of code, or 10 web pages with an average of 5 input fields each (50 function points).
Then by looking at historical data specific to your past projects (some by lines of codes, some by web pages, some by actual function points), and you can estimate how each of these cost in terms of absolute completion time. For those with sufficient data, you can also identify those requirements that track an actual developer head count.
Then you use that and you tell your customer that based on historical data; you argue that project failures tend to follow a exponential distribution follow; and then you are armed with the following argument for your customer:
Based on data from our past and present projects and available
resources, the requirement you are asking will take
X amount of time to complete with a 25% probability of failure (or
75% of success)
1.5 * X amount of time to complete with a 5% of failure (or 95% of success)
0.5 * X amount of time to complete with a 95% of failure (or 5% of success)
The probability of failure as a function of amount of time resources typically go 95%, 25% and 5% (resembling an exponential distro.) You convey the message that a certain baseline amount gives a somewhat decent chance of success (but with real risks). 1.5 of that might give almost a certain chance of success with minimal risk, but than much less than that (0.5 of the original guarantees almost certain failure.)
You let them digest on that. If they still go for the risky proposition (done yesterday!) at least you have in writing that you told them so. If there is hope for your group of not just being agile but engineering-like, then, the customer might put serious consideration into your numbers and schedule this and future requests accordingly.
It is your job as an engineer to explain in engineer, verifiable and clear terms that request changes are not a free meal.