AGILE Sprint Capacity Planning Template

SOP: Agile Sprint Capacity Planning

Document ID: TR-ENG-SOP-042
Effective Date: 2023-10-27
Version: 1.0.0
Review Cadence: Quarterly

---

1. Executive Summary & Purpose

This procedure defines the rigorous, data-driven methodology for calculating sprint capacity at Template Registry. The objective is to normalize velocity across cross-functional teams, minimize delivery variance, and prevent systemic burnout by enforcing empirical constraints on workload allocation.

2. Scope & Prerequisites

• Scope: All engineering, product, and design squads.
• Prerequisites:
  • Access to Jira/Linear/ADO (Source of Truth).
  • Defined team velocity (3-sprint rolling average).
  • Team member availability calendars (updated).
  • Definition of Ready (DoR) and Definition of Done (DoD).

3. Roles & Responsibilities (RACI)

---

4. Step-by-Step Procedure

Phase I: Availability Calculation

• Aggregate total hours per developer per sprint (exclude weekends/holidays).
• Apply the "Load Factor" (Default 0.8 to account for meetings, context switching, and unplanned incidents).
• Identify known constraints (e.g., PTO, training, architecture review cycles).

Phase II: Velocity Normalization

• Review historical velocity (past 3 sprints).
• Adjust for systemic changes (e.g., team size flux, technical debt rotation).
• Subtract "Buffer Capacity" (Minimum 20% for maintenance/production support).

Phase III: Commitment Alignment

• Map high-priority backlog items to available point capacity.
• Validate "Top-Down" estimates against "Bottom-Up" developer tasking.
• Finalize sprint scope; lock commitments in the Sprint Planning meeting.

---

5. Quality Assurance & Pro-Tips

Best Practices

• The 80/20 Rule: Never allocate 100% of capacity. Reserve 20% for operational overhead and technical debt.
• The "Bus Factor" Metric: If a sprint relies on one individual for >50% of capacity, flag as a high-risk dependency.

Common Pitfalls

• Over-committing: Ignoring the "context-switching tax" leads to sprint slippage.
• Point Inflation: Treating points as hours leads to vanity metrics. Points must remain a measure of complexity and risk, not time.

Metric Thresholds

• Say/Do Ratio: Target >90% completion of committed story points.
• Sprint Volatility: Target <15% variance between sprint velocity and rolling average.

---

6. Frequently Asked Questions

Q: What if an emergency arises mid-sprint? A: Utilize the 20% Buffer Capacity. If the buffer is exhausted, the Product Manager must perform a "swap-out" of equal point value to maintain the integrity of the sprint goal.

Q: How do we handle estimates that differ significantly between developers? A: Do not force consensus. Use the "Planning Poker" method—if estimates diverge by >2 levels (e.g., 3 vs 8), facilitate a discussion on ambiguity and re-estimate after clarification.

---

Authorized by: Julian Vance, Chief Architect, Template Registry