Ask ten people what a scrum master does in sprint planning and you’ll get ten answers, several of them wrong. The most common wrong one: “they run the meeting and tell everyone what to work on.” That’s almost the opposite of the job.
A scrum master is a facilitator, not a foreman. In planning, that distinction shows up in everything they do. Here’s what the role actually looks like when it’s done well.
The one-line version
The scrum master’s job in sprint planning is to make a good plan possible without making the plan themselves. They set the conditions — a refined backlog, a time-boxed meeting, honest capacity numbers, a clear goal — and then they get out of the way so the team can commit to work it genuinely believes it can finish.
If you remember nothing else: they facilitate the decision; they don’t own it.
Before the meeting: the unglamorous part
Most of a scrum master’s planning impact happens before anyone sits down. A meeting only goes well if the prep was done, and the prep is largely on them to drive.
- Make sure the backlog is refined. The top items should be estimated, clarified, and free of open questions. If they’re not, the scrum master nudges the product owner and team to refine before planning, not during it.
- Get capacity numbers ready. Who’s out? Whose on-call this sprint? Is there a holiday? Walking in without this means the team plans against fantasy numbers. (We break down the actual math in how to calculate team capacity for a sprint.)
- Confirm there’s a draft sprint goal. That’s the product owner’s to propose, but the scrum master makes sure it exists so the meeting has a north star.
- Time-box the agenda. Decide how long planning gets and protect it.
Honestly, this is where the best scrum masters earn their keep. A team that shows up to a prepared meeting finishes in 45 minutes. A team that shows up to an unprepared one is still arguing about acceptance criteria at hour three.
During the meeting: facilitate, don’t dominate
Once planning starts, the scrum master’s role shifts to keeping things moving and keeping them honest. A few specific jobs:
Keep it time-boxed
Planning has a natural tendency to sprawl. One story sparks a 20-minute architecture debate that should’ve been a separate conversation. The scrum master catches that — “let’s park that and take it offline” — and keeps the meeting on its rails. Protecting the time-box is protecting everyone’s afternoon.
Draw out estimates without anchoring
When the team estimates, the scrum master facilitates so that the loudest or most senior voice doesn’t set the number for everyone. This is the whole reason planning poker exists: everyone reveals their estimate at the same time, so nobody anchors. When votes diverge — say someone votes a 2 and someone else a 13 — that gap is gold. The scrum master gets both to explain, because the disagreement almost always reveals a hidden assumption or an unclear requirement. Then the team re-votes.
The scrum master never just declares the number. The moment they do, estimation stops being the team’s and the ownership evaporates.
Surface dependencies and risks
“Does this depend on the API work?” “Is anyone blocked waiting on design?” The scrum master keeps asking the questions that surface dependencies before they become mid-sprint surprises. In Jira, that means actually looking at blocks and blocked-by links during planning, not discovering them on day four.
Protect the team from over-commitment
This is the big one, and it takes a spine. There’s almost always pressure — sometimes from the product owner, sometimes from the team’s own optimism — to cram in more than capacity allows. The scrum master is the person who says, “We have 234 available hours and you’re about to commit to 300. Which of these are we actually doing?”
That’s not being a pessimist. It’s the single most valuable thing a scrum master does in planning, because a team that consistently over-commits stops trusting its own plans — and so does everyone watching.
What the scrum master does not do
It’s worth being blunt about the boundaries, because crossing them is the most common way the role goes wrong:
- They don’t assign tasks. The team self-organizes and decides who takes what.
- They don’t set the scope or priority. That’s the product owner.
- They don’t commit the team. The team commits itself, based on capacity it believes in.
- They don’t act as a manager. No performance authority, no directing the work. They serve the team.
A scrum master who assigns work and dictates scope isn’t a scrum master — they’re a project manager wearing a different hat, and the team will feel the difference fast.
After the meeting: close the loop
When planning wraps, the scrum master makes sure a few things are true: the sprint goal is written down and everyone can repeat it, every committed item has an owner and an estimate, and the committed load actually fits capacity with a buffer left over. If something’s off, better to catch it now than in the standup on day two.
Where the tooling helps
A lot of what a scrum master does in planning is making reality visible — capacity, dependencies, who’s over-committed. In plain Jira that’s harder than it should be, because Jira doesn’t model PTO or overhead, and dependencies are buried a click away on each issue. So scrum masters end up juggling a spreadsheet and a dozen tabs to facilitate a single meeting.
That’s the friction Ekko is meant to remove. It puts capacity (with time off and overhead already subtracted) right next to the plan, surfaces each task’s linked and blocking issues in one panel, and runs sprint poker inside the planning view so estimates write straight back to Jira. The scrum master spends the meeting facilitating the conversation instead of refereeing tools. None of it replaces the human judgment — it just clears the busywork out of the way so there’s room for it.
The mindset, in the end
The best scrum masters in planning are almost invisible. The meeting just… works. It starts on time, the estimates are honest, the over-commitment gets caught, the goal is clear, and everyone leaves owning a plan they believe in. That smoothness isn’t an accident — it’s a facilitator doing a lot of quiet, deliberate work so the team can do its job. Serve the team, protect the process, and resist every urge to grab the wheel. That’s the whole game.
Frequently asked questions
- Does the scrum master assign tasks in sprint planning?
- No. In Scrum, the development team self-organizes and decides who takes what. The scrum master facilitates the conversation and makes sure ownership is clear, but assigning work top-down undercuts the team's ownership and accountability. The scrum master's job is to enable the decision, not make it.
- Who decides what goes into the sprint?
- It's a shared decision. The product owner brings the prioritized backlog and the desired sprint goal; the development team decides how much of it they can realistically commit to based on capacity. The scrum master facilitates that negotiation and protects the team from being pushed past what's achievable.
- How does a scrum master run planning poker?
- The scrum master presents each story, lets the team ask the product owner clarifying questions, then has everyone reveal an estimate simultaneously so no one anchors to the loudest voice. When estimates diverge widely, the high and low voters explain their reasoning, the team discusses, and re-votes. The scrum master facilitates; they don't impose a number.
- What should a scrum master prepare before sprint planning?
- A refined backlog with the top items estimated and clarified, a realistic view of team capacity (PTO, holidays, and overhead accounted for), a draft sprint goal from the product owner, and a time-boxed agenda. Most planning problems are prep problems — an hour of preparation prevents a wasted afternoon.
- Is the scrum master a project manager?
- No, though the roles get confused constantly. A project manager owns scope, schedule, and budget and directs the work. A scrum master is a facilitator and coach who removes impediments and protects the process — they have no authority to assign work or commit the team. The mindset is "serve the team," not "manage the team."