Can anyone shed some light on best practices of when / where/ how to establish the scope of the Release in the Agile Development Lifecycle model?
Our problem seems to be that we can never get to the point when we can nail down what the scope of the release is. When we do, it seems to be last minute and I am sure that this is not the best method for testing.
Irrespective of development methodology, the release scope should be known before the development starts, granted it can change along the way as requirements, issues and defects, and changes are added and removed. If you are saying we know this release is going to be these 5 changes, and towards the end it become 15 changes. This is indicates bad process.
Even though Agile is concerned as much about process as people, it still requires that you follow some semblance of a release plan. Remember that Agile doesn't mean cowboy developing and releasing.
I'm in agreement with Joe.
Even in an agile environment where you might break down a development/testing process into pieces or iterations/sprints you still need to have an understanding of what needs to be released. In fact knowing what has to be released is a pre-requisite for dividing up the work into smaller pieces.
We prefer to define the content in a release up front so we can communicate this to our clients who are eager to know what changes are coming. This doesnt normally lend itself well to releasing items adhoc but its still possible if a good feature branching approach is used.