Cost for requirement change

The cost of change for a traditional software project

When changes to a product is introduced during the development stage because of new information or a new customer requirement, a domino effect of negative consequences followed.

First, the process had to go through formal change control that was intended to ensure everyone on the team, especially those handling development and QA, understood the change and that the plan
of record was kept up-to-date. This meant documentation and meetings.

Second, the effort had to be estimated and, often, the schedule recast.

Kent Beck, who developed Extreme Programming, asks a very thought-provoking question: if our cost curve were relatively flat (Figure 1.3)

• Would we behave differently? 
• Would we delay decisions until we had better information? 
• Would we over-design in anticipation of future needs or just design and build to our current requirement? 
• Would we be able to deliver more value to the market,
• Would we be able to deliver better software faster?

Figure 1.3: The cost of change during a project with a flat cost curve


Agile attempts to change the cost of change equation.





Source - Agile Excellence™ for Product Managers By Greg Cohen