The essence of agile is unfixed scope -- tactically -- with a fixed scope framework strategically.Thus, by example, if we enter into a project to build a software shopping cart, a functional cart is the strategic objective of the project.
- There is a general framework of functionality for such a cart agreed to in the business plan and the project charter, but
- Many of the detailed feature/function/performance artifacts and objects will "emerge" as conversations go forward during the course of the project;
- In other words, feedback of early deliverables will influence later deliverables.
In that sense, agile is a recursive methodology in that results are applied to the process of creating results. Thus the backlog somewhat begets the backlog -- a classic case of recursion.
Consequently, the agile backlog is constantly changing, at least in theory. In practice, a lot less so.
And, second: agile dismisses the idea of structured requirements (shalls and wills) so as to substitute "conversations", put down as vignettes in the form of stories and use cases.
This obviously causes some creative thinking re verification and validation (V&V) that is often part of a downstream activity, quite apart from development.
And, third: agile is realistic vis a vis a project of intangibles wherein there are really no physical limitations to constrain requirements.
Thus: back to the challenge discussion: When is agile project "done"?
My counsel is: agile is a best value delivery, within constrained budget and time, of the highest priorities that the money will afford. All else, see V2.0.
Now, if you are working agile through the vehicle of a contract, you can also read this posting: www.johngoodpasture.com/2012/11/conversation-through-contracts.html
