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.