Small portion of requirement

Agile promotes an incremental approach, where only a small part of the overall requirements are dealt with at a time. Each of these small requirements are analyzed, designed, coded, integrated, and validated before leaving the workflow cycle.

The delivery end goal is similar for Agile and for traditional development styles: to complete development for the full set of requirements. However, the way to get there is different. In Agile it is essential to break the large set of requirements into small workable chunks. The sequence below shows how, in Agile, the small parts of completed work (darker small square) form the full set of requirements (lighter big square).

In essence, a large, complex requirement is sequenced into a series of small, simple requirements. As a result, the simpler requirements are completed incrementally, and made available for the end user. In this case, the end user (or whoever is validating the software) provides feedback based on the working software increment. This feedback is essential for two reasons. (1) Corrections and changes can be made in an early stage of the project, instead of only showing up at the end; therefore reducing the project risk. (2) The complexity of the analysis work is reduced. The team and the end user have early access to the working software increments. So, the ongoing analysis work is based on existing completed (or partially completed) work, instead of making all of the decisions for the software up front. And this pattern of working on small increments holds true for all the work including: analysis, design, coding, testing, integrating and deploying.