Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Defining project requirements is handled very differently on Agile projects and it is typically one of the hardest concepts for a business to embrace. Consider how most projects are initiated. First, you define the scope of the project, then you price each project line item. Lastly, you sign the contract and commit to your customer that you will execute the contract. What if you start and then discover that one of the project line items is a bad idea? Market conditions can change rapidly and that is especially true of technology projects. Locking yourself into a fixed project plan that you already know is a bad idea is a great way to waste a bunch of time and money.

Agile projects take a very different approach to requirements management. Instead of locking down the project scope, Agile projects define the initial requirements as high level objectives then progressively elaborate the objectives into more detailed requirements at the last responsible moment. This empowers Agile teams to use changing requirements and market conditions as a competitive advantage instead of a stumbling block. Requirements defined later in the project are more likely to be correct because they benefit from what you have learned about the project during the period of performance.

Practice 2.1 : Embrace Change

Instead of fighting change with a complicated change management process, Agile projects avoid the problem entirely by delaying the “lock in” of requirements until the beginning of an iteration (or the last responsible moment). This allows the Agile team to smoothly incorporate changing requirements and continuously improve the definition of the product even into the late stages of the project.

Practice 2.3 : Incorporate Feedback

Having the ability to incorporate changes smoothly empowers the Agile team to actively seek out changes that give the product an advantage. We do this by putting the product in front of customers early and often to get feedback. Agile projects use this feedback to learn about our product and the market where it will live and compete. Information learned from this feedback will guide the team when they elaborate the next objective into requirements and help ensure the product meets the customer’s needs.

For more information about the origin of the Agile Principles, see the Agile Manifesto site.