What is Sprint Planning?
Sprint Planning
Sprint planning is the meeting where a team selects backlog items, agrees on a sprint goal, and commits to what it can realistically deliver in the sprint ahead.
Sprint planning is the meeting held at the start of every sprint, where the team decides exactly what it will work on and agrees to a sprint goal it believes it can hit. It's a single meeting with two distinct halves: deciding what to build, then deciding how to build it, and it produces a specific set of outputs the team refers back to for the rest of the sprint.
The Scrum Guide caps sprint planning at 8 hours for a 4-week sprint, scaling down roughly in proportion to sprint length. In practice, most agency and product teams running 1 to 2 week sprints finish planning in 1 to 2 hours, well under the cap, once the backlog arriving at the meeting is already in reasonable shape.
This entry covers the meeting itself, not the sprint it kicks off. For how sprints work end to end, see the sprint entry; for the framework sprint planning belongs to, see Scrum.
Who Attends Sprint Planning
Three roles need to be in the room, or the meeting produces a plan that doesn't hold up once the sprint starts.
- Product Owner: brings the prioritized backlog, answers scope questions in real time, and confirms the priority order still holds
- Scrum Master or facilitator: keeps the meeting inside its time box and resolves disagreements about what fits
- The delivery team: the people doing the work, since they're the ones committing their own capacity, not someone committing it on their behalf
- A stakeholder or client: optional here, unlike the sprint review, where their presence is the point
How Long Sprint Planning Should Take
A useful rule of thumb, drawn from the Scrum Guide's 8-hour cap on a 4-week sprint, is roughly 1 hour of planning per week of sprint length. That's a ceiling, not a target.
| Sprint length | Recommended planning time | Typical for agency teams |
|---|---|---|
| 1 week | Up to 1 hour | 30 to 45 minutes |
| 2 weeks | Up to 2 hours | 1 to 2 hours |
| 3 weeks | Up to 3 hours | 2 to 2.5 hours |
| 4 weeks | Up to 4 to 8 hours | 3 to 4 hours |
The Two-Part Structure: What and How
Sprint planning splits into two parts with different questions and, often, different people driving the conversation.
Part one answers what: the Product Owner presents the top of the backlog in priority order, the team checks each item against remaining capacity, and the group agrees on a sprint goal, one sentence describing the outcome the sprint is meant to deliver. Items get pulled in from the top of the list until the team's capacity is spoken for.
Part two answers how: for each item pulled into the sprint, the team breaks it into concrete tasks, assigns or claims owners, and flags dependencies that could block the work. A story with no task breakdown by the end of part two usually means nobody has thought through how to build it, which shows up as a surprise mid-sprint instead of a known risk on day one.
What Needs to Be Ready Before the Meeting Starts
Sprint planning runs fast when the inputs are ready and drags for hours when they aren't. The backlog should already be refined, a separate, earlier session where the Product Owner clarifies and roughly estimates upcoming items, not something worked out live in the planning meeting itself.
- A refined backlog: the top 15 to 20 items already clarified and roughly sized before the meeting begins
- Known team capacity: available hours per person for the sprint, adjusted for time off and recurring meetings
- A written Definition of Done that the whole team already agrees on
- Carryover from the previous sprint reviewed and re-prioritized, not silently dropped back into the same slot
What Comes Out of Sprint Planning
A planning session that ends without these artifacts hasn't finished, regardless of how long the meeting ran.
- The sprint backlog: the specific, committed list of items for this sprint
- A one-sentence sprint goal that states the outcome, not a list of tasks
- Task-level breakdown with an owner on each task
- An updated capacity tracker showing what's left, not only what's assigned
- A short list of open dependencies or risks, handed to the Scrum Master to chase down in the first 48 hours
Estimation Techniques Used in Sprint Planning
Teams estimate the items pulled into the sprint using one of a few common methods. None is objectively correct; the right choice depends on how much estimation history the team has built up.
| Technique | How it works | Best for |
|---|---|---|
| Story points (planning poker) | Team votes relative size on a Fibonacci-like scale, discusses gaps, revotes | Teams with 3+ months of estimation history to calibrate against |
| T-shirt sizing | Items sorted into S, M, L, XL buckets, fast and rough | Early-stage backlogs, quick relative sorting |
| Hours | Direct estimate in working hours per task | Small or new teams without enough history for story points to mean anything yet |
Sprint Planning in Practice: A 10-Person Team Agenda
Voss & Ito, a 10-person product studio, runs a 90-minute sprint planning session every other Monday for a 2-week sprint. The agenda is fixed and posted in the meeting invite, so nobody wonders what's coming next.
Minutes 0 to 10: the Product Owner recaps last sprint's completion rate and states the proposed goal for this sprint in one sentence.
Minutes 10 to 40: the team walks the top of the backlog in priority order, asking one question per item, does this fit inside our remaining capacity, and pulling items in until the answer is no. Capacity for this team, after time off and meetings, runs at 340 hours across 10 people for the sprint.
Minutes 40 to 75: part two. Each pulled item gets broken into tasks on the board, with an owner claiming each one live in the meeting, not assigned afterward by the PM.
Minutes 75 to 90: a final capacity check, comparing total task hours against the 340-hour budget, and a read-aloud of the sprint goal to confirm everyone leaves with the same understanding of what this sprint is for.
- 90-minute fixed agenda, posted in advance, same structure every sprint
- Capacity for this sprint: 340 hours across 10 people
- Task ownership claimed live in the meeting, not assigned afterward
- Meeting ends with a capacity check and the sprint goal read aloud
Running Sprint Planning with Melororium
Teams run sprint planning against a live Kanban board in Melororium rather than a separate planning tool. Backlog items sit in a dedicated column, pulled into the sprint column as the meeting works through part one, then broken into subtasks with an owner and an hour estimate for part two.
The Team module's workload view shows each person's remaining hours in real time as tasks get assigned, so a team catches an overcommitted sprint during the meeting instead of on day 6. Time logged against each task compares directly to the original estimate in Work Reports once the sprint is underway.
Available in every plan starting at $29/mo for 4 users.
In Melororium
Run sprint planning on Melororium's boards
Common mistakes with sprint planning
What teams get wrong most often, and what to do instead.
- 1
Estimating during the meeting instead of before it
Walking into planning with an unrefined backlog, so the first half of the meeting gets spent clarifying requirements that should have been settled the week before.
- 2
Skipping part two, the task breakdown
Agreeing on a list of backlog items and calling the meeting done, without breaking anything into tasks or owners, so day one of the sprint starts with everyone unsure what to pick up.
- 3
Letting the loudest voice set the sprint goal
A manager or stakeholder dictating the sprint goal instead of the delivery team, who know their own capacity, agreeing to it together.
- 4
No running total of capacity as items get pulled in
Adding items to the sprint one at a time without tracking a subtotal against available hours, so the meeting ends with a sprint that's quietly 30% over capacity before anyone notices.
Frequently asked questions
Is sprint planning the same as backlog refinement?
No. Backlog refinement happens earlier, usually the week before, and prepares the backlog: clarifying items, rough sizing, splitting anything too large. Sprint planning commits to what refinement already prepared.
Can sprint planning happen without the Product Owner?
It shouldn't. Without the Product Owner, the team is guessing at priority order and scope, and decisions made in that meeting often get reversed once the Product Owner sees what got committed.
What happens if the team disagrees on what fits in the sprint?
The team, not the Product Owner or a manager, has final say on how much it commits to, since they're the ones doing the work. Disagreement usually means the capacity check needs another look before anything gets added.
Does sprint planning happen for Kanban teams too?
Not in the same form. Kanban has no fixed sprints, so there's no equivalent commitment meeting, work enters the board as capacity opens up. Teams running a Kanban board with sprint-style planning layered on top are usually using a Scrumban hybrid.
How does Melororium support sprint planning?
Teams run planning directly against a live Kanban board: pull items from a backlog column into the sprint, break them into subtasks with owners and hour estimates, and check remaining team capacity in the Team module's workload view before the meeting ends.
