Template for AGILE Sprint Planning

Standard Operating Procedure: Agile Sprint Planning (ASP-001)

---

1. Executive Summary & Purpose

The purpose of this SOP is to standardize the execution of Sprint Planning ceremonies at Template Registry. This procedure ensures alignment between product vision and engineering execution, minimizes scope creep, and maintains a consistent velocity-based delivery rhythm.

2. Scope & Prerequisites

• Scope: Applies to all product engineering squads utilizing the Scrum or Kanban-hybrid framework.
• Prerequisites:
  • Fully groomed Product Backlog (Top 2 Sprints worth of tickets).
  • Velocity metrics from the previous three sprints.
  • Software Tools: Jira (or equivalent), Confluence, Slack/Teams (Communication), Velocity Chart Dashboard.
  • PPE/Infrastructure: Stable high-bandwidth connection; functional screen-sharing environment.

3. Roles & Responsibilities (RACI)

---

4. Step-by-Step Procedure

Phase I: Pre-Planning (48 Hours Prior)

• PO updates backlog prioritization based on current business KPIs.
• SM ensures all tickets in the proposed scope have clear Acceptance Criteria (AC).
• Engineering Lead confirms team capacity (considering PTO and operational overhead).

Phase II: The Planning Ceremony (Max 2 Hours)

• Review Capacity: SM presents the calculated capacity (Total Hours minus 20% buffer).
• Goal Alignment: PO presents the "Sprint Goal."
• Capacity Mapping: Team selects tickets from top of backlog until capacity is reached.
• Estimation Validation: Team confirms story point complexity (Planning Poker/Relative Sizing).
• Commitment: Team signs off on the Sprint Scope; SM officially "Starts" the Sprint in Jira.

Phase III: Post-Planning (Immediate)

• SM updates the Sprint Burndown Chart.
• PO notifies stakeholders of the finalized scope.

---

5. Quality Assurance & Pro-Tips

QA Metrics

• Say/Do Ratio: Threshold should be > 85% completion.
• Carry-over: Must be < 10% of total story points per sprint.
• Definition of Ready (DoR): 100% of selected tickets must meet the DoR before the ceremony starts.

Pro-Tips

• The 80% Rule: Never plan to 100% capacity. Plan to 80% to account for technical debt, production fires, and context switching.
• Avoid "Analysis Paralysis": If a ticket requires >15 minutes of discussion, pull it out of the sprint and move it to a "Spike" ticket for further research.
• Focus on the Goal: The Sprint Goal is more important than the individual ticket count.

---

6. Frequently Asked Questions

Q: What do we do if we finish the sprint early?

• A: Pull from the top of the prioritized backlog. Do not "stretch" existing tickets unless there is a clear, high-impact technical necessity.

Q: How should we handle unexpected urgent production bugs mid-sprint?

• A: Utilize the 20% buffer. If the buffer is exhausted, the PO must authorize the removal of an equal amount of story points to maintain the integrity of the sprint commitment.

Q: Who decides if a ticket is "Ready" for the Sprint?

• A: The engineering team. If the team feels the AC is ambiguous or the scope is too broad, the ticket must be returned to the grooming queue.

---

Authorized by: Julian Vance, Chief Architect, Template Registry