Many projects start with a specified budget, and Agile methods are perfectly suited for them because they give us the tools to continuously adjust the scope throughout the project—as opposed to more rigid ones that rely on correct up-front, long-term, estimates and an immutable environment. And every project has a scope, the very reason for which it was started. In an ideal world, the scope would be determined by nothing but a product vision, with everything else left for the team to craft.

“Prediction is very difficult, especially about the future.” (Niels Bohr)

Most projects start with a narrower scope though. Interfacing to other systems or the users to address can lead to constraints, as can many other circumstances. Agile is based on the experience that a cross-functional team working in short iterations and evolving—through continuous inspection of results and adaptation to their environment—will build software that is more valuable to their customers than anything a process with separate phases for requirements engineering, design, implementation and testing could yield. There are many reasons for this. One has to do with the inherent difficulty of predicting the turns of a process as complex as the development of computer software. Another reason has to do with the loss of information inherent in a handover. 

For an agile team to optimise their development efforts towards a customer's needs they need freedom to negotiate and prioritise backlog items. An agile team consists of developers and customer representatives. Together they direct the project such that the product they build will, at every stage of the project, contain the functionality most relevant to its target audience that could have built in the given time frame. Repeated questioning of feature requests, re-thinking of possible solutions, and re-prioritising backlog items are the means by which this is done.

Every constraint that is posed on the project by the contract limits this freedom, thus reducing the team's ability to maximise customer value. A comprehensive requirements document will even limit it to the point where reacting to change is impossible and an agile process will cease to work. In short—the fewer the restrictions you impose on the project team, the better the product it builds will support your vision. Now the big question is: “As a customer, how do I know what I will get for my money? How can I control the outcome?”—You cannot know (and you never could). But you can control the development process and influence its outcome. And you will have to.

The customer in an Agile project actively participates in the development process. She will interact with the developers daily, answering questions, discussing possible solutions, refining ideas, prioritising backlog items. At all times there is total transparency of the project's state. Together as a team they will make sure the most valuable aspects of the product are finished first. Once the project budget is exhausted the customer will know that what they got is the best possible solution to their needs.