Creating a Release Charter

Creating a Release Charter2017-10-12T22:05:27+00:00

Create Release Charter

Context

Summary

Provide a summary of this practice.

The Release Charter sets the basic parameters for a release, ensuring agreement and alignment between stakeholders and the Agile team.

Click here for details of the Release Charter.

Purpose

What is the overall goal or intention of this practice?

Creating a Release Charter is used to define the release’s foundations and overall structure:

  • What will be delivered by the release.
  • How it will be delivered.
  • Who will deliver it.
  • Its business justification.

SLA

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

Creating a Release Charter should be carried out at the start of each release.

The Charter should also be maintained to reflect on-going changes.

Exit conditions

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

Creating a Release Charter is complete when the Release Charter has been agreed.

Entry conditions

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

Creating a Release Charter should not begin until:

  • the Product Plan has defined the basic form of the release.
  • at least a preliminary Release Backlog has been defined.

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
1Confirm readiness
  1. Confirm the release’s readiness for chartering.
2Review Product Plan
  1. Walk through the Product Plan.
  2. Review individual release.
3Identify release goals & backlog
  1. Identify release-specific goals.
  2. Identify release-specific backlog items.
  3. Identify contributors to Charter (SMEs, etc.).
4Draft Release Charter
  1. Identify stakeholders & other approvers.
  2. Identify SMEs & other reviewers.
  3. Draft Release Charter.
  4. Walk through with release team & Iteration Leads.
5Validate Release Charter
  1. Validate the draft Release Charter.
6Review Release Charter
  1. Distribute to agreed reviewers.
  2. Capture comments & recommendations.
  3. Update Release charter.
  4. Reiterate as required.
7Approve Release Charter
  1. Distribute to agreed approvers.
  2. Capture comments, approvals & rejections.
  3. Update Release Charter.
  4. Reiterate as required.
  5. Finalise Release Charter.
8Publish Release Charter
  1. Place Release Charter under formal control.
  2. Publish Release Charter to stakeholders.
  3. Display Release Charter in Agile team space.

Detailed process

#StepByOutputInstructionsNotes
1Confirm readinessProduct Owner.
  1. Confirm the release’s readiness for chartering.
Check that:

  • Iteration Leads have been identified.
  • The Product Plan is understood by the Product Owner & Iteration Leads.
  • Inputs are all up to date.
    • Product & Release Backlogs.
    • Business vision and goals.
    • Current business priorities & concerns.
  • A draft release budget & resource plan are in place.
  • Epics & stories have preliminary estimates & priorities.
2Review Product PlanProduct Owner.

Iteration Leads.

  1. Walk through the overall Product Plan.
  2. Review individual release.
  3. Review Release Backlog.
  • The backlog review should be limited to confirming which stories have been allocated to this release.
3Identify release goals & backlogProduct Owner.

Iteration Leads.

Contributor list.
  1. Identify release-specific goals.
  2. Identify release-specific backlog items.
  3. Identify contributors to Release Charter (SMEs, etc.).
  • The backlog review should be limited to familiarising the participants with the release’s scope.
  • Refinement, estimation & prioritisation will be performed during Release Planning.
4Draft Release CharterProduct Owner.

Iteration Leads.

Iteration teams.

Draft Release Charter.
  1. Identify stakeholders & other approvers.
  2. Identify SMEs & other reviewers.
  3. Draft Release Charter.
  4. Walk through with release team & Iteration Leads.
Like every Agile product, a Release Charter should contain the least that is needed to get the job done.

  • Only release-specific items should be defined.
  • Include nothing that has already been defined elsewhere.
  • Exclude anything self-evident.
  • Exclude anything irrelevant to execution.
  • Do nothing that belongs in iteration management.
5Validate Release CharterProduct Owner.
  1. Validate the draft Release Charter.
The Charter should be checked against:

  • The Product Plan’s definition of the release.
    • Where appropriate, the Product Plan itself may require adjustment.
  • Known issues with the product & release.
    • Business concerns.
    • Technical issues.
  • The complexities of real delivery:
    • Team makeup and historic velocity.
    • Dependencies on other releases.
  • Major overheads:
    • Refactoring, test maintenance, environment refreshes, etc.
  • External events & deadlines.
  • Resource availability (e.g., personal and public holidays).
6Review Release CharterProduct Owner.

Impacted stakeholders.

Appropriate SMEs.

The release team leads & members.

Review comments.
  1. Distribute to agreed reviewers.
  2. Capture comments & recommendations.
  3. Update Release charter.
  4. Reiterate as required.
  5. Create draft for approval.
7Approve Release CharterProduct Owner.

Impacted stakeholders.

Approved Release Charter.
  1. Distribute final draft to agreed approvers.
  2. Capture comments, approvals & rejections.
  3. Update Release Charter.
  4. Reiterate as required.
  5. Finalise Release Charter.
  6. Place approved Release Charter under formal control.
8Publish Release CharterProduct Owner.

Iteration Leads.

  1. Publish Release Charter to stakeholders.
  2. Distribute to senior management, PMO, etc.
  3. Display Release Charter in Agile team space.
  • Make sure that distributed teams also display the Charter.
  • Make sure that the any public display includes ‘static’ information & decisions:
    • I.e., items not included in the individual Release Charter…
    • …but which are equivalent ‘standing’ information & decisions.

Issues & risks

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

  1. A basic definition of a Release Charter can be found here.
  2. During the transition to Agile (or where parts of the organisation remain non-Agile), stakeholders may want the Release Charter to perform a similar role to Prince2’s Project Initiation Documentation (PID). That is, they may want of detail about ‘the project’, the deliverables and the delivery process, and they may expect it to be relatively fixed. This can be remedied by ensuring that they are fully briefed on Agile before the Charter is reviewed by them.
  3. To be effective (e.g., actually read by the stakeholders and the team), the Release Charter should be very brief, ideally no more than one page. Note that this makes it harder, not easier, to write & agree.
  4. The Release Charter is not a one-off document. It can be revised and updated at any time during the release.
    • However, if it is changed, the full cycle of review & approval needs to be repeated.
  5. Iteration Leads should walk their teams through the Release Charter again as part of the Iteration Planning process.
  6. Users should also be familiarised with the Release Charter as part of their induction to the Agile team.

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?