PMO-04.02.08 Phase 04: Planning

PRODUCT BACKLOG

قائمة تراكم المنتج
tasleemat asset PMO-04.02.08 template --lang en

Deliverable Summary & Governance Boundaries

Lifecycle Phase Alignment

Phase 04: Planning

Sizing Tier Requirements

Validation Contract

This deliverable conforms to a strict companion Draft 2020-12 JSON Schema for automated structural and semantic validation. 

tasleemat validate PMO-04.02.08 ./completed_data.json

Template Markdown (Bilingual)

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

The product backlog is developed at the very beginning of a project, often in conjunction with the product vision. It keeps track of all the requirements along with their priority and the release they will be incorporated into.

The product backlog is used to document and prioritize the requirements, features, functions, and user stories for releases or sprints. It is developed at the start of the project and is updated throughout the project.

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

Writing guidance:

*   Keep the summary to one or two sentences. An item that needs a paragraph is usually two items, or belongs in the vision.

*   Give every item an identifier that is never reused, because the same identifier appears in the trace from vision to release.

*   Use the same vocabulary in the Status column on every row, since a status column with mixed values cannot be filtered.

*   State which priority scheme is in use, summary groups or numbered rank, because a backlog mixing the two cannot be sorted.

*   Treat the target release as a forecast. An item that keeps moving between releases is telling you something.

*   Cross-reference the product vision, the roadmap, and the release plan rather than restating them, so the three cannot drift apart.

Tailoring Notes:

*   You can add estimating information such as story points.

*   To provide more detail you can indicate which sprint a feature or function will be incorporated into.

*   You may want to indicate the user type that will benefit from the requirement, such as customer, administrator, manager, etc.

*   For large projects it helps to categorize requirements, so having a column that indicates the category can be useful.

*   The Story Points, Target Sprint or Release, User Type, and Category columns are optional. Remove any of them that the project does not use rather than leaving them empty down every row.

Column guidance, by column:
- **ID:** A unique identifier. Keep it short, stable, and never reused, because the same ID appears in the trace from vision to release and a reassigned ID breaks that trace without anyone noticing.
- **Summary Description:** A brief description of the requirement or need, in no more than one or two sentences. If it needs a paragraph, the item is probably two items, or it belongs in the vision rather than the backlog.
- **Priority:** A way of ranking the requirements. Either summary groups such as high, medium, and low, or a numbered rank. State which scheme is in use, because a backlog that mixes the two cannot be sorted.
- **Story:** A prioritised user story, or the name of a user story recorded elsewhere. Where the story lives elsewhere, reference it rather than copying it, so the two do not diverge.
- **Status:** Whether the requirement is not started, in progress, or complete. Use the same set of values for every row, since a status column with mixed vocabularies cannot be filtered.
- **Story Points:** Estimating information such as story points. An estimate is a prediction made to compare against actuals, so record it even when it is a rough guess, and do not revise it silently.
- **Target Sprint or Release:** Which sprint or release the item will be incorporated into. Treat this as a forecast: an item that keeps moving between releases is telling you something, and the churn is worth seeing.
- **User Type:** The user type that will benefit, such as customer, administrator, or manager. This is what shows which parts of the organisation the release actually serves.
- **Category:** A category, which helps on large projects where the backlog is too big to hold in one view. Categories should reflect how the work is actually sequenced, not how the team happens to be divided.
-->

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

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

---

## 1. Backlog
<!-- One row per requirement, feature, function, or user story. The backlog is developed at the start of the project and is updated throughout it, so a row that has not been revisited in months is worse than no row: it looks current and is not. Add or remove rows and columns as the project needs. -->

