Sprint Planning: The Engineering of Commitment

Sprint Planning is the process of aligning a team's Capacity (available hours) with its Velocity (historical output) to create a high-confidence commitment. Practitioners must distinguish between "Yesterday's Weather" and active capacity constraints.

I. Capacity Modeling

Capacity is the total amount of time the team can spend on sprint work, accounting for "Focus Factor."

A. The Capacity Formula

\text{Available Capacity} = (\text{Total Dev Hours}) \times \text{Focus Factor}

Total Dev Hours: (Number of Devs\timesDays in Sprint\timesHours per Day).2. Focus Factor ( $F$ ): A value between0.6and0.8representing the time spent on actual coding/testing after subtracting meetings, email, and context switching.
- Low F (0.4-0.5): Heavy on-call rotation or fragmented meetings.
- High F (0.8-0.9): Deep-work environment, minimal overhead.

B. Individual Capacity Worksheet (Example)

Dev A: 10 days $\times$ 6 effective hrs = 60 hrs.
Dev B: 8 days (2 days PTO) $\times$ 6 effective hrs = 48 hrs.
Total Team Capacity: 108 hours.

II. Velocity Volatility

Velocity is a measure of throughput, but its volatility measures the reliability of the team's planning.

A. The Say/Do Ratio

\text{Say/Do Ratio} = \frac{\text{Points Completed}}{\text{Points Committed}}

Target: $0.9 - 1.1$ .* Under 0.8: Indicates over-commitment or "Discovery Debt" (stories were too vague).
Over 1.2: Indicates sandbagging or under-estimation.

B. Coefficient of Variation ( $CV$ )

To measure predictability, calculate the volatility of velocity over the last 5 sprints:

CV = \frac{\sigma(V)}{\bar{V}}

Stable ( $CV < 15\%$ ): Use "Yesterday's Weather" (last sprint's velocity) for planning.* Volatile ( $CV > 20\%$ ): Use a 3-sprint moving average and apply a 20% "uncertainty buffer."

III. The Planning Workflow

Verify Definition of Ready (DoR): Do the top stories have clear Acceptance Criteria?
Calculate Capacity: Subtract PTO, holidays, and scheduled maintenance.
Select Stories: Pull from the backlog based on priority until the sum of points $\approx$ Adjusted Velocity.
Task Out: Break stories into sub-tasks (usually 2-6 hours each). If the sum of task hours > Available Capacity, the story must be removed.

IV. Sprint Planning Template (YAML)

sprint_id: "SP-2025-12"
goal: "Migrate Auth Service to v2 and reduce P95 latency"
capacity:
  total_members: 5
  planned_pto_days: 2
  focus_factor: 0.7
  available_hours: 196 # (5 devs * 8h * 10d * 0.7) - (2 pto * 8h * 0.7)
velocity:
  last_sprint: 42
  moving_avg_3_sprint: 38
  volatility_cv: 0.12
  planning_target: 38
commitment:
  total_points: 36
  stories:
    - id: "AUTH-01"
      points: 8
      risk: "High (Integration with legacy)"
    - id: "AUTH-02"
      points: 5
      risk: "Low"
  unplanned_buffer_hours: 20

V. Critical Failure Modes

Planning to 100% Capacity: Never plan to 100%. Leave 10-20% buffer for the "unknown unknowns" that surface mid-sprint.
Point Inflation: Increasing story points to "show growth" in velocity. This destroys the predictive power of the metric.
Ignoring the "Definition of Done": Claiming points for stories that are "mostly finished." Velocity is binary: 0 or 100.
The "Hero" Fallacy: Assuming one senior dev can absorb the work of three juniors. Capacity is not fungible across specialized domains.