Release Exit Criteria

This is a check list to show the release readiness.

This is similar to the phase gate in the project lifecycle.

Some people also define the "Entry Criteria" to indicate when a phase can start.

Here are some samples:

• Functional Design and Technical Design Specifications have been reviewed and signed off by stake holders.
• User Experience Review and Signed off
• Coding  Complete
• Testing Complete
• Translation (i18n)
• Documentation is ready

The coding work can be categorized as follows:

• The coding for the new key features as described in the release content.
• UI - Front End
• Back End Process
• Model / Database 
• Batch Process
• API
• Forward Porting of the bugs fixed in the prior release by the sustaining engineering team
• Platform Porting (if supporting multiple platforms) 
• Upgrade / Data Migration

During the course of the project, the work can be measured by percent complete.
Sometime the percent complete method is too subjective.  A alternate way is to break the work into smaller units and measure three status : started? work in process? completed?  and assigned, 0%, 50%, and 100%.  The total percentage can be a rolled up based on the weighted average.


Testing (coverage) are complete

Here are some of the typically testing categories:

• Installation (for new customers)
• Functional Test (For new features)
• Integration / Interops
• Regression Test (for existing, old features)
• Performance Test
• Stress Test
• Platform Certifications
• Upgrade (for existing customers)
• Security Test
• Accessibility Test

To measure the testing coverage, we can use percentage. Testing execution can be similar to the coding work. The measurement can also be done by smaller units of work.

The overall progress of the QA testing cycle can be measured by the backlog of the bugs to be fixed in the queue.  Which can be further converted # of days of the backlog based on the fixing rate.  For examples, typically 2 bugs fixed per person each day and five resource in total.  The 100 bugs can be fixed in 50 person days.  It means that we have 10 days of backlog.

The incoming rates can also be a good leading indicator.  Initially the bugs logged per day may be high.  After the testing has been done for a while, the number of bugs logged per day may be reduced.

Deferral rate is a good measurement. A exit criteria can be the deferral rate is less than 10%.  The deferral rate can be further broken down by priories (P1, P2, P3, etc).  Deferral means that the bugs found is the testing cycle is not being fixed. Deferral rate is too high means that the issues are passed to the future releases.  It also means that the list of known issues are high.



A release is more than just engineering and testing. Other than the above typical development work.  Here are some of the release exit criteria

• Export Compliance
• Security Compliance
• Third Party software license
• Product's bill of materials

We may need to consider other activities as part of the release readiness:

• Demo Env and build the demo scenarios
• Field Readiness - Sales and Marketing
• Analyst Briefing
• Press Release
• Partner training
• Support training
• Hand Over to Sustain Engineering