| ID | Summary Description | Priority | Story | Status | Story Points | Target Sprint or Release | User Type | Category |
| :---: | :--- | :---: | :--- | :---: | ---: | :---: | :--- | :--- |
| [ 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... ] | [ 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... ] | [ 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. Sign-off and Approvals

| Role | Name | Signature | Date |
| :--- | :--- | :---: | :---: |
| **Product Owner** | {{Product_Owner_Name}} | _______________________ | [ .... - .... - .... ] |
| **Scrum Master / Agile Coach** | {{Scrum_Master_Name}} | _______________________ | [ .... - .... - .... ] |
| **Development Team Lead** | {{Dev_Lead_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> PRODUCT BACKLOG | <strong>Ref:</strong> PMO-04.02.08 <br>
  <i>Generated on: {{Current_Timestamp}}, by <a href="https://github.com/fakhruldeen/Tasleemat/" style="color: #7f8c8d;">Tasleemat</a></i>
</div>

User Guide & Practitioner Instructions

Tasleemat Forms Guide

Project Artifact: Product Backlog

Document Reference: PMO-04.02.08

This document provides a comprehensive, professional reference to understand the purpose and effective usage of the Product Backlog in alignment with the Tasleemat framework.

1. What?

A formal Tasleemat-aligned project document known as the Product Backlog, used to document and prioritize the requirements, features, functions, and user stories for releases or sprints. It is developed at the very beginning of a project, often in conjunction with the product vision, and it keeps track of all the requirements along with their priority and the release they will be incorporated into.

It records five elements: the identifier, a summary description, the priority, the user story, and the status. It also carries the four optional columns the tailoring guidance calls for: story points, target sprint or release, user type, and category.

2. Why?

To keep every requirement, its priority, and its target release in one place that is visible to the whole team, so that what is being built next is a matter of record rather than of memory or of who asked most recently.

3. When?

This artifact is prepared at the PLANNING Process Group, under Scope. It is developed at the very beginning of the project and is updated throughout it.

4. Who?

Responsibilities: Maintained by the Product Owner, who is accountable for the ordering and for its accuracy. Estimated, reviewed, and updated by the team.

Tailoring Tips

  • You can add estimating information such as story points.
  • To provide more detail you can indicate which sprint a feature or function will be incorporated into.
  • You may want to indicate the user type that will benefit from the requirement, such as customer, administrator, manager, etc.
  • For large projects it helps to categorize requirements, so having a column that indicates the category can be useful.
  • The Story Points, Target Sprint or Release, User Type, and Category columns are optional. Remove any of them the project does not use, rather than leaving them empty down every row.
  • Add or remove rows as needed. On a large project the backlog will outgrow any single sheet, and a backlog that is split without a stated rule will drift into two backlogs.

Alignment & Dependencies

1. Pre-requisites & Inputs (Upstream Dependencies)

  • Mandatory:
    • Project Charter (PMO-03.01)
    • Stakeholder Requirements
  • Optional / Contextual:
    • Product Vision (PMO-03.02)
    • Assumption Log (PMO-03.03)

2. Downstream Dependents

  • Mandatory:
    • Work Breakdown Structure / WBS (PMO-04.02.06)
    • Project Schedule (PMO-04.03.08)
    • Cost Estimates (PMO-04.04.02)
  • Optional / Contextual:
    • Product Backlog (PMO-04.02.08)
    • Quality Metrics (PMO-04.05.02)

5. How?

To accurately and professionally complete the PRODUCT BACKLOG, the responsible party must populate the following sections based on the project context (ensure parameters.md is referenced for global project variables):

  • ID: A unique identifier. Keep it short, stable, and never reused, because the same ID appears in the trace from vision to release and a reassigned ID breaks that trace without anyone noticing.
  • Summary Description: A brief description of the requirement or need, in no more than one or two sentences. If it needs a paragraph, the item is probably two items, or it belongs in the vision rather than the backlog.
  • Priority: A way of ranking the requirements. Either summary groups such as high, medium, and low, or a numbered rank. State which scheme is in use, because a backlog that mixes the two cannot be sorted.
  • Story: A prioritised user story, or the name of a user story recorded elsewhere. Where the story lives elsewhere, reference it rather than copying it, so the two do not diverge.
  • Status: Whether the requirement is not started, in progress, or complete. Use the same set of values for every row, since a status column with mixed vocabularies cannot be filtered.
  • Story Points: Estimating information such as story points. An estimate is a prediction made to compare against actuals, so record it even when it is a rough guess, and do not revise it silently.
  • Target Sprint or Release: Which sprint or release the item will be incorporated into. Treat this as a forecast: an item that keeps moving between releases is telling you something, and the churn is worth seeing.
  • User Type: The user type that will benefit, such as customer, administrator, or manager. This is what shows which parts of the organisation the release actually serves.
  • Category: A category, which helps on large projects where the backlog is too big to hold in one view. Categories should reflect how the work is actually sequenced, not how the team happens to be divided.

📥 Associated Templates

6. Reference Example

A fully completed, gold-standard reference example illustrating this artifact in practice is available:

📖 Completed Example: 04_02_08_Product_Backlog_Example.md

LLM Generation Prompt & Agent Instructions

PRODUCT BACKLOG - LLM GENERATION GUIDE

System Prompt / Instructions: This document serves as the detailed instruction set for generating the PRODUCT BACKLOG. When asked to populate this form, use the guidance provided for each section below to accurately generate the required content. Reference parameters.md for global project variables.

Context & Definition: The product vision provides the future view of the product being developed. It is aspirational, yet achievable and realistic, and is developed at the very beginning of a project, where it is often an input to the business case. On agile-based projects it is often used in place of a project charter, and it is developed once, at the beginning.

Alignment & Dependencies: * Pre-requisites (Inputs): * Mandatory: Project Charter (PMO-03.01), Stakeholder Requirements * Optional: Product Vision (PMO-03.02), Assumption Log (PMO-03.03) * Downstream Dependents: * Mandatory: Work Breakdown Structure / WBS (PMO-04.02.06), Project Schedule (PMO-04.03.08), Cost Estimates (PMO-04.04.02) * Optional: Product Backlog (PMO-04.02.08), Quality Metrics (PMO-04.05.02)

Backlog

ID

Instruction: A unique identifier. Keep it short, stable, and never reused, because the same ID appears in the trace from vision to release and a reassigned ID breaks that trace without anyone noticing.

Generated value: [ Add details... ]

Summary Description

Instruction: A brief description of the requirement or need, in no more than one or two sentences. If it needs a paragraph, the item is probably two items, or it belongs in the vision rather than the backlog.

Generated value: [ Add details... ]

Priority

Instruction: A way of ranking the requirements. Either summary groups such as high, medium, and low, or a numbered rank. State which scheme is in use, because a backlog that mixes the two cannot be sorted.

Generated value: [ Add details... ]

Story

Instruction: A prioritised user story, or the name of a user story recorded elsewhere. Where the story lives elsewhere, reference it rather than copying it, so the two do not diverge.

Generated value: [ Add details... ]

Status

Instruction: Whether the requirement is not started, in progress, or complete. Use the same set of values for every row, since a status column with mixed vocabularies cannot be filtered.

Generated value: [ Add details... ]

Story Points

Instruction: Estimating information such as story points. An estimate is a prediction made to compare against actuals, so record it even when it is a rough guess, and do not revise it silently.

Generated value: [ Add details... ]

Target Sprint or Release

Instruction: Which sprint or release the item will be incorporated into. Treat this as a forecast: an item that keeps moving between releases is telling you something, and the churn is worth seeing.

Generated value: [ Add details... ]

User Type

Instruction: The user type that will benefit, such as customer, administrator, or manager. This is what shows which parts of the organisation the release actually serves.

Generated value: [ Add details... ]

Category

Instruction: A category, which helps on large projects where the backlog is too big to hold in one view. Categories should reflect how the work is actually sequenced, not how the team happens to be divided.

Generated value: [ Add details... ]

PMO-04.02.08 Phase 04: Planning Realistic Case Study Benchmark
Date Prepared
2026-03-15
Project Manager
Faisal Al-Harbi, PMP
Prepared By
Faisal Al-Harbi, PMP (Senior Project Manager)

Product Backlog (Reference Example)

🏆 Gold Standard Reference Example: This document illustrates a fully completed, production-grade artifact adhering to the Tasleemat PMO Framework (PMO-04.02). All company names, project references, and figures are realistic fictional simulations.

Apex Global Solutions

Apex Unified Cloud ERP & Supply Chain Modernization - PRJ-2026-ERP-01

PRODUCT BACKLOG

1. Backlog

ID Summary Description Priority Story Status Story Points Target Sprint or Release User Type Category
INIT-01 Deploy hardened cloud environment and master databases Approved and aligned with Apex Global Solutions governance baseline Approved and aligned with Apex Global Solutions governance baseline In Progress Approved and aligned with Apex Global Solutions governance baseline Approved and aligned with Apex Global Solutions governance baseline Technical & Integration Technical & Integration
REQ-02 Automate procurement requisition and inventory workflows Approved and aligned with Apex Global Solutions governance baseline Approved and aligned with Apex Global Solutions governance baseline Completed Approved and aligned with Apex Global Solutions governance baseline Approved and aligned with Apex Global Solutions governance baseline Operational & Functional Operational & Functional
ACT-03 Build interactive executive dashboards and KPI reports Approved and aligned with Apex Global Solutions governance baseline Approved and aligned with Apex Global Solutions governance baseline Planned Approved and aligned with Apex Global Solutions governance baseline Approved and aligned with Apex Global Solutions governance baseline Governance & Compliance Governance & Compliance
BEN-04 Conduct comprehensive end-user enablement workshops Approved and aligned with Apex Global Solutions governance baseline Approved and aligned with Apex Global Solutions governance baseline Approved Approved and aligned with Apex Global Solutions governance baseline Approved and aligned with Apex Global Solutions governance baseline Cloud Infrastructure Cloud Infrastructure
WBS-05 Deploy hardened cloud environment and master databases Approved and aligned with Apex Global Solutions governance baseline Approved and aligned with Apex Global Solutions governance baseline In Progress Approved and aligned with Apex Global Solutions governance baseline Approved and aligned with Apex Global Solutions governance baseline Cybersecurity Cybersecurity
DEL-06 Automate procurement requisition and inventory workflows Approved and aligned with Apex Global Solutions governance baseline Approved and aligned with Apex Global Solutions governance baseline Completed Approved and aligned with Apex Global Solutions governance baseline Approved and aligned with Apex Global Solutions governance baseline Technical & Integration Technical & Integration
AUD-07 Build interactive executive dashboards and KPI reports Approved and aligned with Apex Global Solutions governance baseline Approved and aligned with Apex Global Solutions governance baseline Planned Approved and aligned with Apex Global Solutions governance baseline Approved and aligned with Apex Global Solutions governance baseline Operational & Functional Operational & Functional
INIT-08 Conduct comprehensive end-user enablement workshops Approved and aligned with Apex Global Solutions governance baseline Approved and aligned with Apex Global Solutions governance baseline Approved Approved and aligned with Apex Global Solutions governance baseline Approved and aligned with Apex Global Solutions governance baseline Governance & Compliance Governance & Compliance

2. Sign-off and Approvals

Role Name Signature Date
Product Owner Mariam Al-Khatib (Principal Product Owner) [Electronically Signed] 2026-03-18
Scrum Master / Agile Coach Hassan Al-Majid, CSM [Electronically Signed] 2026-03-18
Development Team Lead Eng. Walid Al-Hammad (Development Lead) [Electronically Signed] 2026-03-18
---
Template: PRODUCT BACKLOG | Ref: PMO-04.02.08
Generated on: 2026-03-15 10:00 UTC, by Tasleemat

Draft 2020-12 JSON Schema

Canonical machine-readable data contract for automated payload validation with tasleemat CLI. 
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://tasleemat.pmo/schemas/completed/PMO-04.02.08.schema.json",
  "title": "Completed PRODUCT BACKLOG Data Contract",
  "description": "Additive structural schema validating completed PRODUCT BACKLOG artifact data payloads (PMO-04.02.08).",
  "type": "object",
  "properties": {
    "artifact_id": {
      "type": "string",
      "const": "PMO-04.02.08"
    },
    "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"
      ]
    },
    "backlog": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string",
          "minLength": 1,
          "description": "A unique identifier. Keep it short, stable, and never reused, because the same ID appears in the trace from vision to release and a reassigned ID breaks that trace without anyone noticing."
        },
        "summary_description": {
          "type": "string",
          "minLength": 1,
          "description": "A brief description of the requirement or need, in no more than one or two sentences. If it needs a paragraph, the item is probably two items, or it belongs in the vision rather than the backlog."
        },
        "priority": {
          "type": "string",
          "minLength": 1,
          "description": "A way of ranking the requirements. Either summary groups such as high, medium, and low, or a numbered rank. State which scheme is in use, because a backlog that mixes the two cannot be sorted."
        },
        "story": {
          "type": "string",
          "minLength": 1,
          "description": "A prioritised user story, or the name of a user story recorded elsewhere. Where the story lives elsewhere, reference it rather than copying it, so the two do not diverge."
        },
        "status": {
          "type": "string",
          "minLength": 1,
          "description": "Whether the requirement is not started, in progress, or complete. Use the same set of values for every row, since a status column with mixed vocabularies cannot be filtered."
        },
        "story_points": {
          "type": "string",
          "minLength": 1,
          "description": "Estimating information such as story points. An estimate is a prediction made to compare against actuals, so record it even when it is a rough guess, and do not revise it silently."
        },
        "target_sprint_or_release": {
          "type": "string",
          "minLength": 1,
          "description": "Which sprint or release the item will be incorporated into. Treat this as a forecast: an item that keeps moving between releases is telling you something, and the churn is worth seeing."
        },
        "user_type": {
          "type": "string",
          "minLength": 1,
          "description": "The user type that will benefit, such as customer, administrator, or manager. This is what shows which parts of the organisation the release actually serves."
        },
        "category": {
          "type": "string",
          "minLength": 1,
          "description": "A category, which helps on large projects where the backlog is too big to hold in one view. Categories should reflect how the work is actually sequenced, not how the team happens to be divided."
        }
      },
      "required": [
        "id",
        "summary_description",
        "priority",
        "story",
        "status",
        "story_points",
        "target_sprint_or_release",
        "user_type",
        "category"
      ]
    }
  },
  "required": [
    "artifact_id",
    "metadata",
    "backlog"
  ]
}
📋 Form Field Definitions Dictionary (Legacy Specification) 
{
  "_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": "PRODUCT BACKLOG",
  "document_reference": "PMO-04.02.08",
  "project_title": "",
  "date_prepared": "",
  "fields": {
    "f01_ID": {
      "section": "Backlog",
      "label": "ID",
      "guidance": "A unique identifier. Keep it short, stable, and never reused, because the same ID appears in the trace from vision to release and a reassigned ID breaks that trace without anyone noticing.",
      "value": ""
    },
    "f02_Summary_Description": {
      "section": "Backlog",
      "label": "Summary Description",
      "guidance": "A brief description of the requirement or need, in no more than one or two sentences. If it needs a paragraph, the item is probably two items, or it belongs in the vision rather than the backlog.",
      "value": ""
    },
    "f03_Priority": {
      "section": "Backlog",
      "label": "Priority",
      "guidance": "A way of ranking the requirements. Either summary groups such as high, medium, and low, or a numbered rank. State which scheme is in use, because a backlog that mixes the two cannot be sorted.",
      "value": ""
    },
    "f04_Story": {
      "section": "Backlog",
      "label": "Story",
      "guidance": "A prioritised user story, or the name of a user story recorded elsewhere. Where the story lives elsewhere, reference it rather than copying it, so the two do not diverge.",
      "value": ""
    },
    "f05_Status": {
      "section": "Backlog",
      "label": "Status",
      "guidance": "Whether the requirement is not started, in progress, or complete. Use the same set of values for every row, since a status column with mixed vocabularies cannot be filtered.",
      "value": ""
    },
    "f06_Story_Points": {
      "section": "Backlog",
      "label": "Story Points",
      "guidance": "Estimating information such as story points. An estimate is a prediction made to compare against actuals, so record it even when it is a rough guess, and do not revise it silently.",
      "value": ""
    },
    "f07_Target_Sprint_or_Release": {
      "section": "Backlog",
      "label": "Target Sprint or Release",
      "guidance": "Which sprint or release the item will be incorporated into. Treat this as a forecast: an item that keeps moving between releases is telling you something, and the churn is worth seeing.",
      "value": ""
    },
    "f08_User_Type": {
      "section": "Backlog",
      "label": "User Type",
      "guidance": "The user type that will benefit, such as customer, administrator, or manager. This is what shows which parts of the organisation the release actually serves.",
      "value": ""
    },
    "f09_Category": {
      "section": "Backlog",
      "label": "Category",
      "guidance": "A category, which helps on large projects where the backlog is too big to hold in one view. Categories should reflect how the work is actually sequenced, not how the team happens to be divided.",
      "value": ""
    }
  }
}