Agile Sprint Planning

Table of Contents

• [Overview](#overview)
• [When to Use](#when-to-use)
• [Quick Start](#quick-start)
• [Reference Guides](#reference-guides)
• [Best Practices](#best-practices)

Overview

Agile sprint planning provides a structured approach to organize work into time-boxed iterations, enabling teams to deliver value incrementally while maintaining flexibility and responding to change.

When to Use

• Starting a new sprint cycle
• Defining sprint goals and objectives
• Estimating user stories and tasks
• Managing sprint backlog prioritization
• Handling mid-sprint changes or scope adjustments
• Preparing sprint reviews and retrospectives
• Training team members on Agile practices

Quick Start

Minimal working example:

# Sprint Planning Checklist

## 1-2 Days Before Planning Meeting

- [ ] Groom product backlog (ensure top items are detailed)
- [ ] Update user story acceptance criteria
- [ ] Identify dependencies and blockers
- [ ] Prepare estimates from previous sprints
- [ ] Review team velocity (average story points per sprint)
- [ ] Identify team availability/absences
- [ ] Prepare sprint goals draft

## Information to Gather

- Product Owner priorities
- Team capacity (working hours available)
- Previous sprint metrics
- Upcoming holidays or interruptions
- Technical debt items to address

Reference Guides

Detailed implementations in the references/ directory:

Best Practices

✅ DO

• Base capacity on actual team velocity from past sprints
• Include buffer time for interruptions and support work
• Focus sprint goal on business value, not technical tasks
• Timeboxe planning meeting (2 hours max for 2-week sprint)
• Include entire team in planning discussion
• Break down large stories into smaller, manageable pieces
• Track story points for velocity trending
• Review and adjust estimates based on actual completion
• Maintain consistent sprint length
• Include retrospective improvements in planning

❌ DON'T

• Plan for 100% capacity utilization
• Skip story grooming before planning meeting
• Add stories after sprint starts (unless emergency)
• Let one person estimate for entire team
• Use story points as employee performance metrics
• Ignore team velocity trends
• Plan without clear sprint goal
• Force stories into sprints to match capacity numbers
• Skip sprint planning to save time
• Use planning poker results as final estimate without discussion