Release Planning and Business Value
Is it important to think of Release Planning in the same breadth as Business Value? Our readings and discussions over the last week seem to suggest – Yes.
Generally speaking, a release can comprise of one or more sprints/ iterations.
- Can we make an assumption that a sprint really is a release?
- Can we release something every sprint? Also, is release a product release or just a demo to a client ?
Like all Agile Development practices, it seems that the idea of keeping track of sprints and releases separately has its origins in product development. However, it also seems true that all the projects can probably benefit from this not so subtle difference. Even in these days of software as a service [http://msdn2.microsoft.com/en-us/architecture/aa699384.aspx] the importance of planning a release can not be overlooked. Release planning really is just a collection of stories organized in order of priority and bunched together so that each such collection can be released [i.e. end users can start using the website]. The sprint however is just a collection of stories that the team hopes to complete within a given time period. However, even at the end of a successful sprint you might not have a product or software that you can release for use by potential users or subset of users.
This is where Release Planning comes in. The emphasis of release planning is business value. The team should not think that a sprint and building features by priority is enough to give a business value. The business value comes from getting users to use the software [or probably want to use the software]. Anything else, no matter how organized and dynamic an environment it creates, does not work from an Agile perspective.