How late should you allow changes in a release?

This entry is about the very end of a release. I have talked about the whole end-game in a previous posting but this period warrants more discussion. There are always more bugs to fix. Sometimes this pressure comes from engineering trying to perfect a release and sometimes from product management trying to help out one more customers or avoid a service call. Either way I suggest you avoid a lot of changes down the end of a release.

There should always be a quiet period before a release where only bugs that would stop shipment and cause an immediate patch of a production release should get fixed. Clearly the length of this period will vary with the size of release or the maturity of a company. But the period should not be less time than a full run of testing (which should be set to take 7 or less days).

In this period, any bugfix is as likely to cause more problems as fix problems. People like to minimize the impact of changes in this period but my experience does not support that position. I have seen slips due to innocuous changes.

If you have not met your bug goals or you have not completed testing do not enter this period because you will need to fix bugs that are not appropriate for this period. Do not assume you can fix a lot of bugs and keep the release stable.

So what can you do to manage this period:

• Show leadership
• Plan a patch release shortly after your release as a vehicle to handle critical non-showstopper bugs.
• Get involved in the bug reviews yourself
• Do not start new testing that has not been performed before in the cycle

Managing this period well will improve your company's and group's predictability which will in turn enhance your chances for success.

More later ...