# Sprint Planning — Estimation, Capacity, and Commitment

<!-- hint:slides topic="Sprint planning: two parts, estimation techniques, velocity vs capacity, Definition of Ready, and common pitfalls" slides="5" -->

## What Is Sprint Planning?

**Sprint planning** is the Scrum ceremony where the team decides what work to do in the upcoming sprint and how to do it. It's a timeboxed event (typically 2–4 hours for a 2-week sprint) that produces two outcomes: a **sprint goal** and a **sprint backlog**.

Scrum defines sprint planning as having two parts:

1. **What** — What can we achieve this sprint? (Product Owner presents the goal; team selects work.)
2. **How** — How will we build it? (Team plans tasks and approach.)

## The Two Parts of Sprint Planning

| Part | Who Leads | Output |
|------|-----------|--------|
| **What** | Product Owner | Sprint goal, selected backlog items |
| **How** | Development Team | Tasks, breakdown, approach |

The Product Owner explains the objective and proposed backlog items. The Development Team estimates capacity, selects items, and defines how they'll deliver them. The Scrum Master facilitates but doesn't make content decisions.

## The Sprint Goal

A sprint goal is a **single, cohesive objective** for the sprint. It answers: "Why are we doing this work together?"

**Weak:** "Complete user stories from the backlog."

**Strong:** "Enable users to reset their password without calling support."

The sprint goal creates focus. When trade-offs arise during the sprint, the team asks: "Does this support the goal?"

## Estimation Techniques

### Story Points

Story points measure **relative complexity**, not hours. A 3-point story is roughly 1.5× a 2-point story. Teams calibrate over time.

**Fibonacci sequence (common):** 1, 2, 3, 5, 8, 13, 21

Larger numbers = more uncertainty. If a story feels bigger than 13, split it.

### T-Shirt Sizing

Fast, non-numeric: **XS, S, M, L, XL**. Good for backlogs where precise points aren't needed. Map to points later if required (e.g., S=1, M=3, L=5, XL=8).

### Planning Poker

1. Product Owner reads the story.
2. Everyone privately picks a card (story point value).
3. Reveal simultaneously.
4. Discuss outliers—why did someone pick 2 and someone 8?
5. Re-vote until consensus.

Planning poker surfaces assumptions and promotes conversation. The estimate is a byproduct; the discussion is the value.

## Velocity vs Capacity

| Term | Meaning |
|------|---------|
| **Velocity** | Historical throughput—how many points the team typically completes per sprint. Measured *after* the sprint. |
| **Capacity** | Available person-hours (or person-days) for the sprint. Planned *before* the sprint. |

**Capacity** = Team size × Working days × Hours per day × (1 − % meetings/admin)

**Velocity** = Average points completed over last 2–3 sprints (or team's best guess for new teams).

Use velocity to **forecast** how much work *might* get done. Use capacity to sanity-check that you haven't over-committed.

## Commitment vs Forecast

- **Commitment** — The team commits to the sprint goal. They'll do everything in their power to achieve it. Scope may be adjusted if the goal changes or becomes invalid.
- **Forecast** — The selected backlog items are a *forecast*, not a promise. The team will rebalance as they learn.

In practice: commit to the *goal*; treat the *product backlog items* as a best-effort forecast.

## Definition of Ready

Items must be **ready** before sprint planning. Definition of Ready (DoR) might include:

- [ ] Clear acceptance criteria
- [ ] Sized (or at least discussed)
- [ ] Dependencies identified
- [ ] Technical feasibility understood

If items aren't ready, the team spends planning time clarifying instead of committing. Define your DoR as a team.

## Sprint Planning Flow

```mermaid
flowchart TD
  A[Product Owner presents goal + proposed items] --> B[Team discusses capacity]
  B --> C[Team selects items for sprint]
  C --> D[Team breaks down into tasks]
  D --> E[Sprint goal agreed]
  E --> F[Sprint backlog complete]
  F --> G[Sprint starts]
```

## Common Anti-Patterns

1. **Over-commitment** — Loading the sprint to 100%+ of velocity. Leave buffer for unknowns; 80–90% is often healthier.
2. **No sprint goal** — A list of unrelated stories with no unifying purpose.
3. **Estimating in hours** — Hours are precise but mislead; complexity and uncertainty matter more. Story points keep the focus on relative effort.
4. **Skipping the "how"** — Only selecting stories without tasking. The team discovers blockers mid-sprint.
5. **Stakeholders dictating scope** — Sprint planning is a team decision. External pressure to "fit more in" undermines ownership.

## Tips for Remote Sprint Planning

- **Async prep:** Share proposed items and context 24–48 hours before. Let people read ahead.
- **Break into two sessions:** Part 1 (what) and Part 2 (how) on different days if attention wanes.
- **Use shared boards:** Miro, FigJam, or Jira/Linear so everyone can see and edit.
- **Timebox rigorously:** 15-min chunks per topic; move on even if not "perfect."
- **Cameras on for key decisions:** When voting or agreeing the goal, visibility helps.
- **Document decisions:** Capture sprint goal and key assumptions in a shared doc immediately.

## Sprint Goal Template

```markdown
## Sprint Goal

**Sprint:** [Sprint X — dates]

**Goal:** [One sentence: what outcome we're aiming for]

**Success looks like:** [2–3 concrete outcomes or demos]

**Out of scope this sprint:** [What we're explicitly NOT doing]
```

## Capacity Calculation Example

```markdown
Team: 5 developers, 2-week sprint
Working days: 10
Hours per developer per day: 6 (after meetings)
Meeting/admin overhead: ~15%

Capacity = 5 × 10 × 6 × 0.85 ≈ 255 developer-hours
```

Use velocity (e.g., 45 points last sprint) to forecast how many points to pull. If capacity is lower (holidays, PTO), pull fewer points.