In classical project management, you fix the scope and then calculate the budget based on it — as you describe it.
Agile development, taken seriously, turns it upside down.
It makes sense to agree on a common product vision with customers/users, stakeholders and development early. Such a vision would include users and their needs, and high level goals concerning the product.
Based on that, you could do an estimate, which is less of budget, and more of: how much is the customer/sponsor willing to invest in this vision?
You would also agree with the customers/users that they collaborate with development every sprint, and that they can change requirements later on at no additional cost (given that they are willing to deprioritize features / take them out of scope).
Of course you need customers and stakeholders who are willing to do that, and that may need some convincing. Sometimes it is not possible at all. Then, realistically, you can’t really work that way. You may still work iteratively, but you’d lose many benefits of an agile way of working.
Scrum in particular doesn’t even know the concept of a “project”. There’s also a shift in mindset that comes with that: moving from a project centric to a product centric way of development. In Scrum, development carries on until the product is taken off the market, not until some arbitrary date that you set beforehand. The release cycle is independent of that.