Sprint Planning Best Practices

Sprint planning is where strategy meets execution. A good planning session produces achievable commitments, clear goals, and a team that knows exactly what to build. A bad one creates overcommitment, confusion, and sprint failure before it starts.

Planning Problems

Preparation

Before the Meeting

SPRINT PLANNING PREPARATION
═══════════════════════════

PRODUCT OWNER PREP:
─────────────────────────────────────
□ Backlog groomed and prioritized
□ Top items have:
  ├── Clear acceptance criteria
  ├── Estimates (from refinement)
  ├── Dependencies identified
  └── Questions resolved
□ Priority clear for top 150% of capacity
□ Sprint goal drafted
□ Stakeholder input gathered

SCRUM MASTER PREP:
─────────────────────────────────────
□ Previous sprint data reviewed
  ├── Velocity average
  ├── Completion rate
  └── Issues to address
□ Capacity calculated
  ├── Team availability
  ├── PTO noted
  ├── Other commitments
□ Meeting scheduled and rooms booked
□ Tools ready (GitScrum, projector)
□ Timeboxes planned

TEAM PREP:
─────────────────────────────────────
□ Previous sprint work completed or handed off
□ Questions about top backlog items noted
□ Technical considerations identified
□ Ready to commit

IF NOT PREPARED:
─────────────────────────────────────
Don't plan. Prep first.
Bad planning = failed sprint.
2 hours of prep saves 4 hours in meeting.

Capacity Calculation

CAPACITY BEFORE PLANNING
════════════════════════

CALCULATE AVAILABLE CAPACITY:
─────────────────────────────────────
Sprint: 2 weeks (10 working days)

PERSON AVAILABILITY:
────────────────────────────────────────────────────
Person    Days Out    Days Available    Focus Factor
────────────────────────────────────────────────────
Sarah       0            10               80%
Mike        2 PTO         8               75%
Alex        1 training    9               75%
Emma        0            10               80%
────────────────────────────────────────────────────

CAPACITY CALCULATION:
├── Sarah: 10 × 5.5h × 0.80 = 44h → 11 pts
├── Mike: 8 × 5.5h × 0.75 = 33h → 8 pts
├── Alex: 9 × 5.5h × 0.75 = 37h → 9 pts
├── Emma: 10 × 5.5h × 0.80 = 44h → 11 pts
└── TOTAL: 39 points capacity

WITH BUFFER:
├── Calculated: 39 points
├── Buffer (10%): -4 points
├── Commit to: 35 points
└── Stretch: 35-39 points

The Meeting

Part 1: Goals and Priorities

PLANNING PART 1 (30-45 min)
═══════════════════════════

SPRINT GOAL:
─────────────────────────────────────
PO presents:
"This sprint, our goal is to complete
user authentication so we can begin
user testing next sprint."

Why this matters:
├── User testing blocked without auth
├── Critical path for Q1 release
├── Customer committed demo on [date]
└── Questions?

DISCUSS GOAL:
├── Team understands the why
├── Questions answered
├── Goal refined if needed
├── Everyone aligned on priority

PRIORITY STACK:
─────────────────────────────────────
"To achieve this goal, here are the items
in priority order:

1. GS-100: Login implementation (8 pts)
2. GS-101: Password reset (5 pts)
3. GS-102: OAuth integration (8 pts)
4. GS-103: Session management (5 pts)
5. GS-104: Remember me (3 pts)
------- Sprint goal items above -------
6. GS-105: Security audit (5 pts)
7. GS-106: Bug fixes (4 pts)

We have 35 points capacity.
Items 1-4 = 26 points = goal achievable
Items 5-6 = stretch if capacity allows"

STAKEHOLDER EXIT:
─────────────────────────────────────
After Part 1, stakeholders leave.
Team owns the "how" in Part 2.

Part 2: Detailed Planning

PLANNING PART 2 (60-90 min)
═══════════════════════════

ITEM BY ITEM:
─────────────────────────────────────
For each item:

1. PO PRESENTS CONTEXT
   "GS-100: Login implementation.
   Users enter email/password.
   Acceptance criteria are..."

2. TEAM DISCUSSES APPROACH
   "We'll use JWT tokens"
   "Frontend form + backend validation"
   "Need to integrate with existing user model"

3. TEAM BREAKS DOWN IF NEEDED
   "Let's split this:
   - Backend API (3 pts)
   - Frontend form (3 pts)
   - Integration + testing (2 pts)"

4. TEAM ESTIMATES/CONFIRMS
   "Still 8 points total? Yes."

5. TEAM ASSIGNS (or decides later)
   "Sarah on backend, Mike on frontend"

CONTINUE UNTIL CAPACITY:
├── Work through priority order
├── Track points committed
├── Stop at capacity
├── Don't exceed even for "one more thing"

