Sprint planning
Definition
Sprint planning is a time-boxed Scrum ceremony at the start of each sprint where the team collaborates with the Product Owner to select backlog items, commit to a sprint goal, and define how the work will be done.
Sprint planning opens every sprint. The Scrum Guide caps it at eight hours for a one-month sprint — shorter sprints get proportionally shorter planning sessions, typically one to two hours for a two-week sprint.
The meeting has two distinct parts:
Part 1 — What will we do? The Product Owner presents the highest-priority backlog items. The team asks questions, clarifies acceptance criteria, and selects the items they're confident they can complete by end of sprint. The output is a sprint goal — a concise sentence capturing why this sprint matters.
Part 2 — How will we do it? The team breaks selected stories into tasks, estimates effort (often in hours), and identifies dependencies. This produces the sprint backlog.
Good sprint planning depends on a groomed backlog. Items at the top need clear acceptance criteria before planning starts — teams that skip backlog refinement often spend the first half of sprint planning clarifying what items actually mean.
Planning sessions frequently happen on a whiteboard. Teams draw the sprint goal, map out stories, and sketch dependency flows. That whiteboard becomes the sprint's source of truth — until someone erases it. BoardSnap AI reads the board before it disappears, turning the planning session into a structured sprint backlog ready to load into Jira, Linear, or Notion.
Common failure modes: over-committing (pulling too many points), under-discussing (saying "yes" to items nobody understands), and skipping the sprint goal (leaving the team with a list of tasks but no north star).
Examples
- Team selects eight user stories from the backlog and agrees the sprint goal is 'Ship the onboarding flow to beta users'
- Developers break a user story into five sub-tasks and estimate each in hours
- Product Owner re-prioritizes mid-planning after the team surfaces a technical dependency nobody saw coming
- Remote-hybrid team draws the sprint goal and story map on a whiteboard; BoardSnap captures it for async teammates
- Engineering lead discovers during planning that two stories have a shared dependency and reorders the work
Snap a sprint planning. Ship its actions.
BoardSnap turns any whiteboard — including this one — into a summary and action plan.