There is no such thing as fixed scope
The classic rule for agile projects is that out of the three main constraints time, price and scope (often referred to as the Iron Triangle) only two can be fixed - in other words you can fix the end date and the price but leave the scope flexible, or you can fix scope and time but leave the price flexible etc.
Particularly as a vendor we are quite often asked to deliver on-time, on-budget and to-scope. Fair enough, as a client you want to know what you get, when you get it and how much you have to budget for it. I will ignore for a moment the fact that quite often less important features get de-scoped in favor of new more important features and/or modifications to already delivered functionality. This tendency is well documented and known by most people with two or more projects under their belt. How can an agile project succeed if the client asks for on-time, on-budget and to-scope?
The answer of course is that there is no such thing as fixed scope! You might have a fixed list of features in your backlog or a fixed list of requirements in your requirements document. But these features or requirements can be implemented in a number of different ways - some of which will take more effort to build than others. With frequent and rapid user feedback you will encounter a lot of little changes to your implementation - and rightfully so! After all we set out to build a solution that is aligned with the business as much as possible. But of course that means you still need to manage scope as you can’t just take on a whole lot of little things without either dropping other features (reducing scope), deferring the delivery date (time) or charging extra (costs). At the same time this also allows you to negotiate scope and open up the iron triangle by making the deliverables side flexible!
Typically the original request is to build all features to the utmost sophistication and usability. In reality however on average at least 50% of your feature list are either used less frequently or be a smaller audience than your high-priority features and therefore lend themselves to compromises should you need them. When putting price tags on features based on the sophistication level of the implementation you will discover quickly that the client will rarely go for the deluxe version.