Release a Product

Release Manager

1

Establish a User Acceptance Test Environment

• Establish a user acceptance test environment.
• In order to maintain schedules, it is necessary to have the facilities and equipment needed for user acceptance tests ready to use when the release candidate is selected. The test environment should be acquired and commissioned for use ahead of time.

2

Establish User Acceptance Test Procedures and Criteria

• Establish a set of procedures for running a user acceptance test.
• This would include procedures for developing test plans and test cases, procedures on running tests and reporting results, and procedures for accepting or rejecting a release candidate based on the reported results.

3

Select Release Candidate

• Code is being built everyday. Each build is a potential release candidate. However, most builds will not be in a suitable state for user acceptance testing.
• When the last acceptable date for starting user acceptance tests is close, evaluate builds against a set of acceptance criteria for user acceptance tests.
• Several builds generated over a recent period may be evaluated together. Some will have different levels of functionality and varying levels of quality. Select the best candidate and promote it as the release candidate for user acceptance testing.

4

Create Rollout and Deployment Plan

• Gather the requirements for rollout or deployment including training and education for sales staff, help desk associates, field service and maintenance engineers, operations engineers, and end user trainers. Create a plan for marketing collateral, marketing communications, product launch, and any trade shows or exhibitions associated with the product release.
• Analyze the requirements and create a list of tasks.
• Assign tasks to personnel.
• Define a list of other resources including facilities, equipment, and budget.
• Add rollout and deployment risks to the risk log and risk management activities.
• Monitor and manage rollout and deployment issues through the day-to-day issue management activities.

5

User Acceptance Testing

• Run user acceptance tests and report results.
• User acceptance testing is used to validate the product delivers what the sponsor, business case, vision statement and ultimate consumer need and want from a product release.
• User acceptance testing enforces the MSF principle that quality is defined by the customer. The purpose is not to validate that the release candidate conforms to the specification (customer requirements in the shape of scenarios and qualities of service) but to agree that the release candidate delivers what the market needs.
• Any variation from defined specification should be recorded and used as feedback for future product definition and planning activities.

6

Analyze User Acceptance Test Results

• Evaluate user acceptance test results against a set of acceptance criteria.
• This should include the critical to quality (CTQ) factors defined during the Envision track at the beginning of the project lifecycle.
• CTQs are sometimes called "overall goodness factors" (or OGFs).
• Based on reaching a minimum bar against the CTQs, accept a product for release.
• Otherwise reject it and request a new release candidate for another round of user acceptance tests.
• Based on the business drivers, consider canceling or rescheduling the release if quality is not acceptable.
• For example, the effectiveness of training for downstream personnel in sales, support, and maintenance, may atrophy. This may require a rescheduling of a release and another round of training. Because of the costs incurred by the business, it is always better to deliver acceptable quality the first time.

7

Accept Product for Release

• Involve all stakeholders.
• Schedule a product review and demonstration.
• Present the working product along with the summarized release evaluation results.
• Agree upon a consensus that the product is acceptable for release.
• Obtain commitments from each stakeholder agreeing to the release.

8

Package Product

• Package the product for distribution.
• It is impossible to be prescriptive about packaging. The type of packaging will vary depending on the product and the domain. It may require a physical box or it may simply be a zip file for distribution electronically. You must decide what represents the right packaging for your product.
• Release the product.

9

Execute Rollout Plan

• Assign tasks in the rollout plan and authorize personnel to act upon them.
• Monitor task resolution against the plan with Visual Studio Team System.
• Maintain a record of variance against the plan for use as future feedback and subsequent release planning activities.

10

Create Release Notes

• Document the functionality in the release. Provide guidance on installation. Provide details of any new functionality if this is an upgrade on an earlier release. Detail any bugs fixed and other quality improvements.

Change requests from exploratory testing and usability study feedback.

Problems found in user acceptance testing.

A signal that the packaged release is available.

The packaged product.