Wednesday, October 1, 2008

How do I decide optimum release size?

So, my project sponsor wants to do a production release every month. He feels that we are not agile enough as we are doing releases only once in 3 months. Our team size is 100+.

His core reason is : He needs to give the functionality to his customer with shortest lead time possible. Also, he likes to keep giving functionality to his customer one by one rather than in one go.


If we make release duration too short, it will not allow us to complete some features scheduled in the release. This is an extra overhead for the release when a feature is not production ready, as dev team needs to switch off that functionality and QAs needs to ensure that all workflows works fine after switching off the half baked feature.

So, what are the factors that i should consider before deciding on a release size?

3 comments:

ShareKhan said...

I think that the factors you should consider are:
1. Overhead involved in making a release: regression time, UAT time, planning time. Quantify and convert all these to dollar amounts and make the cost of the release apparent to all.
2. Try and quantify the dollar value of making more frequent releases.
3. Ask the project sponsor to weight one against the other and then try and arrive at the optimum schedule for the releases.

Sagar said...

I think the release size should also be decided based on how long it would take for an average feature (or a part of a feature that can be used effectively) to be built.

In some cases the feature may be big and might have to still be split into different parts, but the release size should still allow for a reasonable amount of time to build the feature.

Laura said...

I agree with the previous comments, you need to quantify the cost of a product release very clearly for your sponsor and present some options (with costs) for rejigging your release planning process. It could be that the benefits outweigh the costs, but you won't know unless your sponsor has the opportunity to evaluate it.

Laura
http://www.bridging-the-gap.com