Skip to main content

Sprint Planning

Sprint Planning sets the stage for a successful sprint by defining clear goals, selecting achievable work, and ensuring team alignment.

Overview​

Sprint Planning is a collaborative ceremony where the team selects work for the upcoming sprint, breaks it down into tasks, and commits to a sprint goal. The ceremony bridges strategic intent (product backlog priorities) with tactical execution (sprint backlog tasks), translating business needs into executable engineering work.

Effective sprint planning requires balancing competing forces: ambitious enough to deliver value, realistic enough to complete, flexible enough to handle unknowns. Teams that plan too conservatively underdeliver value. Teams that overcommit create stress, cut quality corners, and miss sprint goals. The art lies in finding sustainable pace - a velocity the team can maintain indefinitely without burning out.

Sprint Planning Success

A successful sprint planning results in a clear sprint goal, a realistic commitment, and high team confidence. The team should leave planning knowing exactly what they'll deliver and why it matters. If any team member feels unclear about the sprint direction or doubts the commitment's feasibility, those concerns must be addressed before planning concludes - silent doubt becomes vocal failure mid-sprint.

Core Principles​

  • Goal-Oriented: Every sprint has a clear, achievable goal
  • Capacity-Based: Commitment matches team capacity
  • Collaborative: Entire team participates in planning
  • Realistic: Team commits only to what they can complete
  • Flexible: Plan allows for learning and adjustment

Sprint Planning Structure​

Duration​

  • 2-week sprint: 2 hours
  • 1-week sprint: 1 hour

Participants​

  • Development Team (required)
  • Product Owner (required)
  • Scrum Master (facilitator)

Agenda​

Part 1: Sprint Goal Definition (15 minutes)​

What is a Sprint Goal?​

A sprint goal is a concise statement describing what the team aims to achieve. It provides coherence to the sprint backlog - a unifying purpose that guides trade-off decisions during the sprint. When unexpected issues arise, the sprint goal helps the team decide what to protect versus what to defer.

Good Sprint Goals (outcome-focused, specific, valuable):

  • "Enable customers to schedule future payments" → Clear user capability, measurable completion
  • "Improve payment processing performance by 50%" → Quantifiable improvement, technical focus
  • "Complete OAuth2 authentication integration" → Specific integration, clear completion criteria
  • "Reduce payment failure rate to <1%" → Measurable quality improvement

Bad Sprint Goals (output-focused, vague, unfocused):

  • "Complete 30 story points" → Focuses on velocity metric, not business value
  • "Work on payments" → Too vague, no clear success criteria or direction
  • "Fix bugs and add features" → Lacks coherence, just a collection of unrelated work

A strong sprint goal enables the team to self-organize around a shared objective. When a developer finishes their current task, the sprint goal helps them select the next most valuable work. Without a goal, the sprint becomes a collection of disconnected stories with no narrative thread - completion feels arbitrary rather than purposeful.

Defining the Sprint Goal​

Product Owner Presents:

  • Business context and priorities
  • Key stakeholder needs
  • Success criteria for sprint

Team Discusses:

  • Technical feasibility
  • Dependencies and risks
  • Alignment with product roadmap

Team Agrees:

  • Single, clear sprint goal
  • Success criteria
  • How this aligns with longer-term goals

Part 2: Capacity Planning (10 minutes)​

Calculate Available Capacity​

Capacity planning grounds sprint commitments in reality. Without capacity calculation, teams rely on gut feeling - a recipe for consistent overcommitment. The formula accounts for all the hidden time that erodes development capacity:

Available Capacity = (Team Size × Sprint Days) - Planned Absences - Meetings - Support Work

Example Calculation:

Team: 5 developers
Sprint: 10 working days
Planned absences: 2 days (1 developer on vacation)
Meetings/Ceremonies: 0.5 days per developer (standups, planning, review, retro, refinement)
Support/BAU: 1 day per developer (production support, code reviews, helping other teams)

Available Capacity = (5 × 10) - 2 - (5 × 0.5) - (5 × 1)
                   = 50 - 2 - 2.5 - 5
                   = 40.5 developer-days

