<!--  LLM INSTRUCTIONS: Fill in the [ Add details... ] placeholders based on project context.

The release plan is similar to a roadmap. It functions as a high-level schedule that indicates which release each requirement or user story will be assigned to. The elements in a particular release can be updated based on the relative priority of the requirements in the backlog and the availability of resources needed to work on the specific requirements.

The release plan can be further elaborated into sprints. Each release may have multiple sprints. Once a sprint starts, the requirements or user stories in the sprint cannot be changed.

A high-level release plan may be developed after the product vision and backlog are started; however, it will remain somewhat dynamic throughout the project as priorities shift and new requirements are identified. The sequence and priorities of requirements or user stories may be updated after each sprint to reflect changing needs based on performance feedback or customer needs.

Alignment: the release plan should be aligned and consistent with the following documents: Product vision, Roadmap, Product backlog.

Writing guidance:

*   This is a forecast, not a commitment, until a sprint starts. Write it so a reader can tell the two apart, because a plan that reads as fixed when it is not will be used to make promises.

*   Reference each user story by its backlog identifier rather than restating it, so the plan and the backlog cannot drift apart.

*   Give each release a goal in one sentence. A release without a goal becomes whatever happened to fit.

*   Review the plan after every sprint and move what has not started. A plan that is never re-sequenced is a plan written once and never true.

*   Record resource constraints where they bite. An item that keeps sliding because one person is unavailable is telling you something the schedule alone does not show.

Tailoring Notes:

*   As information in the release plan gets more concrete you may want to assign requirements or user stories to specific sprints in the release.

*   You can arrange the release plan in swim lanes, with each lane assigned to a specific team or work stream.

*   If you show the release plan with a timeline you can show the relationships between various user stories or features. This blends the information about the content of each release with the schedule information.

Column guidance, by column:
- **Release:** The release identifier and name, for example R1 or Release 1. A release is the unit the customer receives, not an internal milestone, so name it the way the customer would recognise it.
- **Start Date:** When the release starts. For a high-level plan a month or a quarter is honest; a day-level date implies a precision the plan does not have.
- **End Date:** When the release finishes. Give the duration as well as the end date, since the two together are what show whether the release is gaining or losing ground.
- **User Stories:** The requirements or user stories from the backlog assigned to this release, referenced by their backlog identifier rather than restated, so the plan and the backlog cannot drift apart.
- **Release Goal:** What this release is for, in one sentence. A release without a goal turns into a list of everything that happened to fit, which is how releases acquire unrelated work.
- **Status:** Not started, in progress, or released. This is the column that makes the plan honest: once a sprint has started its contents cannot change, so anything still marked in progress is committed, and anything not started can still move.
- **Sprint:** The sprint identifier and the release it belongs to, so the plan can be read per release rather than as one long list.
- **Dates:** When the sprint starts and ends. A sprint with no dates cannot be told apart from one that is still open to negotiation, and once it has started its contents are fixed.
- **Sprint Goal:** What this sprint is for, in one sentence. Several sprints toward one release goal is the normal case; a sprint goal that contradicts the release goal is a sign the release is carrying two unrelated pieces of work.
- **Sprint User Stories:** The user stories committed to this sprint, by backlog identifier. Once the sprint has started this list is what was committed, and a change to it is a change to the commitment rather than to the plan.
- **Sprint Status:** Not started, in progress, or complete.
-->

<h3 dir="ltr" align="right">{{Company_Name}}</h3>
<h2 dir="ltr" align="right">{{Project_Name}} - {{Project_ID}}</h2>
<h1 dir="ltr" align="center">RELEASE PLAN</h1>

| **Date Prepared:** {{Current_Date}} | **Project Manager:** {{Project_Manager_Name}} | **Prepared By:** {{Prepared_By}} |
| :--- | :--- | :--- |  

---

## 1. Releases
<!-- One row per release. The release is the unit the customer receives, so name it the way the customer would recognise it. Reference the user stories by their backlog identifier rather than restating them. Until a sprint starts this table is a forecast, and a reader must be able to tell a forecast from a commitment. -->

| Release | Start Date | End Date | User Stories | Release Goal | Status |
| :---: | :---: | :---: | :--- | :--- | :---: |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 2. Sprint Breakdown
<!-- One block per sprint. A release may have several sprints, and a sprint's contents are fixed once it starts, so a plan that shows a sprint without a date does not tell the reader whether it is already committed or still negotiable. List the user stories by backlog identifier. -->

