Overview |  | Roles |  | Work Items |  | Views |  | CMMI |  | Index |  | Glossary |

Project Portal
| Release a Product Release Manager
|  | Participating Roles Responsible: Release Manager Tester Test Manager Product Manager User Experience Architect User Education Specialist Accountable: Release Manager Consult: Development Manager Developer Business Analyst Sponsor IPM Officer Informed: All
### Overview Working software should be release as often as possible within the bounds defined by the business, the problem domain, and the distribution channel's ability to absorb releases and realize the value they contain. There are many types of releases, such as full or main product releases and earlier life cycle versions such as alphas, betas, as well as defect patches and minor upgrades, often referred to as point releases. External release of software products requires a lot of planning and coordination. Marketing and sales collateral must be created, training for trainers, help desk personnel, operations engineers, and field service personnel must be planned and created, sales teams need to be educated, and field sales tactics developed. To prepare these folks for the upcoming release, a release plan is created. Releases are signaled at the last responsible moment; that is, a release is locked based on the market's capacity to absorb it and the project's ability to foresee its availability and its content. This requires clarity in the scope and vision coupled to maturity in the productivity and estimation. When a future release is signaled, release planning will spin up and product release activities will get under way. Once this happens, the transaction cost of aborting or delaying a release becomes expensive and resultantly the project must be totally focused on the date and delivering on its committed promise. # Entry Criteria User Acceptance Test Readiness Signal A firm commitment to a release including a tight (low variation) definition of scope, and a fixed delivery date. Build Code builds ready for evaluation as release candidates. System Test Results System test results for each build as input to evaluation for release candidate. Critical to Quality Factors The minimum set of criteria for acceptance of a release. Requirements The set of customer and product requirements committed to in the delivery promise at the time of the user acceptance test readiness signal. When: A future release is signaled during iteration planning. # Activities
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 Validation Guidelines | Establish guidelines for how validation is approached. 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.
# Exit Criteria
| 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.
| The release candidate is signed and accepted for the stabilize milestone review.
© 2005 Microsoft Corporation. All rights reserved. MSF for CMMI Process Improvement: 1.00.0000.00 |