This reveals a critical insight: only 81% of theoretical capacity is actually available for sprint work (40.5 / 50). New teams often ignore these "overhead" hours and wonder why they consistently deliver only 60-70% of committed work. The problem isn't execution - it's unrealistic planning that ignores reality.

Velocity Considerations​

Velocity measures the team's historical output, providing an empirical basis for commitment. It answers "Based on past performance, how much work can we realistically complete?" Velocity isn't a performance metric to maximize - it's a planning tool for sustainable delivery.

Historical Velocity:

  • Review last 3 sprints' completed story points (not committed, but actually completed)
  • Calculate average velocity to smooth outlier sprints
  • Identify trends (increasing/decreasing) that might indicate systemic changes
  • Recognize that velocity is team-specific - comparing velocities across teams is meaningless due to different estimation calibration

Adjustment Factors:

Teams must adjust raw velocity for sprint-specific circumstances that differ from historical context:

  • New team members (reduce capacity by 20-30%): Onboarding consumes experienced team members' time through pairing, code reviews, and knowledge transfer. The new member contributes minimal output initially while creating overhead.
  • Technical debt work (reserve 10-20% capacity): Refactoring and architecture improvements rarely deliver user-visible stories but require capacity. Explicitly budget this work rather than letting it squeeze story completion.
  • Known risks or unknowns (add buffer): If the sprint involves unfamiliar technologies, complex integrations, or dependency on external teams, reduce planned velocity to account for learning curves and coordination overhead.
  • Holiday periods (reduce capacity): Major holidays reduce available working days. Account for this in capacity calculation - don't pretend December sprints deliver the same velocity as March sprints.

Example Calculation:

Last 3 sprints: 28, 32, 30 story points
Average velocity: 30 story points

Adjustments:
- New team member: -20% = -6 points
- Technical debt sprint: -10% = -3 points

Sprint commitment target: 30 - 6 - 3 = 21 story points

Part 3: Story Selection (60 minutes)​

Selection Process​

1. Start with Highest Priority

Product Owner presents top priority stories in order
Team discusses each story:
- Acceptance criteria clear?
- Dependencies identified?
- Risks understood?
- Estimate still accurate?

2. Assess Against Sprint Goal

For each story, ask:
- Does this contribute to sprint goal?
- Is it essential for sprint success?
- Can it wait for next sprint?

3. Check Capacity

Running total of story points
Compare to available capacity
Stop when capacity reached

4. Add Buffer

Reserve 10-20% capacity for:
- Unexpected issues
- Code review time
- Bug fixes
- Support requests

Story Breakdown​

For large stories (>5 points), break down further:

Payment Scheduling Story (8 points):

Original: "As a user, I want to schedule future payments"

Break down into:
- Backend API for scheduled payments (3 points)
- Database schema for scheduled jobs (2 points)
- Frontend UI for date selection (2 points)
- Background job processor (3 points)
- Email notifications (2 points)

Total: 12 points (larger than estimate - needs discussion)

Handling Dependencies​

Identify Dependencies:

  • External team dependencies
  • Infrastructure dependencies
  • Third-party service dependencies
  • Waiting on stakeholder input

Mitigate Risks:

  • Front-load dependent stories
  • Have backup stories ready
  • Communicate dependencies early
  • Escalate blockers immediately

Part 4: Task Breakdown (20 minutes)​

Breaking Stories into Tasks​

For each committed story, identify specific tasks:

Example: Payment API Story (5 points):

Tasks:
1. Create Payment entity and repository (2 hours)
2. Implement PaymentService with validation (4 hours)
3. Create REST controller with endpoints (2 hours)
4. Write unit tests for service layer (3 hours)
5. Write integration tests with TestContainers (4 hours)
6. Update OpenAPI specification (1 hour)
7. Code review and fixes (2 hours)
8. Update documentation (1 hour)

Total estimate: 19 hours (~2.5 days)

Task Estimation Guidelines​

Time Estimates:

  • Use hours for tasks (not story points)
  • Tasks should be 2-8 hours max
  • If >8 hours, break down further

Include All Work:

  • Development
  • Testing (unit, integration, contract)
  • Code review time
  • Documentation
  • Bug fixes

