Release charter

Release charter2017-10-12T22:05:28+00:00

Just as the Product Vision is the foundation for the product as a whole, so the Release Charter provides the foundation for the individual release.

Do you need a Release Charter?

As with any other aspect of Agile, the most basic rule is that the fastest way to do anything is not at all. So you should only have a Release Charter when it serves a clear need.

If the answer to any of the following questions is Yes, you probably need a Release Charter.

  • Will the release involve multiple teams who are not in frequent contact with one another?
  • Will the release deliver changes or updates to several products with different Product Owners (or no Product Owners at all)?
  • Are there many stakeholders with no other access to the information and decisions the Release Charter contains?

Conversely, if the answer to any of these questions is No, you probably need a Release Charter.

  • Are there reliable sources for all the information the Release Charter would normally document?
  • Are the responsibilities the Release Charter normally defines and supports clearly defined elsewhere?
  • Are there other (reliable) channels through which your wider group of stakeholders can access this information?
  • Are the processes through which the various teams involved in delivering the Release as a whole well defined and effective?

As these questions suggest, a fully mature Agile organisation doesn’t need Release Charters. However, for many less advanced organisations, the Release Charter is a valuable interim measure.

Contents of the Release Charter

Because the Release Charter is one of those products that is likely to read by a wide range of stakeholders, it is impossible to define completely:

  • An exhaustive list of contents.
  • Its structure and format.

However, what can be defined here is what the Agile release team needs to get from the Release Charter. So, regardless of how the Release Charter is structured, the basic information needs to define include:

ElementWhat this tells the team
Release identifier
  • The release’s goals and objectives.
  • The intended high-level outputs and outcomes.
  • Stakeholder success criteria or user expectations for the release.
  • There is no need to identify the individual epics, features and stories the release will implement.
  • These are already documented in the Release Backlog itself, and are likely to change as the release evolves.
Work allocation
  • Which teams are expected to deliver which parts of the release backlog.
  • If necessary, the scope of individual iterations, outline timescales, etc.
    • These are required only if detailed interaction, alignment, integration, etc. between teams or products need to be decided before:
      • The release as a whole can be approved.
      • Additional/specialised resources or Extended Team cooperation can be organised or approved.
      • Etc.
  • Responsibilities for overall integration across teams and iterations.
  • The overall release budget.
  • The release’s participants and their roles:
    • Product Owners.
    • Iteration teams and leads.
    • Users.
    • SMEs and Extended Team members.
    • Other stakeholders.
    • Other participants, as required.
  • Non-people resource needs:
    • Tools.
    • Training.
    • Etc.
  • Delivery dates.
  • Iteration start/end milestones.
  • Other key events.
Risks and constraints
  • Risks, the specific uncertainties they create, and planned mitigations.
  • Constraints.

Level of detail

  • A Release Charter should only include information and decisions that are specific to that release.
  • Information and decisions shared by several releases should be published in product-level documentation, and not repeated in individual Release Charters.
  • This shared material should be referenced by individual Release Charters.


If the release affects only a single product, then the owner of the Release Charter is the Product Owner. If a release covers several products, it is strongly recommended that it be assigned a single owner – typically the Product Owner with the most interest in the release. Assigning the Charter to a single owner means that it can only be changed with that individual’s agreement.


The Release Charter is agreed by all the participants in the release, including the iteration teams. So it should be agreed not only by the functions it benefits (e.g., the business) but also by the teams who are being asked to deliver those benefits.

Click here for the process for creating a Release Charter.

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?