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

Context and Definition:
A definition of ready and a definition of done are a standard rather than a
record. They are written once, at the start, and every piece of work is then
measured against them, which is what separates this from a checklist that is
filled in per item.

The two definitions point in opposite directions. The definition of ready is
a promise made by whoever brings work in, and it is the team's only legitimate
reason to refuse work. Its value depends on being small: a ready standard that
cannot be met is one that gets waived, and once it is waived the team has lost
the right to ask the question at all.

The definition of done is a promise made to whoever reads the work later, and
it is the one that decays. Every story shipped with an exception makes the
standard weaker for the next one, and nothing in the process stops that
exception becoming the rule. So the done criteria are written once and applied
without renegotiation, and a justified exception is logged as an exception
rather than folded back into the definition where nobody will see it.

Both are about evidence rather than intention. Ready does not mean the team
believes the work is well formed; it means somebody can check without asking
the author. Done does not mean the developer believes it works; it means a test
exists that somebody else ran.

It can receive information from:
*   The product backlog, which is where the acceptance criteria already live or
    should live
*   The team's retrospective findings, which is where a criterion that is being
    waived should be reported
*   The estimation record, so the ready standard reflects what estimating
    actually requires

It provides information to:
*   The sprint planning log, which applies the ready standard when work is pulled
*   The team performance assessment, which can only be read against a standard
*   The change log, because a change that was not tested is the change the done
    standard exists to prevent

Tailoring Tips:
*   Keep the ready standard short. It is the only reason the team can refuse
    work, and a standard that cannot be met is a standard that will be waived.
*   Write the done standard once and apply it without renegotiation. A
    justified exception belongs in an exception log, because a definition that
    is quietly rewritten is one nobody can hold anybody to.
*   Make every item checkable by somebody other than its author. Both
    definitions are about evidence, and the moment an item can only be confirmed
    by the person who wrote it, it is a statement of confidence rather than a
    criterion.

Alignment:
The definition of ready and done standard should be aligned and consistent with:
*   The team's estimation record, so the ready standard reflects real practice
*   The retrospective, which is where a criterion that keeps being waived is
    reported rather than quietly dropped
*   The change control process, since a change that has not been tested is the
    case the done standard exists to catch

Section Instructions:
*   Definition of Ready (DoR): the conditions work must satisfy before the team
    picks it up, each written so a second person can check it.
*   Definition of Done (DoD): the conditions that must hold before work is
    called finished, each written so somebody other than the author could
    confirm it.
-->

<h3 dir="ltr" align="right">{{Company_Name}}</h3>
<h2 dir="ltr" align="right">{{Project_Name}} - {{Project_ID}}</h2>
<h1 dir="ltr" align="center">DEFINITION OF READY AND DONE STANDARD</h1>

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

---

## Team Working Agreement

### Definition of Ready (DoR)

[ Add details... ]

---

### Definition of Done (DoD)

[ Add details... ]

---

### 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> DEFINITION OF READY AND DONE STANDARD | <strong>Ref:</strong> PMO-04.05.03 <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.05.03.schema.json",
  "title": "Completed Definition of Ready and Done Standard Data Contract",
  "description": "Additive structural schema validating completed Definition of Ready and Done Standard artifact data payloads (PMO-04.05.03).",
  "type": "object",
  "properties": {
    "artifact_id": {
      "type": "string",
      "const": "PMO-04.05.03"
    },
    "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"
      ]
    },
    "team_working_agreement": {
      "type": "object",
      "properties": {
        "definition_of_ready_dor": {
          "type": "string",
          "minLength": 1,
          "description": "What a piece of work must satisfy before the team will pick it up. The test for every item is that a second person can check it without asking the author: the acceptance criteria are written and are unambiguous, the dependency is named, the estimate exists. \"The team believes it is understood\" is not ready; \"the acceptance criteria are in the ticket and no two readers would build different things from them\" is."
        },
        "definition_of_done_dod": {
          "type": "string",
          "minLength": 1,
          "description": "What must be true before a piece of work is called finished, stated so that somebody other than the author could confirm each one: the change is reviewed, the tests exist and pass, the documentation follows the change, and the acceptance criteria are met. This is the definition that decays, because every story shipped with an exception weakens it for the next one and nothing stops that becoming the rule. It is written once and applied without renegotiation; a justified exception is logged, not folded back into the definition."
        }
      },
      "required": [
        "definition_of_ready_dor",
        "definition_of_done_dod"
      ]
    }
  },
  "required": [
    "artifact_id",
    "metadata",
    "team_working_agreement"
  ]
}

{
  "form_name": "Definition of Ready and Done Standard",
  "document_reference": "PMO-04.05.03",
  "_llm_instructions": "Populate the fields of 'Definition of Ready and Done Standard' and write the value of each field under 'Generated Value', based on the project context. Context: the project carrying reference PMO-04.05.03.",
  "fields": {
    "f01_Definition_of_Ready_DoR": {
      "section": "Team Working Agreement",
      "label": "Definition of Ready (DoR)",
      "guidance": "What a piece of work must satisfy before the team will pick it up. The test for every item is that a second person can check it without asking the author: the acceptance criteria are written and are unambiguous, the dependency is named, the estimate exists. \"The team believes it is understood\" is not ready; \"the acceptance criteria are in the ticket and no two readers would build different things from them\" is.",
      "value": ""
    },
    "f02_Definition_of_Done_DoD": {
      "section": "Team Working Agreement",
      "label": "Definition of Done (DoD)",
      "guidance": "What must be true before a piece of work is called finished, stated so that somebody other than the author could confirm each one: the change is reviewed, the tests exist and pass, the documentation follows the change, and the acceptance criteria are met. This is the definition that decays, because every story shipped with an exception weakens it for the next one and nothing stops that becoming the rule. It is written once and applied without renegotiation; a justified exception is logged, not folded back into the definition.",
      "value": ""
    }
  }
}