| Sprint | Dates | Sprint Goal | Sprint User Stories | Sprint Status |
| :---: | :---: | :--- | :--- | :---: |
| **Sprint 1** | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| **Sprint 2** | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |
| **Sprint 3** | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

<!-- A release may have several sprints; give each one a row and state which release it belongs to. -->

---

## 3. Sign-off and Approvals

| Role | Name | Signature | Date |
| :--- | :--- | :---: | :---: |
| **Product Owner** | {{Product_Owner_Name}} | _______________________ | [ .... - .... - .... ] |
| **Release / DevOps Lead** | {{Release_Lead_Name}} | _______________________ | [ .... - .... - .... ] |
| **Project Manager** | {{Project_Manager_Name}} | _______________________ | [ .... - .... - .... ] |
---

<div dir="ltr" align="right" style="margin-top: 20px; font-size: 12px; color: #7f8c8d;">
  <span>Electronic Audit Trail: Hash SHA256: {{Audit_Trail_SHA256_Hash}}</span> <br>
  <strong>Template:</strong> RELEASE PLAN | <strong>Ref:</strong> PMO-04.03.09 <br>
  <i>Generated on: {{Current_Timestamp}}, by <a href="https://github.com/fakhruldeen/Tasleemat/" style="color: #7f8c8d;">Tasleemat</a></i>
</div>

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://tasleemat.pmo/schemas/completed/PMO-04.03.09.schema.json",
  "title": "Completed RELEASE PLAN Data Contract",
  "description": "Additive structural schema validating completed RELEASE PLAN artifact data payloads (PMO-04.03.09).",
  "type": "object",
  "properties": {
    "artifact_id": {
      "type": "string",
      "const": "PMO-04.03.09"
    },
    "metadata": {
      "type": "object",
      "properties": {
        "project_name": {
          "type": "string",
          "minLength": 1
        },
        "project_code": {
          "type": "string"
        },
        "date_prepared": {
          "type": "string",
          "format": "date"
        },
        "project_manager": {
          "type": "string",
          "minLength": 1
        },
        "prepared_by": {
          "type": "string",
          "minLength": 1
        },
        "version": {
          "type": "string"
        },
        "status": {
          "type": "string",
          "enum": [
            "draft",
            "baselined",
            "in_review",
            "approved"
          ]
        }
      },
      "required": [
        "project_name",
        "date_prepared",
        "project_manager",
        "prepared_by"
      ]
    },
    "releases": {
      "type": "object",
      "properties": {
        "release": {
          "type": "string",
          "minLength": 1,
          "description": "The release identifier and name, for example R1 or Release 1. A release is the unit the customer receives, not an internal milestone, so name it the way the customer would recognise it."
        },
        "start_date": {
          "type": "string",
          "minLength": 1,
          "description": "When the release starts. For a high-level plan a month or a quarter is honest; a day-level date implies a precision the plan does not have."
        },
        "end_date": {
          "type": "string",
          "minLength": 1,
          "description": "When the release finishes. Give the duration as well as the end date, since the two together are what show whether the release is gaining or losing ground."
        },
        "user_stories": {
          "type": "string",
          "minLength": 1,
          "description": "The requirements or user stories from the backlog assigned to this release, referenced by their backlog identifier rather than restated, so the plan and the backlog cannot drift apart."
        },
        "release_goal": {
          "type": "string",
          "minLength": 1,
          "description": "What this release is for, in one sentence. A release without a goal turns into a list of everything that happened to fit, which is how releases acquire unrelated work."
        },
        "status": {
          "type": "string",
          "minLength": 1,
          "description": "Not started, in progress, or released. This is the column that makes the plan honest: once a sprint has started its contents cannot change, so anything still marked in progress is committed, and anything not started can still move."
        }
      },
      "required": [
        "release",
        "start_date",
        "end_date",
        "user_stories",
        "release_goal",
        "status"
      ]
    },
    "sprint_breakdown": {
      "type": "object",
      "properties": {
        "sprint": {
          "type": "string",
          "minLength": 1,
          "description": "The sprint identifier and the release it belongs to, so the plan can be read per release rather than as one long list."
        },
        "dates": {
          "type": "string",
          "minLength": 1,
          "description": "When the sprint starts and ends. A sprint with no dates cannot be told apart from one that is still open to negotiation, and once it has started its contents are fixed."
        },
        "sprint_goal": {
          "type": "string",
          "minLength": 1,
          "description": "What this sprint is for, in one sentence. Several sprints toward one release goal is the normal case; a sprint goal that contradicts the release goal is a sign the release is carrying two unrelated pieces of work."
        },
        "sprint_user_stories": {
          "type": "string",
          "minLength": 1,
          "description": "The user stories committed to this sprint, by backlog identifier. Once the sprint has started this list is what was committed, and a change to it is a change to the commitment rather than to the plan."
        },
        "sprint_status": {
          "type": "string",
          "minLength": 1,
          "description": "Not started, in progress, or complete."
        }
      },
      "required": [
        "sprint",
        "dates",
        "sprint_goal",
        "sprint_user_stories",
        "sprint_status"
      ]
    }
  },
  "required": [
    "artifact_id",
    "metadata",
    "releases",
    "sprint_breakdown"
  ]
}

