Release planning

Release planning2017-10-12T22:05:27+00:00

Release Planning Workflow

 

Context

Summary

Provide a summary of this practice.

Release Planning defines the overall structure of the release as a whole, including goals, iterations and stories.

For general principles of Agile planning, click here.

Purpose

What is the overall goal or intention of this practice?

Release Planning is used:

  1. to set the goals and scope for a complete release.
  2. to identify the epics, features and themes to be addressed by the release.
  3. to translate the epics, features and themes into stories.
  4. to evaluate (at a high level) the stories the team expects to complete in the release.
  5. to decide the overall schedule of release iterations.
  6. to express the team’s commitment to completing the release.

SLA

What are the schedule, cost, quality, frequency, performance or other expectations for completing this practice?

Frequency: 1 per release.

Release Planning should not generally take more than 4-8 hours.

Exit conditions

What must have happened or been delivered for this practice to be considered complete?

  1. A committed Release Plan is in place.
  2. The release goals have been agreed between the Product Owner and the team.
  3. All items to be delivered in this release have been agreed between the team and the Product Owner.
  4. The Release Backlog is fully up to date.
  5. The release iterations have been identified and scheduled.
  6. It is clear what preparations need to be made in Iteration 0.

Entry conditions

What pre-conditions must be met before this practice is used?

  • A Product Backlog of prioritized features and high-level stories is available.
  • A Product Plan identifying a provisional program of releases is in place.
  • All items (epics, themes, features, defects, change requests, etc,) that are intended for the release have already been translated into Agile stories.

Outline process

This view shows a simplified version of this process. For full details, explanation and advice, click on the ‘Detailed process’ tab. For background such as entry and exit conditions, click on the ‘Context’ tab.

#StepInstructions
1Prepare planning meeting.
  1. Ensure that all preparations and inputs are ready.
    • Business vision and goals.
    • Product Plan.
    • Product Backlog.
    • Feedback from business stakeholders on:
      • previous releases.
      • business priorities and concerns.
    • Release budget and resources.
    • Release organisation and teams.
    • Release epics, features and themes.
    • Candidate release stories.
    • Preliminary story estimates.
  2. Schedule the meeting.
  3. Package meeting inputs.
  4. Identify additional participants.
  5. Prepare and circulate meeting agenda.
2Initiate planning meeting.
  1. Open meeting.
  2. Explain the meeting’s purpose.
  3. Outline the expected outputs and exit conditions.
  4. Agree agenda, meeting schedule, etc.
3Agree release goals.
  1. Product Owner explains the release as a whole.
    • Business drivers.
    • Vision, objectives, targets and priorities.
    • Current business roadmap.
    • Epics, themes and features.
  2. For each feature and epic, the Product Owner explains its:
    • Purpose.
    • Intended benefits.
    • Impacted stakeholders/business units.
    • Scope.
    • Priority.
    • Provisional estimate.
  3. The participants agree release outcomes and targets.
4Validate release stories.
  1. The participants review each release story:
    • Is it clear?
    • Is the estimate plausible?
    • Is it correctly prioritised?
    • Which systems/data/processes are likely to be impacted?
    • Are there any special technical issues or dependencies?
    • Are there any special delivery issues or dependencies?
    • Are any trade-offs needed?
  2. Where appropriate:
    • Estimates and priorities are updated.
    • Issues and risks are recorded for future action.
    • The Release Backlog is updated.
  3. The participants confirm the Release Backlog.
 5Map release iterations.
  1. The Product Owner walks through the scope of the release against its expected duration.
    • If the final release date is not fixed, the Iteration Leads estimate the number of iterations required to complete the stories, based on:
      • The story estimates.
      • Their teams previous velocity (if they are an established team).
    • If the final release date is fixed, the Iteration Leads use the same data to calculate how many of the prioritised stories can be completed in the time available.
  2. The Iteration Leads allocate stories to iterations.
    • Unless there is some other basis for prioritising stories, they should be assigned to iterations in order of their business value.
  3. The Iteration Leads review the estimated effort for each iteration.
6Detail initial iterations.
  1. Define the first 3-4 iterations of the release in further detail. In particular:
    • Increase the precision of story estimates.
    • Identify, map and evaluate dependencies.
    • Identify specific contingencies related to individual stories.
    • Estimate tolerances for iterations.
7Validate Release Plan.
  1. Validate the overall Release Plan.
  2. Publish and communicate the Release Plan to relevant stakeholders.

Detailed process

#StepLed byInvolvingOutputInstructionsNotes
1Prepare planning meeting.Product Owner.Iteration Leads.

SMEs.

Meeting schedule.

Agenda.

Meeting inputs.

  1. Ensure that all preparations and inputs are ready.
    • Business vision and goals.
    • Product Plan.
    • Product Backlog.
    • Feedback from business stakeholders on:
      • previous releases.
      • business priorities and concerns.
    • Release budget and resources.
    • Release organisation and teams.
    • Release epics, features and themes.
    • Candidate release stories.
    • Preliminary story estimates.
  2. Schedule the meeting.
  3. Package meeting inputs.
  4. Identify additional participants.
  5. Prepare and circulate meeting agenda.
  • Individual organisations may have additional requirements, such as formal release approvals.
  • Release planning meetings should always include the Product Owner and at least the Iteration Leads and, wherever possible, the team members.
  • Additional meeting participants may include:
    • Impacted business stakeholders.
    • Programme and PMO representatives.
    • Independent tester(s).
    • Training and other user support specialists.
  • Other participants should be invited only where they are relevant SMEs or direct stakeholders in the release and can provide active feedback or clarification on its potential outcomes.
