Brand
Get all logo versions.
Download 
Sprint planning is the scrum ceremony where a team decides what it will deliver in the next sprint and how. This template covers both halves of that decision: an effort-versus-impact frame for choosing which backlog items deserve the sprint, and a sprint progress board (Backlog, To Do, In Progress, Review, Done) with a color-coded tag key for running it. Scrum teams use it to plan the sprint and track it on one board.
They blur together in practice, but they answer different questions on different clocks. Refinement is the ongoing housekeeping: splitting oversized stories, estimating, sharpening acceptance criteria, a little every week. Sprint planning is the boundary event: from this refined list, what do we commit to for the next two weeks, and to what goal? Refinement makes items ready; planning makes them promised. Do the first continuously and the second stays short.
Sprint planning is the scrum event that starts each sprint: the team reviews the refined backlog, agrees a sprint goal, and selects the items it can deliver, breaking them into tasks. The Scrum Guide frames it as three questions: why this sprint (the goal), what fits (the backlog selection), and how it'll get done (the task plan). Product owner, scrum master, and developers all attend.
The standard timebox is two hours per week of sprint: four hours for a two-week sprint, eight for a month. Most teams finish faster when the backlog arrives refined; most teams that blow the timebox are doing refinement in the room. If planning regularly runs long, the fix is usually a mid-sprint refinement session, not a longer meeting.
Refinement prepares; planning commits. Backlog refinement happens continuously during the sprint: splitting big items, estimating, clarifying acceptance criteria, reordering. Sprint planning is the formal event at the sprint boundary where the team selects from that prepared backlog and commits to a goal. Teams that skip refinement end up doing it inside planning, which is why their planning meetings hurt.
In: a refined product backlog, the team's velocity (the rolling average of recent sprints), real capacity for this sprint (people, minus leave and meetings), and the definition of done. Out: a sprint goal in one or two sentences, and a sprint backlog, the selected items broken into tasks with owners. If any input is missing, the output is a guess.
Overcommitting, and it's rarely malicious: the backlog items all look important, capacity feels bigger than it is, and nobody wants to be the one saying less. The effort/impact grid in this template is the antidote; when every candidate is placed against effort, the sprint's real size becomes visible before the commitment, not at the retro. A sprint goal that survives contact with week two is the win.