Sprint Planning in AGILE Template

Standard Operating Procedure: Agile Sprint Planning for Template Architecture

---

1. Executive Summary & Purpose

This Standard Operating Procedure (SOP) defines the institutional requirements, operational workflows, and governance metrics for conducting Sprint Planning within the Template Registry engineering organization. The purpose of this protocol is to align engineering output with architectural roadmaps, ensure deterministic velocity metrics, and maintain rigorous quality gates for all template deliverables. Compliance with this SOP is mandatory for all cross-functional engineering teams.

---

2. Scope & Prerequisites

2.1 Scope

This procedure applies to all Scrum teams, Product Owners, Scrum Masters, and Principal Architects operating within the Template Registry ecosystem. It governs the transition of backlog items into committed, executable sprint backlogs.

2.2 Prerequisites & Tooling

• Jira Enterprise / Azure DevOps: Configured with strict workflow states (Backlog, Groomed, Ready for Planning).
• Confluence: For live architectural documentation and Sprint Goal hosting.
• Mural / Miro: Authorized digital whiteboard for capacity mapping and dependency visualization.
• Historical Velocity Metrics: Access to the past three sprints' burndown and throughput data.
• Template Registry Design System: Current versions loaded and accessible via local development environments.

---

3. Roles & Responsibilities (RACI Matrix)

---

4. Step-by-Step Procedure

Phase 1: Pre-Planning Preparation (T-48 Hours)

• Product Owner finalizes and grooms the top 150% of the upcoming sprint's projected capacity in the product backlog.
• Architecture leads review candidate template tickets for systemic dependencies, technical debt, and adherence to Template Registry design patterns.
• Scrum Master extracts historical velocity data to calculate baseline team capacity, accounting for planned PTO and operational overhead (15% reserve standard).

Phase 2: Part 1 - Establishing the Sprint Goal & Capacity (T-0 Hours)

• Step 2.1: Scrum Master opens the Sprint Planning session and presents the team's calculated net capacity in Story Points (SP) or Ideal Engineering Days.
• Step 2.2: Product Owner presents the strategic business objective, framing the overarching Sprint Goal.
• Step 2.3: Team reviews the Sprint Goal against current architectural constraints and reaches consensus on achievability.

Phase 3: Part 2 - Backlog Item Selection & Commitment (T + 45 Minutes)

• Step 3.1: The team pulls prioritized user stories and template tasks from the top of the backlog into the active sprint container.
• Step 3.2: For each template task, the team executes Planning Poker to estimate complexity, ensuring alignment with definition of ready (DoR) criteria.
• Step 3.3: Sub-tasks are generated for complex template integration paths, CI/CD pipeline validation, and automated test coverage.
• Step 3.4: The team validates that total committed points do not exceed 100% of the verified net capacity.

Phase 4: Finalization & Activation (T + 90 Minutes)

• Step 4.1: Scrum Master formally initiates the Sprint in Jira/ADO.
• Step 4.2: Product Owner locks the Sprint Backlog; no scope additions are permitted post-activation without an emergency change request.
• Step 4.3: Confluence Sprint Page is published, detailing the Sprint Goal, scope manifest, and assigned ownership matrices.

---

5. Quality Assurance & Pro-Tips

5.1 Best Practices

• Definition of Ready (DoR) Enforcement: Never pull a ticket into a sprint unless acceptance criteria are explicitly defined and visual template assets are attached.
• Buffer Allocation: Always reserve 20% of sprint capacity for unpredicted technical debt or platform stability maintenance.

5.2 Common Pitfalls

• Optimism Bias: Overcommitting based on ideal developer output rather than historical rolling averages. Mitigation: Strictly enforce the historical velocity cap.
• Undefined Acceptance Criteria: Accepting vague template updates ("make UI cleaner"). Mitigation: Reject tickets lacking explicit rendering parameters and accessibility standards (WCAG 2.1 AA).

5.3 Metric Thresholds

• Planning Accuracy (Commitment vs. Completed): $\ge 85%$.
• Capacity Utilization: Between $85%$ and $100%$.

---

6. Frequently Asked Questions (FAQ)

Q: What happens if a critical production bug emerges mid-sprint that requires immediate architectural intervention?
A: The Product Owner and Engineering Lead must evaluate the disruption. If the bug consumes $>20%$ of team capacity, an equivalent weight of non-critical template tasks must be dropped from the sprint back to the product backlog to preserve sprint integrity.

Q: Can story points be modified after the Sprint Planning session concludes?
A: No. Once the sprint is activated, story points are immutable historical data points. If a template task proves significantly larger than estimated, the discrepancy is addressed via velocity tracking in the retrospective and handled by splitting the story in a subsequent cycle.