Scrum Master Interview Questions
(With Answer Frameworks)

Answer framework

A Project Manager operates in a command-and-control model: they assign tasks, track progress, and own delivery outcomes. If something slips, it is the PM's problem to fix. A Scrum Master operates as a servant leader: they facilitate, coach, and remove blockers — but the team owns delivery. The SM enables the team to do its best work; they do not direct the work. In a Scrum context, the Development Team commits to the sprint and is accountable for the sprint goal. The SM creates the conditions for that commitment to succeed. A good answer will also note that the SM serves three parties: the Development Team (shielding them from interruptions, coaching self-organization), the Product Owner (helping them manage the backlog and communicate with stakeholders), and the broader organization (evangelizing Agile values and removing systemic impediments).

Answer framework

The three pillars of Scrum are Transparency, Inspection, and Adaptation — and they form a feedback loop, not just a list. Transparency means everyone sees the true state of work: the backlog, the sprint progress, the Definition of Done. Without transparency, inspection is impossible. Inspection means the team regularly examines progress toward the sprint goal and the product goal — in daily standups, sprint reviews, and retrospectives. Without inspection, adaptation is blind. Adaptation means the team adjusts plans, processes, or behaviors quickly when inspection reveals problems. The reason this matters in an interview: interviewers are checking whether you understand Scrum as an empirical process framework, not just a set of ceremonies. The pillars explain why the ceremonies exist.

Answer framework

The Definition of Done is the shared agreement of what conditions must be met for a backlog item to be considered complete. It is created by the Development Team (with input from the PO and SM) and applied consistently to every Product Backlog Item. A good DoD typically includes: code written and reviewed, tests written and passing, functionality tested in a production-like environment, documentation updated, and the item integrated and deployed to a staging environment. The key point interviewers want to hear: the DoD is not a checklist the SM imposes — it is an agreement the team owns. If items consistently fail to meet the DoD, that is a signal for the retrospective: is the DoD realistic? Is there a systemic problem with testing or integration? The SM's role is to ensure the DoD is visible, understood, and consistently applied.

Answer framework

Velocity is the amount of work a team completes per sprint, measured in story points (or whatever sizing unit the team uses). It is calculated by summing the story points of all completed items — items that meet the Definition of Done — at the end of each sprint. Velocity is used for two things: sprint planning (how many points can the team realistically commit to, based on recent sprints?) and release forecasting (given remaining backlog size and current velocity, when might we complete this set of work?). Critically, velocity is not a performance metric. You should not use it to compare teams, pressure teams to increase it sprint over sprint, or reward teams for high velocity. Teams that inflate velocity by lowering their estimates are not delivering more value — they are gaming a metric. A good SM watches for velocity manipulation and redirects the conversation back to outcomes: what did the team actually deliver for users?

Answer framework

Low morale usually signals that previous retrospectives produced no visible change. The first thing to address is psychological safety — people will not speak honestly if they fear judgment or if they believe nothing will come of it. Start by acknowledging the state directly: 'I know the last few sprints have been hard. I want this retro to actually be useful.' Use anonymous feedback tools (Retrium, EasyRetro's anonymous mode, or simple sticky notes collected before the session) so people can say what they actually think. Focus the conversation on systems and processes, not individuals — 'What made this sprint hard?' not 'Who made this sprint hard?' Most importantly: close the session with at least one specific, owned, time-bound action item. Then, visibly act on it before the next retro. Nothing repairs retrospective trust faster than showing that something changed because the team said it should.

Answer framework

Sprint planning has a timebox: typically 2 hours per week of sprint length (so 4 hours for a 2-week sprint). If you are running long, the first intervention is a gentle reminder: 'We have 30 minutes left and we still need to confirm the sprint goal — let us focus on that.' The most common cause of long planning is the team trying to solve implementation details in the room. Defer those: 'Let us park the question of how we implement the authentication flow and schedule a technical spike for day 1 of the sprint.' Keep the discussion anchored to the sprint goal — can the team articulate it clearly? Does everyone understand what Done looks like for the most critical items? If planning consistently runs long, that is a signal to address in the retrospective: are backlog items well-refined before planning? Is the Product Owner able to answer questions quickly? The SM's role is to protect the timebox while ensuring the team leaves with enough clarity to start.

Answer framework

The daily standup is a synchronization event for the Development Team — not a status report for the SM or PO. If one person is dominating, gently redirect using the three-question format: what did you complete since yesterday, what will you work on today, and are there any blockers? If the developer is going into implementation detail, you can say: 'It sounds like you and [other developer] should sync on that after standup — let us note it as a follow-up.' Do this in the moment but without embarrassing anyone. Then coach the developer 1:1 after the meeting: 'I noticed we were spending a lot of time on implementation detail in standup. The goal is to keep it to 15 minutes so everyone can get to work. How can I help you structure your updates differently?' Also remind the broader team: the standup is theirs. If it is becoming a status meeting for management, that is a culture issue — one the SM and team need to address explicitly.

Answer framework

The SM must not take sides — doing so destroys trust with one party and makes you ineffective as a facilitator. Instead, create a structured space for both parties to be heard: 'I hear that you both have strong views on this. Let me give each of you time to explain your concern without interruption.' Then redirect to shared ground: the sprint goal, the product goal, the Definition of Done, or the team's working agreements. Often PO-team conflict is about scope ('You are adding complexity I did not ask for') or about feasibility ('You are asking for something that cannot be done in the time you have given'). Help both parties articulate the constraint clearly. If the conflict is about prioritization, that is the PO's decision to make — but the SM can ensure the team's input is heard before the decision is finalized. If the conflict persists and is affecting the sprint, escalate to a structured conversation with both parties and their managers present.

Answer framework

Chronic carryover is a symptom, not a root cause. Before intervening, diagnose: is the team overcommitting in sprint planning (velocity is too optimistic)? Are requirements unclear at the start of the sprint, leading to mid-sprint rework? Are there external interruptions — production issues, unplanned stakeholder requests — that consume capacity? Is technical debt making every task take longer than estimated? Use the retrospective to name the pattern explicitly: 'I have noticed that for the last three sprints, we have carried over two or three items. I would like to understand why — not to assign blame, but to fix the system.' Once you have identified the root cause, address it structurally: if it is overcommitment, lower the sprint commitment until velocity stabilizes. If it is unclear requirements, invest in backlog refinement. If it is interruptions, create a policy for handling them. The SM's job is to help the team see the pattern and build the habit of completing what they commit to.