GuideRolesEventsWorkflow

Scrum Events

Sprint Planning

Sprint Planning initiates the Sprint by defining the why, what, and how. The entire Scrum Team collaborates to set a Sprint Goal, select Product Backlog items, and create a plan for delivering them. This is where the team aligns on purpose and commits to a shared objective.

Initiating the Sprint · Timebox: ≤ 8 hours (1-month Sprint)

Overview

Sprint Planning initiates the Sprint by defining the why, what, and how. The entire Scrum Team collaborates to set a Sprint Goal, select Product Backlog items, and create a plan for delivering them. This is where the team aligns on purpose and commits to a shared objective.

Event Ownership

Owned / Facilitated By
Scrum Master (facilitator) / Product Owner (content driver)
Scrum Master facilitates the event, guards the timebox, and coaches the team through the process
Product Owner comes prepared with a refined, ordered Product Backlog and a proposed Sprint Goal
Product Owner explains how the Sprint can best contribute to the Product Goal
Scrum Master ensures all three topics (Why, What, How) are addressed

Who Should Be Present

Product Owner
Proposes the Sprint Goal, explains top backlog items, clarifies acceptance criteria, and negotiates scope with Developers
Developers
Select items they can commit to, decompose them into tasks, estimate effort, and create the delivery plan
Scrum Master
Facilitates the session, ensures productive collaboration, coaches on estimation techniques, and guards the timebox
Subject Matter Experts
May be invited by the Scrum Team to provide technical or domain advice on specific backlog items

Preparation Checklist

01Product Owner: Backlog refined, ordered, and top items have clear acceptance criteria
02Product Owner: Draft Sprint Goal prepared that connects to the Product Goal
03Developers: Review velocity data, upcoming capacity (PTO, on-call), and previous Sprint’s retrospective commitments
04Scrum Master: Prepare facilitation materials — timers, voting tools, capacity worksheets
05Team: Review the Definition of Done and any changes from the last Retrospective

Facilitation Techniques

Click any technique to expand details and learn when to apply it.

Three-Topic Structure (Why → What → How)

Structure the session around the Scrum Guide’s three questions. Start with Why (Sprint Goal), then What (item selection), then How (task decomposition). This prevents the team from jumping into task details before aligning on purpose.

Click to expand

Roman Voting / Fist-of-Five

After defining the Sprint Goal, ask each team member to vote their confidence level (1–5 fingers). Low scores surface hidden concerns. Discuss any votes below 3 before proceeding.

Click to expand

Planning Poker / T-Shirt Sizing

Use relative estimation techniques for sizing items. Planning Poker uses numbered cards for consensus; T-Shirt sizing (XS–XL) is faster for initial rough estimates. Both prevent anchoring bias.

Click to expand

Silent Brainstorming for Task Decomposition

Give Developers 5–10 minutes of silent time to individually decompose selected items into tasks on sticky notes. Then merge and discuss. This prevents the loudest voices from dominating the plan.

Click to expand

Capacity-Based Forecasting

Calculate actual available hours per team member (subtract PTO, meetings, on-call, retro commitments). Compare against historical velocity. This grounds the forecast in reality rather than optimism.

Click to expand

Sprint Goal Workshop

Instead of the PO dictating the Sprint Goal, run a brief workshop: PO shares the product direction, then the team collaboratively drafts the Sprint Goal using powerful questions like ‘What is the single most important outcome this Sprint?’

Click to expand

Tips & Tricks

01
The Sprint Goal should be outcome-oriented, not a list of features — ‘Enable users to complete checkout’ not ‘Build cart page, payment API, and receipt email’
02
If Developers cannot explain the Sprint Goal in their own words, it isn’t clear enough
03
Don’t over-plan the How — decompose the first few days in detail, plan the rest at a higher level
04
Include retrospective commitments in Sprint capacity — if the team agreed to pair-program more, that costs time
05
If the Product Backlog isn’t ready, Sprint Planning will be painful — refinement is the real fix
06
End by reading the Sprint Goal aloud and doing a final confidence vote

Success Takeaways by Role

What each participant should walk away with when this event is run well.

Developers

A clear plan they created themselves; confidence they can deliver the Sprint Goal; understanding of each item’s requirements

Product Owner

Confidence the team understands what’s needed and why; alignment between business value and technical capacity

Scrum Master

A well-facilitated start with high team energy; identified any knowledge gaps or risks early

Stakeholders

Clarity on what the team aims to deliver this Sprint and why it matters to the product

Cross-Framework Definition
See Sprint Planning in the glossary
→