n 1981, Barry Boehm published information on the cost of change in software at various stages of the development cycle. The following chart shows this cost curve:
image 
Boehm's Cost of Change Curve – 1981

This model has historically led the industry to believe that the most important thing we can do is “get the requirements right!”.  The thing is, the model above is somewhat incorrect. It assumes a traditional software development lifecycle is the only way software is built and that working software can only be used at the end of a project.  With the rise of agile development techniques this is no longer true and we can deliver usable software every week or two.

Also, from the chart, consider that bottom axis – time. Time here represents the length of the feedback cycle; i.e. how long it takes to realise a problem exists and that a change is needed. Time is the critical element in determining the cost of any change. The longer we go before realising we need a change, the higher the cost of that change.
In an agile approach, the short iterations of a few weeks or less result in a much shorter feedback cycle.

Scott Ambler published the following chart on the cost of change in relation to defect correction and the point in the development cycle where that defect is detected.  Again, the longer the feedback cycle the higher the cost of rectifying the problem.

image
Image via Scott Ambler - http://www.ambysoft.com/essays/whyAgileWorksFeedback.html

So by using Scrum and putting in place good engineering practices alongside a short feedback cycle we establish a number of mechanisms that help us rapidly detect mistakes in both requirements and their implementation. This in turn allows us to take corrective action and fix the problem while it is still cost effective for us to do so.

In the end, this helps us keep our application quality high and provides better value to our end users and customers.