Plan a Release

(Activity) for Tier: Release

View Training

PURPOSE

This activity provides guidance for planning a release. A release delivers an increment of value to the users. This differs from a production deployment in that a production deployment delivers components to production but may not necessarily release those features to the end user. A release is composed of one to many Sprints. Teams that release each Sprint may merge the two activities. The release plan constitutes an agreement between the project team and the customer wherein the project team, working collaboratively and transparently with the customer, ensures the objectives outlined in the release plan are met. This does not constitute a commitment for a specific scope as a defined schedule. Once planned, the team monitors the release and provides feedback to the overall project plan.

There are two primary types of release iterations which are addressed within the Estimate Release sub-activity. Scope based releases where the end of the release is determined by completing a defined scope or set of objectives. These types of releases are still often constrained by time in order to deliver frequent value and collect feedback. Small releases are the best practice. The second type of release is a time-boxed release where the team delivers whatever scope is complete on a set, habitual, and recurring schedule.

WHEN

  • Continuously and before the start of a new release

ENTRY CRITERIA

  • The Project Plan has updated and reviewed by the team
  • Features are prioritized within the Product Backlog

SUB-ACTIVITIES

  1. Draft Release Objectives

    • Analyze the project plan to determine if the forecasted objectives are still relevant. These objectives typically represent the highest value features to the users, customer, and/or project health. They may also represent reduction in major project bottlenecks, realization of major milestones, or even a limited release of features in order to conduct user experience or system health research.
    • Consider technical objectives that improve security, reduce the risk of obsolescence, or address technical debt impacting maintainability. Use projet metrics and development feedback to gain insights in these areas. Projects should ensure long term positive trends in these areas.
    • Document the objectives within the release plan.

  2. Assess Knowledge, Skills, and Architecture

    • Analyze the proposed objectives against the solution architecture to find any gaps. Plan early spikes to reduce the risk of unplanned technical debt. Document these within Azure DevOps.
    • Work with the architect to identify and assess any architectural concerns including security, obsolescence, and technical debt.
    • Assess the team’s knowledge and skills to ensure they’re ready to perform the work.
    • Develop risks and mitigation plans for required objectives that correlate to significant gaps exist in knowledge, skill, or architecture. Consider retrospection to improve readiness for future releases. For example, the team may need to perform this assessment earlier to allow more mitigation time. Assign the risks to the release iteration.
    • Consider deferring objectives that aren’t required where more time is needed to develop knowledge, skills, and architecture.

  3. Estimate the Release

    • Estimation for a release depends on the type of release iteration (scope vs time-box).
    • Estimate each Feature objective using the average cycle/lead time. This estimate may require adjustment for variations such as number or size of user stories or bugs. These stories may be forecasted and not written yet. Document this estimate in terms of number of Sprints within the Effort field of the Feature.
    • Estimate the release iteration duration by comparing the Feature efforts to the available resources.
    • Consider critical dependencies and bottlenecks to any objectives in the release and adjust the plan to accommodate or defer.
    • Assess any risks to adjust the estimate.
    • Determine the number of sprints necessary to meet all release objectives. Consider the team’s ability to develop multiple features concurrently and the extra coordination cost.

    Note

    Many teams are focusing on user stories that update multiple features. Release objectives only outline the most important goals. The team may add additional work based on the product backlog ranking during Sprint Planning.

  4. Schedule the Release

    • Verify that the Deployment Plan supports the release plan or vice versa. Resolve any conflicts between the deployment and release plans.

    Note

    A release may depend on one or more deployments. (Future: plan deployment)

    • For scope-based releases (adjust duration)

      • Determine the number of sprints to achieve the objectives.

    • For time-based release (adjust scope)

      • Add/remove objectives from the release to fit within the team’s time-box (number of sprints).

    • Create the sprints under the appropriate release iteration path in Azure DevOps.

    • Schedule critical dependencies such as system of system events and external interface changes.

    • Document the objectives selected, critical dependencies, and duration of the release within the Azure DevOps.

    Note

    Teams may want to consider tags for identifying critical dependencies on Features, User Stories, or other work items.

  5. Review the Release Plan

    • Confirm with stakeholders that the release plan is relevant and achievable.
    • Review with stakeholders any risks and risk management strategies that affect them or may require action on their part.
    • Respond and adjust the plan based on the feedback.

Exit Criteria

  • The Release Plan has been developed and reviewed.
  • The release plan and the deployment plan support each other.

Next Activity

Process Guidance Version: 10.4