Sprint goal
A single sentence stating what the team commits to delivering by the end of the sprint. Write it large, at the top. Every backlog item you pull in should connect to this goal — if it doesn't, it doesn't belong in the sprint.
Free template
Free sprint planning template — whiteboard to sprint in one session.
Define the sprint goal, pull the backlog items, break them into tasks, and check capacity — all on one board. Snap it when you're done and BoardSnap ships the action plan.
Download on the
App Store
Free to start. Pro from $9.99/mo or $69.99/yr.
When to run this
Run sprint planning at the start of every sprint — the first day of the new cycle, immediately after (or the morning after) the previous sprint's retro while context is still fresh.
For a two-week sprint, budget 2–4 hours. Shorter sprints need less time. The most common mistake is trying to plan on an empty stomach for the backlog — make sure the product owner has groomed and prioritized the top stories before the room fills up.
The structure
Candidate backlog items
Stories pulled from the top of the groomed backlog, ordered by priority. Each story has an acceptance criterion and a rough estimate. This column is the raw material — not everything here makes it into the sprint commitment.
Sprint commitment
The subset of backlog items the team is actually committing to complete. Pulled left-to-right based on capacity. If the total estimated effort exceeds capacity, items go back to the backlog — not into the sprint under-estimated.
Task breakdown
Each committed story broken into specific engineering tasks. One sticky per task, estimated in hours (not story points). This column is where engineers discover hidden complexity — that's the point.
Capacity check
Available developer-days this sprint, accounting for PTO, meetings, and on-call. Compare against the sum of task estimates. If they don't match, negotiate scope before the sprint starts — not halfway through.
How to run it
- State the sprint goal (10 min)
The product owner proposes the sprint goal. The team debates until everyone can commit to it. Write it at the top of the board before touching the backlog — the goal is the filter for everything that follows.
- Walk the backlog (20 min)
The PO walks the top stories: what the feature does, why it matters, acceptance criteria. Engineers ask clarifying questions. Refine estimates if needed. No task breakdown yet — that comes after selection.
- Select and commit (20 min)
Pull stories from 'candidate' to 'commitment' until you hit capacity. When in doubt, pull less — a sprint where you complete everything is better than one where you scramble and ship half.
- Break down into tasks (30 min)
Engineers self-organize to decompose each committed story into hour-level tasks. Write one sticky per task; post under the parent story. Surface hidden dependencies and external blockers now.
- Check capacity (10 min)
Sum the task estimates. Compare to available hours. If you're over, negotiate scope with the PO — drop the lowest-priority story, not tasks from existing stories.
- Snap and ship the plan
Snap the board with BoardSnap before you leave the room. The AI reads the sprint goal, committed stories, and tasks — and outputs a structured plan with action items ready to import into your project management tool.
Why sprint plannings on a whiteboard + BoardSnap is better than digital
Sprint planning on a physical board forces the whole team to look at the same surface at the same time. There's no 'share screen' lag, no one typing in a corner of Jira while the discussion happens elsewhere. The board is the single source of truth for the 2–4 hours you're in the room.
The problem is always what happens after the room empties. Task stickies fall off, photos get buried in a camera roll, and the sprint starts without a clean artifact. BoardSnap solves the capture problem: one snap reads every sticky — stories, tasks, estimates, the sprint goal — and ships a structured plan that travels directly into Linear, Jira, or Notion.
Frequently asked
How much of the sprint should we plan in detail during planning?
Plan the entire sprint at the story level and the first few days at the task level. Don't try to decompose everything in one session — stories two weeks out will change. Plan enough to start, and use daily standups to break down upcoming work as you go.
What if the team can't agree on estimates?
Use planning poker or a quick dot-vote on the range. If two engineers are far apart, ask each to explain their thinking — you'll discover a hidden assumption or dependency that changes the estimate. Don't average; resolve the disagreement.
How do you handle a story that doesn't fit in a single sprint?
Split it. A story that takes more than half a sprint should be broken into independently shippable pieces. If you can't split it, treat it as an epic and plan the first shippable slice.
Should the sprint planning board stay up during the sprint?
Yes — or a derivative of it. Many teams evolve the planning board into the sprint board by moving tasks to a Kanban-style layout. Snap the planning board before you rearrange it so the original plan is preserved.
Run your next sprint planning and BoardSnap will summarize it.
No exporting, no transcription. Snap the board, get the action plan.
Free · 1 project, 30 boards
Pro $9.99/mo · everything unlimited
Pro $69.99/yr · save 42%