Working with Milestones

if you use a release template to create a major release, automatically defines milestones you can also create custom milestones from the quick actions menu, from the milestones tab, or from the schedule tab using the gantt chart best practice for release milestones we recommend the following best practice when using milestones include risk assessment as an activity in the planning milestone of a major release and document the result of the activity as an attachment to the release include the confirmed availability of the required configuration item for the release as an activity within the planning milestone include financial planning to ensure that the cost of the project is justified and approved as an activity in the planning milestone include documentation of the financial analysis and approval process as an attachment include the updates for the cmdb with the post release configuration item detail as an activity within the release review and closure milestone milestones created by templates release template milestones created major master location based release and deployment planning build and test release service testing and pilot release review and closure major master feature based release and deployment planning release review and closure major phase feature based build and test release service testing and pilot deployment preparation deployment early life support major phase location based deployment preparation deployment early life support major standalone build and test release deployment deployment preparation early life support release and deployment planning release review and closure service testing and pilot milestone rules by default, milestones are not created automatically for minor and emergency releases you may decide as a rule not to create milestones for emergency releases because they are usually recorded after the fact if the release type is minor, you may decide to create some of the milestones release and deployment activities should be planned in stages as details of the deployment might not be known in detail initially you have the option of creating milestones and adding information to a milestone record at any time in the release cycle however, it is best to identify them in advance, even if you do not have all the information good planning and management are essential to deploy a release, across distributed environments and locations, into production successfully milestones that are created as a result of selecting or applying a major release template have an associated workflow that triggers the first milestone in the sequence when the release status is set to active, and the milestone status is set to active as each milestone in the sequence is approved and set to completed, the next milestone in the sequence is initiated when a milestone is created for a release using the milestone templates, and both the release status and milestone status are set to active, tasks and checklists are automatically created for the first milestone in the sequence add more information to each task record and identify a team and owner to work on each task see working with tasks docid\ e40f2roctrskvptf1awpc for more information about creating, working with, assigning, and canceling tasks, as well as task escalations by default, tasks are created for the it, application development, and qa teams when each task defined in the milestone is set to complete by the appropriate task owner, an approval notification is sent to the users defined in the release review board when the milestone is approved, its status is updated to completed you can then go to the next milestone in the sequence and update its status to active tasks and checklists for the next milestone in the sequence appear and notification is sent to the appropriate task owner teams when those tasks are completed, again the approval notifications are generated when the milestone is approved, its status is updated to completed after all the milestones defined for the release have completed status, the release status is updated to closed checklists are also created for each milestone record you can add attachments to build and test plans that are referenced in the checklist and any other documentation that is needed for the milestone add other activities, such as notes or emails, to the activity history tab of the milestone record the cost of a milestone is calculated when all the tasks associated with the milestone are completed the cost of a task associated with a milestone is calculated by multiplying the average cost of the actual effort by the average cost of the owner team assigned to the task the cost of all the tasks associated with the milestone are rolled into the total cost of the milestone when the milestone is completed upon completion of the tasks, the sum of the actual time spent on all the associated tasks in the milestone is also rolled up into the milestone record and shown in the time field if you create a new milestone, there is no workflow associated with it you need to add tasks to it and assign the tasks to appropriate owners milestone workflows the milestone workflows described here reference the default application you can work with your administrator to create or modify the workflows to meet your business and organizational needs milestone workflows are defined for five combinations of the major release the first specified milestone workflow in the sequence is invoked when the milestone status is updated to active when the final milestone for the release is approved and the status is updated to completed, the release status is updated to closed milestones are defined when you create a major release using a release template the milestone workflow starts when both the status of the release and the status of the milestone are updated to active when the milestone status is updated to active, checklist records and tasks are created for the milestone record notifications are sent to the appropriate teams to work on the tasks when a task is completed, the qa team is notified finally, when the qa team sets the task status to complete, the users identified in the are notified to approve the milestone the application development team (appdevemailaddress), the it team (itemail address), and the qa team (qaemailaddress) are generic teams with corresponding email addresses that are set up in global constants in the configuration console your administrator can add or modify these groups and email addresses associated with the groups when the approves the milestone, the status of the milestone is set to complete associated tasks and checklists for the next milestone in the sequence are created when the status of the preceding milestone is set to complete after each milestone defined for the release is approved and the status is updated to complete, the release status is updated to closed the build and test release milestone workflow is an example the workflow shown is by default you might be using a workflow customized by your administrator build and test release milestone workflow