Who Estimates:

  • Developer who will do the work
  • Others provide input
  • Team validates estimates

Part 5: Sprint Commitment (10 minutes)​

Confirm Commitment​

Team Votes:

Fist of Five voting:
5 fingers = Highly confident
4 fingers = Confident
3 fingers = Somewhat confident (discuss concerns)
2 fingers = Not confident (identify risks)
1 finger = Cannot commit (major issues)

If Confidence Low:

  • Identify specific concerns
  • Remove stories if needed
  • Adjust scope
  • Re-vote

Document Commitment:

  • Sprint goal
  • Committed stories
  • Total story points
  • Key risks and mitigations

Sprint Planning Output​

Documented in Jira:

  • Sprint created with dates
  • Stories moved to sprint
  • Sprint goal visible
  • Tasks created and assigned

Communicated:

  • Sprint goal shared with stakeholders
  • Risks escalated
  • Dependencies flagged
  • Team aligned on priorities

Best Practices​

Preparation is Critical​

Product Owner Preparation:

  • Backlog prioritized
  • Top stories refined and estimated
  • Sprint goal drafted
  • Stakeholder priorities clarified
  • Dependencies identified

Development Team Preparation:

  • Review upcoming stories beforehand
  • Research technical approaches
  • Identify questions for Product Owner
  • Review velocity and capacity

Keep It Focused​

Timebox Discussions:

  • Use timer for each story discussion
  • Park detailed technical conversations
  • Follow up on specifics after planning

Parking Lot:

  • Capture off-topic items
  • Schedule follow-up discussions
  • Don't derail planning

Realistic Commitments​

Don't Overcommit:

Bad: "We can definitely do 40 points!" (historical velocity: 28)
Good: "Based on our velocity and capacity, we'll commit to 25 points"

Include Buffer:

  • 10-20% buffer for unknowns
  • Reserve capacity for code review
  • Account for support work

Be Honest About Capacity:

  • Account for all planned absences
  • Include meeting time
  • Consider team experience

Common Anti-Patterns​

Status Quo Planning​

Problem: Planning based on previous sprint without reassessing Solution: Evaluate capacity fresh each sprint

Gold Plating​

Problem: Adding nice-to-have features to stories during planning Solution: Stick to acceptance criteria, defer enhancements

Over-Tasking​

Problem: Breaking every story into 20+ tiny tasks Solution: Task breakdown should be helpful, not bureaucratic

No Sprint Goal​

Problem: Sprint is just a collection of unrelated stories Solution: Define clear goal that unifies the work

Passive Participation​

Problem: Only Scrum Master and Product Owner talking Solution: Ensure all developers actively participate

Sprint Planning Checklist​

Before Sprint Planning​

  • Backlog prioritized and refined
  • Top stories estimated
  • Team capacity calculated
  • Sprint goal drafted
  • Previous sprint reviewed
  • Dependencies identified
  • Demo environment ready

During Sprint Planning​

  • Sprint goal agreed upon
  • Team capacity reviewed
  • Stories selected based on priority
  • Story points sum matches capacity
  • Dependencies documented
  • Risks identified and mitigated
  • Stories broken into tasks
  • Team confidence level high (3+)
  • Commitment documented in Jira

After Sprint Planning​

  • Sprint goal visible in Jira
  • Stories in sprint backlog
  • Tasks created and assigned
  • Stakeholders informed
  • Dependencies communicated
  • Risks escalated

Further Reading​

Summary​

Key Takeaways:

  1. Clear Sprint Goal: Define specific, achievable goal that guides story selection
  2. Capacity Planning: Calculate realistic capacity accounting for absences and overhead
  3. Collaborative Selection: Team selects stories based on priority and capacity
  4. Task Breakdown: Break stories into concrete tasks with hour estimates
  5. Team Commitment: Ensure high team confidence through Fist of Five voting
  6. Buffer Included: Reserve 10-20% capacity for unknowns and code review
  7. Preparation Required: Product Owner and team must prepare beforehand
  8. Document Thoroughly: Capture sprint goal, commitment, and risks in Jira