PMO-04.03.10 Phase 04: Planning

SPRINT PLANNING LOG

سجل تخطيط دورة تطوير

tasleemat asset PMO-04.03.10 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.03.10 ./completed_data.json

Template Markdown (Bilingual)

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

Section Instructions:

**1. Sprint Frame**
*   **Sprint Goal:** The one outcome the sprint is for, stated as a capability the team can demonstrate rather than as a list of stories. A goal written as a list of stories cannot be used to reject anything, and a sprint that cannot reject anything has no goal.
*   **Sprint Window:** The start and end dates, and the length of the sprint. The window is a constraint rather than a preference, because a sprint length that drifts is a velocity figure that means nothing.
*   **Capacity Basis:** How much the team believes it can take on, and what that belief is based on. Capacity stated without its basis is a wish, and the first sprint is where a capacity figure is usually found to be wrong.
*   **Carry-over From the Previous Sprint:** What was not finished, and whether it has been re-estimated or carried as-is. Work carried without a new estimate is work whose estimate has never been tested.

**2. Committed Scope**
*   **Stories Committed:** The stories the team takes on, with the identifier from the board. A story with no identifier cannot be traced when the sprint ends and the question is asked afterwards.
*   **Story Points:** The estimate for each story, and the scale used. Points are a relative comparison rather than a duration, so a scale change between sprints makes two velocities incomparable.
*   **Acceptance Criteria:** What will be true when the story is done, written so that a person who was not in the planning meeting can tell. Criteria agreed after the work is built describe whatever was built.
*   **Scope Added After Planning:** Anything added once the sprint had started, with who asked for it. Scope added mid-sprint is how a sprint stops being a commitment, and the record of who asked is what makes the trade-off visible.

**3. Team Assignment**
*   **Assignee and Availability:** Who is on each story, and how much of their time the sprint actually has. An assignee at full capacity across every story in the log is a plan that has not been made yet.
*   **Skill and Capacity Gaps:** What the committed scope needs that the team does not have. A gap named at planning is a risk to be managed; the same gap found at the end of the sprint is a surprise.
*   **Dependencies Outside the Team:** What must arrive from another team, and by when. A dependency with no date is an assumption, and it is usually discovered on the last day of the sprint.

**4. Risks to the Sprint**
*   **Risks Identified at Planning:** What could stop the sprint, with the trigger that would show it happening. A concern without a trigger has no date and so is not tracked.
*   **Contingency:** What will be dropped or deferred if the risk occurs. A sprint with no contingency is a sprint where the decision gets made under pressure by whoever is most available.

**5. Sign-off and Approvals**
*   **Team Lead, Product Owner, Project Manager:** The three roles that commit the sprint. The product owner commits the priority and the team lead commits the estimate, and a sign-off that has only one of the two is an agreement about half of what was planned.
-->

<h3 dir="ltr" align="right">{{Company_Name}}</h3>
<h2 dir="ltr" align="right">{{Project_Name}} - {{Project_ID}}</h2>
<h1 dir="ltr" align="center">SPRINT PLANNING LOG</h1>

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

## 1. Sprint Frame
<!-- What the sprint is for, over what window, and how much the team believes it can take on. -->

**Sprint Goal:** [ Add details... ]

**Sprint Window:** [ Add details... ]

**Capacity Basis:** [ Add details... ]

**Carry-over From the Previous Sprint:** [ Add details... ]

---

## 2. Committed Scope
<!-- The stories the team takes on, what they are estimated at, and what counts as done. -->

**Stories Committed:**

| Story ID | Story Title | Story Points | Priority | Status |
| :---: | :--- | ---: | :---: | :---: |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

**Acceptance Criteria:**

| Story ID | Acceptance Criteria | Verified By |
| :---: | :--- | :--- |
| [ Add details... ] | [ Add details... ] | [ Add details... ] |

**Scope Added After Planning:**

| Story ID | Reason Added | Requested By | Effect on Sprint |
| :---: | :--- | :--- | :--- |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

---

## 3. Team Assignment
<!-- Who is working on what, how much time the sprint has, and what the committed scope needs that the team does not have. -->

**Assignee and Availability:**

| Team Member | Role | Assigned Stories | Available Capacity |
| :--- | :--- | :--- | :--- |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

