Sprint Planning

Purpose

Sprint Planning kicks off every Sprint by answering two questions: *What can we deliver?* and *How will we do the work?* The ceremony aligns the team around a shared Sprint Goal, selects Product Backlog items that support it, and produces a Sprint Backlog the developers feel confident they can complete within the time-box.

At a glance

How to run

1. Set the stage (10 min) — The Product Owner presents the proposed Sprint Goal and the highest-ordered Backlog items. Share any relevant velocity data or capacity constraints.
2. Select items (30 min) — The team discusses each candidate item, asks clarifying questions, and forecasts how many items fit the Sprint. Use historical velocity or gut-feel; do not force commitment.
3. Craft the Sprint Goal (10 min) — Collaboratively write a single sentence that captures the coherent objective. Every selected item should contribute to this goal.
4. Task breakdown (50 min) — Developers decompose selected items into tasks of roughly one day or less. Identify dependencies and flag unknowns.
5. Confidence check (10 min) — Ask the team: "On a fist-of-five, how confident are you we can meet this Sprint Goal?" If below 3, adjust scope.
6. Close (10 min) — Confirm the Sprint Goal, the Sprint Backlog, and any logistics (days off, meetings, pairing needs).

Materials needed

• Product Backlog (refined and ordered)
• Sprint board (physical or digital — Jira, Azure DevOps, Miro)
• Velocity chart or throughput data from previous Sprints
• Team capacity calendar
• Timer

Pitfalls & common mistakes

• Skipping the Sprint Goal — Without a goal the Sprint becomes a disconnected to-do list and the team loses focus.
• Product Owner dictates scope — Planning is a negotiation; developers must own the forecast.
• Over-committing — Teams pad the Sprint to look productive, then carry over half the items. Use data, not optimism.
• No task breakdown — Jumping straight into coding without decomposition leads to hidden complexity surprises mid-Sprint.
• Going over time — If planning regularly exceeds the time-box, the root cause is usually poor Backlog refinement upstream.

Inclusion & accessibility

• Share the candidate Backlog items 24 hours before so introverts and non-native speakers can prepare.
• Use a visible timer and structured rounds so dominant voices do not monopolize.
• Provide the Sprint Goal in writing, not just verbally.
• For remote teams, ensure captions are on and use a shared digital board everyone can edit simultaneously.

Variations

• Two-part planning — Part 1 focuses on the "What" (goal + items), Part 2 on the "How" (task breakdown). Useful for larger teams.
• Async pre-planning — Developers review and ask questions on Backlog items asynchronously before the meeting, reducing live time to 60–90 min.
• Sprint Planning with estimation — Combine with card-based estimation if items have not been estimated during refinement.

When NOT to use this

• If you run a continuous-flow Kanban system without fixed iterations — use Kanban Replenishment instead.
• If the team has fewer than two weeks of refined Backlog items — run Backlog Refinement first.
• If the organisation has not empowered the team to self-select work — the ceremony becomes theatre.

Source & further reading

• Schwaber, K. & Sutherland, J. (2020). *The Scrum Guide*. scrumguides.org
• Cohn, M. (2005). *Agile Estimating and Planning*. Prentice Hall.
• Rubin, K. (2012). *Essential Scrum*. Addison-Wesley.