{
  "_llm_instructions": "Fill in the 'project_title' and 'date_prepared' properties, and the 'value' property of each field, based on the provided project context. Reference parameters.md for global project variables.",
  "form_name": "RELEASE PLAN",
  "document_reference": "PMO-04.03.09",
  "project_title": "",
  "date_prepared": "",
  "fields": {
    "f01_Release": {
      "section": "Releases",
      "label": "Release",
      "guidance": "The release identifier and name, for example R1 or Release 1. A release is the unit the customer receives, not an internal milestone, so name it the way the customer would recognise it.",
      "value": ""
    },
    "f02_Start_Date": {
      "section": "Releases",
      "label": "Start Date",
      "guidance": "When the release starts. For a high-level plan a month or a quarter is honest; a day-level date implies a precision the plan does not have.",
      "value": ""
    },
    "f03_End_Date": {
      "section": "Releases",
      "label": "End Date",
      "guidance": "When the release finishes. Give the duration as well as the end date, since the two together are what show whether the release is gaining or losing ground.",
      "value": ""
    },
    "f04_User_Stories": {
      "section": "Releases",
      "label": "User Stories",
      "guidance": "The requirements or user stories from the backlog assigned to this release, referenced by their backlog identifier rather than restated, so the plan and the backlog cannot drift apart.",
      "value": ""
    },
    "f05_Release_Goal": {
      "section": "Releases",
      "label": "Release Goal",
      "guidance": "What this release is for, in one sentence. A release without a goal turns into a list of everything that happened to fit, which is how releases acquire unrelated work.",
      "value": ""
    },
    "f06_Status": {
      "section": "Releases",
      "label": "Status",
      "guidance": "Not started, in progress, or released. This is the column that makes the plan honest: once a sprint has started its contents cannot change, so anything still marked in progress is committed, and anything not started can still move.",
      "value": ""
    },
    "f07_Sprint": {
      "section": "Sprint Breakdown",
      "label": "Sprint",
      "guidance": "The sprint identifier and the release it belongs to, so the plan can be read per release rather than as one long list.",
      "value": ""
    },
    "f08_Dates": {
      "section": "Sprint Breakdown",
      "label": "Dates",
      "guidance": "When the sprint starts and ends. A sprint with no dates cannot be told apart from one that is still open to negotiation, and once it has started its contents are fixed.",
      "value": ""
    },
    "f09_Sprint_Goal": {
      "section": "Sprint Breakdown",
      "label": "Sprint Goal",
      "guidance": "What this sprint is for, in one sentence. Several sprints toward one release goal is the normal case; a sprint goal that contradicts the release goal is a sign the release is carrying two unrelated pieces of work.",
      "value": ""
    },
    "f10_Sprint_User_Stories": {
      "section": "Sprint Breakdown",
      "label": "Sprint User Stories",
      "guidance": "The user stories committed to this sprint, by backlog identifier. Once the sprint has started this list is what was committed, and a change to it is a change to the commitment rather than to the plan.",
      "value": ""
    },
    "f11_Sprint_Status": {
      "section": "Sprint Breakdown",
      "label": "Sprint Status",
      "guidance": "Not started, in progress, or complete.",
      "value": ""
    }
  }
}