IDENTIFY DEPENDENCIES:
─────────────────────────────────────
"GS-101 needs GS-100's auth endpoint.
Sarah, can you have that done by Day 3?"

"GS-102 needs OAuth keys from platform team.
We'll follow up today. If not by Day 2, at risk."

Commitment

FINALIZING THE SPRINT
═════════════════════

REVIEW COMMITMENT:
─────────────────────────────────────
Sprint 26 Commitment:
├── Goal: Complete user authentication
├── Capacity: 35 points
├── Committed: 33 points

Items:
├── GS-100: Login (8 pts) - Sarah/Mike
├── GS-101: Password reset (5 pts) - Alex
├── GS-102: OAuth (8 pts) - Sarah
├── GS-103: Session mgmt (5 pts) - Mike
├── GS-104: Remember me (3 pts) - Emma
└── GS-106: Bug fixes (4 pts) - Emma

Stretch (if ahead):
├── GS-105: Security audit (5 pts)

TEAM CONFIRMATION:
─────────────────────────────────────
"Looking at this list, is this achievable
in the next two weeks?"

Each person speaks:
├── Sarah: "Yes, I'm good"
├── Mike: "Concerned about OAuth timing"
├── Alex: "All set"
├── Emma: "Yes"

RESOLVE CONCERNS:
"Mike, what would help with OAuth timing?"
"If we get keys by Day 2, we're fine."
"Let's make that Day 1 action item."

COMMIT:
"We're committing to this sprint. Let's go!"

Common Pitfalls

Avoiding Problems

SPRINT PLANNING PITFALLS
════════════════════════

PITFALL: OVERCOMMITMENT
─────────────────────────────────────
Symptom: Always spilling work to next sprint
Cause: Planning to 100% capacity

Fix:
├── Calculate real capacity
├── Apply focus factor
├── Include buffer
├── Track and improve accuracy
└── Under-promise, over-deliver

PITFALL: VAGUE ITEMS
─────────────────────────────────────
Symptom: "What does this mean?" in planning
Cause: Skipping refinement

Fix:
├── Groom before planning
├── Acceptance criteria required
├── Questions answered in refinement
├── Definition of Ready
└── If not clear, don't commit

PITFALL: NO SPRINT GOAL
─────────────────────────────────────
Symptom: Random assortment of work
Cause: No focus from PO

Fix:
├── Require sprint goal
├── Items connect to goal
├── Trade-offs favor goal items
├── Success = goal achieved
└── Not just "finish X points"

PITFALL: MANAGER ASSIGNS
─────────────────────────────────────
Symptom: Team told what to do
Cause: Top-down culture

Fix:
├── Team pulls work
├── Team self-organizes
├── PO sets priorities (what)
├── Team decides approach (how)
└── Ownership = motivation

GitScrum for Planning

Planning Features

GITSCRUM SPRINT PLANNING
════════════════════════

BACKLOG VIEW:
─────────────────────────────────────
Planning → Backlog
├── Prioritized list
├── Points visible
├── Drag to sprint
├── Running total
└── Capacity indicator

SPRINT CREATION:
─────────────────────────────────────
├── Set sprint dates
├── Define sprint goal
├── Set capacity (manual or calculated)
├── Track committed vs. capacity
└── Start sprint when ready

CAPACITY TRACKING:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────┐
│  Sprint 26                                             │
├─────────────────────────────────────────────────────────┤
│  Goal: Complete user authentication                    │
│                                                         │
│  Capacity: 35 pts                                      │
│  Committed: 33 pts                                     │
│  Buffer: 2 pts (6%)                                    │
│                                                         │
│  ████████████████████████████████░░ 94%                │
│                                                         │
│  Status: ✓ Good commitment level                       │
│                                                         │
└─────────────────────────────────────────────────────────┘

ASSIGNMENTS:
─────────────────────────────────────
In planning:
├── Assign owners to items
├── See workload balance
├── Adjust if uneven
└── Everyone has clear work

Best Practices

For Sprint Planning

1. Groom before planning — 80% prep, 20% planning
2. Set sprint goal — Focus, not feature list
3. Calculate capacity — Realistic availability
4. Team commits — Not manager assigns
5. Timebox ruthlessly — 2-4 hours max

Anti-Patterns

PLANNING MISTAKES:
✗ Ungroomed backlog in planning
✗ No capacity calculation
✗ Always overcommitting
✗ No sprint goal
✗ Manager assigns work
✗ Planning takes all day
✗ Same items every sprint (never done)
✗ No team input on approach

Related Solutions

• Improving sprint planning accuracy
• Planning sprints with accurate capacity
• Creating effective sprint backlogs