2Initiate planning meeting.Product Owner.Iteration Leads.
  1. Open meeting.
  2. Explain the meeting’s purpose.
  3. Outline the expected outputs and exit conditions.
  4. Agree agenda, meeting schedule, etc.
3Agree release goals.Product Owner.Iteration Leads.Agreed release goals.
  1. Product Owner explains the release as a whole.
    • Business drivers.
    • Vision, objectives, targets and priorities.
    • Current business roadmap.
    • Epics, themes and features.
  2. For each feature and epic, the Product Owner explains its:
    • Purpose.
    • Intended benefits.
    • Impacted stakeholders/business units.
    • Scope.
    • Priority.
    • Provisional estimate.
  3. The participants agree release outcomes and targets.
  • If Product Backlog work items are excluded from the release on the grounds of low business priority but are, in the team’s view, important for overall delivery of the release, the team may wish to challenge the Release Backlog.
  • This should be negotiated with the Product Owner.
4Validate release stories.Iteration LeadsProduct Owner.
  1. The participants review each release story:
    • Is it clear?
    • Is the estimate plausible?
    • Is it correctly prioritised?
    • Which systems/data/processes are likely to be impacted?
    • Are there any special technical issues or dependencies?
    • Are there any special delivery issues or dependencies?
    • Are any trade-offs needed?
  2. Where appropriate:
    • Estimates and priorities are updated.
    • Issues and risks are recorded for future action.
    • The Release Backlog is updated.
  3. The participants confirm the Release Backlog.
  • Stories need to be analysed and estimated only in enough detail to decided their relative priority. Exact numbers are neither required nor realistic.
  • ‘Special technical issues’ might include:
    • Unfamiliar systems/environments.
    • Unfamiliar development tools.
    • Use of obsolescent technology.
  • Typical ‘special delivery issues’ might be:
    • Conflict between assigned story priorities & the optimal development sequence.
    • Dependencies with a non-Agile team.
  • Once the review is complete, the Product Owner may wish to modify the Release Backlog.
    • E.g., because the team predict that items will be cheaper or more risky than the Product Owner originally expected.
 5Map release iterations.Product Owner.Iteration Leads.Draft Release Plan.
  1. The Product Owner walks through the scope of the release against its expected duration.
    • If the final release date is not fixed, the Iteration Leads estimate the number of iterations required to complete the stories, based on:
      • The story estimates.
      • Their teams previous velocity (if they are an established team).
    • If the final release date is fixed, the Iteration Leads use the same data to calculate how many of the prioritised stories can be completed in the time available.
  2. The Iteration Leads allocate stories to iterations.
    • Unless there is some other basis for prioritising stories, they should be assigned to iterations in order of their business value.
  3. The Iteration Leads review the estimated effort for each iteration.
  • If a story is difficult to evaluate and can’t be dealt with by creating a Spike during Iteration 0, it should be returned to the backlog until the Product Owner has redefined it.
  • The teams’ rhythm and productivity will benefit if all iterations are of similar length.
  • Estimates should be checked against the iteration teams’ historic velocities:
    • Is this story too much to deliver in the time available?
    • Could the teams do more?
  • Larger releases may, where absolutely necessary, include at least one final ‘hardening’ iteration.
6Detail initial iterations.Product Owner.Iteration Leads.Preliminary iteration plans.
  1. Define the first 3-4 iterations of the release in further detail. In particular:
    • Increase the precision of story estimates.
    • Identify, map and evaluate dependencies.
    • Identify specific contingencies related to individual stories.
    • Estimate tolerances for iterations.
  • This task is carried out to allow the team to look ahead effectively and anticipate potentially issues.
  • This is not a substitute for full Iteration Planning. However, enough should be agreed to allow the teams to prepare fully during Iteration 0.
7Validate Release Plan.Product Owner.Iteration Leads.Finalised Release Plan.
  1. Validate the overall Release Plan.
  2. Publish and communicate the Release Plan to relevant stakeholders.
If the release duration is fixed and not all expected features/stories have been included, the Product Owner should validate the items the teams plan to complete.

Validate the plan:

  • Does it cover the Product Owner’s original priorities and goals?
  • Does it reflect known issues with the release.
  • Will the release features and epics be completed?
  • Are the stories associated with individual features, epics and themes efficiently grouped?
  • Are key dependencies identified?
  • Are external events and deadlines allowed for?
  • Does the plan take into account:
    • Major implementation overheads (refactoring, test maintenance, environment refreshes, etc.).
    • Predictable downtime (e.g., public holidays, personal leave, company events).

Issues & risks

What are the key concerns in making a success of this practice?

  1. The term ‘Release Planning’ should not be understood to mean that release will only happen at the end of the plan.
    • Releases may actually take place at many points in the plan and may occur at many levels (e.g., external customers, to a staging area, etc.).
    • In this context, ‘release’ is a more of an operational or business unit of activity, to which the release team may respond in a variety of ways.
  2. Release planning is not a one-off event.
    • As the release unfolds, more information is uncovered, the system is better understood, the release will almost certainly change.
    • These changes will often demand at least some replanning.
    • The Refine Backlog practice usually takes place at least once during each iteration, and will often impact the Release Plan.
  3. Even while a release is in progress, business needs evolve, opportunities emerge, priorities change.
    • So release stakeholders are entitled to revise goals, features and stories and their priorities at any point.
    • However, it’s also their responsibility to tell the team about changes in good time.
  4. Release planning does not take precedence over Iteration Planning.
    • The Iteration Plan is closer to real delivery, and should take priority.
    • The resulting changes may require management with release stakeholders.
  5. If the team does not have an established velocity, the estimates for the first few iterations are unlikely to be accurate.
  6. Ideally you should be able to offer ‘confidence limits’ on how many story points you will be able to deliver in the release as a whole, and even individual iterations.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?