**Skill and Capacity Gaps:** [ Add details... ]

**Dependencies Outside the Team:** [ Add details... ]

---

## 4. Risks to the Sprint
<!-- What could stop the sprint, what would show it happening, and what would be given up if it does. -->

**Risks Identified at Planning:**

| Risk | Trigger | Likelihood | Impact | Response |
| :--- | :--- | :--- | :--- | :--- |
| [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] | [ Add details... ] |

**Contingency:** [ Add details... ]

---

## 5. Sign-off and Approvals

| Role | Name | Signature | Date |
| :--- | :--- | :---: | :---: |
| **Site / Execution Lead** | {{Execution_Lead_Name}} | _______________________ | [ .... - .... - .... ] |
| **Project Planner / Scheduler** | {{Scheduler_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> Sprint Planning Log | <strong>Ref:</strong> PMO-04.03.10 <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: Sprint Planning Log

Document Reference: PMO-04.03.10

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

1. What?

A record of one sprint: its goal and window, the stories committed with their estimates and acceptance criteria, who is carrying what, and what could stop it. It is the point at which a sprint becomes a commitment that can be checked rather than an intention.

2. Why?

Because a sprint is agreed in a meeting and reviewed weeks later by people who were not there. Without a record the review becomes an argument about memory, and the numbers that disagree are the ones nobody can reconstruct. The log also makes scope added mid-sprint visible, which is the single largest cause of a sprint finishing over.

3. When?

Prepared at the start of each sprint and completed at its review. Read again whenever the next sprint is planned, because the carry-over and the actual capacity are the two figures that the next estimate depends on.

4. Who?

The team lead records it and owns the estimate, the product owner owns the priority and confirms the goal, and the project manager confirms the sprint fits the release plan. A sign-off with only one of the first two is an agreement about half of what was planned.

Tailoring Tips

A sprint of one story is fine and should be recorded as such; the log is not the place to argue for a smaller number.
Keep the identifiers exactly as the board shows them. A log that paraphrases them cannot be reconciled with the board later.
Where a story carries over, re-estimate it rather than repeating the old number, and say which of the two was done.
An agile team using this form may record only the committed scope and the risks; the remaining sections are there when a release needs defending.
Where the sprint is fixed by a release date rather than by capacity, record the date in the window field so the constraint is visible to whoever reviews the outcome.

Alignment & Dependencies

1. Pre-requisites & Inputs (Upstream Dependencies)

Mandatory:
- Work Breakdown Structure / WBS (PMO-04.02.06)
- Scope Statement (PMO-04.02.05)
Optional / Contextual:
- Resource Requirements (PMO-04.06.02)
- Risk Register (PMO-04.08.02)

2. Downstream Dependents

Mandatory:
- Project Schedule Baseline (PMO-04.03.08)
- Earned Value Analysis / EVA (PMO-06.05)
Optional / Contextual:
- Release Plan (PMO-04.03.09)
- Lookahead Planning Log (PMO-04.03.10)

5. How?

To accurately complete the Sprint Planning Log, populate the following sections based on the project context (ensuring reference to parameters.md for the general project variables):

Sprint Goal: The one outcome the sprint is for, stated as a capability the team can demonstrate rather than as a list of stories. A goal written as a list of stories cannot be used to reject anything, and a sprint that cannot reject anything has no goal.
Sprint Window: The start and end dates, and the length of the sprint. The window is a constraint rather than a preference, because a sprint length that drifts produces a velocity figure that means nothing.
Capacity Basis: How much the team believes it can take on, and what that belief is based on. Capacity stated without its basis is a wish, and the first sprint is where a capacity figure is usually found to be wrong.
Carry-over From the Previous Sprint: What was not finished, and whether it has been re-estimated or carried as-is. Work carried without a new estimate is work whose estimate has never been tested.
Story ID: The identifier from the board, so the story can be traced when the sprint ends and the question is asked afterwards. A story with no identifier cannot be found again once it leaves the room.
Story Title: A short name for the story, in the language the team uses for it. A title that restates the acceptance criteria instead of naming the story makes the log harder to scan than the board it came from.
Story Points: The estimate for each story, and the scale used. Points are a relative comparison rather than a duration, so a scale changed between sprints makes two velocities incomparable.
Priority: Order relative to the other stories in this sprint, and why this story sits where it does. Priority stated as high or medium without a reason is a label rather than an ordering.
Status: Where the story stands at the end of the sprint, against what was committed. A status recorded only at review is too late to be useful to anyone planning the next sprint.
Acceptance Criteria: What will be true when the story is done, written so that a person who was not in the planning meeting can tell. Criteria agreed after the work is built describe whatever was built.
Verified By: Who checks the criteria and when. A criterion with no named verifier is a statement of intent, and the review becomes the first time anyone looks at it.
Reason Added: Why the story entered a sprint that had already been planned. The reason is the part worth recording, because it distinguishes a genuine discovery from a preference.
Requested By: Who asked for the addition, so the trade-off can be discussed with the person who wanted it. Scope added mid-sprint is how a sprint stops being a commitment.
Effect on Sprint: What the addition displaces, or which committed story now carries the risk of not finishing. An addition recorded without an effect reads as free, and it is not.
Team Member: The person, named rather than as a role, so the assignment can be checked against the person's actual availability.
Role: The role this person holds on the sprint, which is not the same as their title outside it. The role decides who settles an argument about scope during the sprint.
Assigned Stories: The stories this person is carrying in this sprint. The list is the thing to read for over-allocation: a person on every story in the log is a plan that has not been made yet.
Available Capacity: How much of this person's time the sprint actually has, after other commitments. Capacity at full for every story in the log is a statement of hope rather than of plan.
Skill and Capacity Gaps: What the committed scope needs that the team does not have. A gap named at planning is a risk to be managed; the same gap found at the end of the sprint is a surprise.
Dependencies Outside the Team: What must arrive from another team, and by when. A dependency with no date is an assumption, and it is usually discovered on the last day of the sprint.
Risk: What could stop the sprint, described as the event rather than as a feeling. A risk written as a concern cannot be managed, because there is nothing to watch for.
Trigger: The observable signal that the risk is happening. This is what makes a risk trackable: without a trigger the item is reviewed at the end of the sprint and found to have happened.
Likelihood: How likely the risk is, and what that judgement rests on. A bare high or low records no basis, so the next person cannot tell whether the estimate improved or the mood changed.
Impact: What the sprint loses if the risk occurs, measured in the same units as the commitment. Impact stated as severe is not comparable to a story estimate.
Response: What will be done about the risk while the sprint is running. A risk with no response is recorded in order to be mentioned later.
Contingency: What will be dropped or deferred if the risk occurs. A sprint with no contingency is a sprint where the decision gets made under pressure by whoever is most available at the time.

📥 Associated Templates

6. Reference Example

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

📖 Completed Example: 04_03_10_Sprint_Planning_Log_Example.md

LLM Generation Prompt & Agent Instructions

SPRINT PLANNING LOG - LLM Generation Prompt

SYSTEM INSTRUCTIONS: This document is the detailed instruction set for generating the SPRINT PLANNING LOG. When asked to populate the template, follow the guidance for each section below to produce the requested content. Refer to parameters.md for the general project variables.

Context and Definition: A sprint plan is a commitment, and the log exists so that the commitment can be read back later by the people who were not in the room. The difference shows up at the review: a sprint whose scope was recorded shows what was traded for what, and a sprint remembered shows only that the two numbers disagree.

The fields that resist filling are the ones worth having. A capacity figure with no basis, a scope addition with no displaced story, and a risk with no trigger are all cheap to leave blank and expensive to discover in week two. Filling them is the whole value of the form, so the guidance below leans on the reason rather than restating the label.

Alignment & Dependencies: * Pre-requisites (Inputs): * Mandatory: Work Breakdown Structure / WBS (PMO-04.02.06), Scope Statement (PMO-04.02.05) * Optional: Resource Requirements (PMO-04.06.02), Risk Register (PMO-04.08.02) * Downstream Dependents: * Mandatory: Project Schedule Baseline (PMO-04.03.08), Earned Value Analysis / EVA (PMO-06.05) * Optional: Release Plan (PMO-04.03.09), Lookahead Planning Log (PMO-04.03.10)

Sprint Frame

Sprint Goal

Instructions: The one outcome the sprint is for, stated as a capability the team can demonstrate rather than as a list of stories. A goal written as a list of stories cannot be used to reject anything, and a sprint that cannot reject anything has no goal.