I’ve seen a lot of guides on Scrum Master interview questions. Most of them are basically a lightly reordered list from the Scrum Guide. The problem is that interviewers who have actually been Scrum Masters for a few years don’t ask textbook questions, they ask situational ones. And the situational ones are where people get tripped up.
This is my attempt to write the guide I wish had existed when I was prepping for my first Scrum Master role. These are organized by the areas interviewers actually probe, not by arbitrary difficulty tiers.
The foundational questions (still important)
You will almost always get at least two or three basics, usually at the start to warm up the conversation. Know them cold so you can answer them in under 90 seconds and move on.
What’s the difference between a Scrum Master and a project manager? The short answer: a project manager owns the deliverable. A Scrum Master owns the process and removes impediments for a self-organizing team. Project managers typically have authority over what gets built. Scrum Masters don’t. They facilitate. This distinction matters more than it sounds, because interviewers use it to screen out candidates who will default to command-and-control behavior in disguise.
What are the three pillars of empiricism in Scrum? Transparency, inspection, and adaptation. What interviewers want beyond the recitation is an example of each from your actual work. “Transparency” without a concrete example (like “we made velocity visible to the entire org, not just the team”) sounds hollow.
How long should a sprint be, and how do you decide? The Scrum Guide says one to four weeks. What interviewers want to hear is your reasoning process, not a fixed answer. Teams newer to Scrum often benefit from shorter sprints (two weeks) to get faster feedback cycles. Teams with high external dependencies might need longer ones to reduce context-switching overhead. There’s no single right answer here.
Situational questions about dysfunction
This is where most interviews get interesting. Interviewers want to know how you handle common Scrum anti-patterns, because every real team has them.
A developer keeps skipping the Daily Scrum. What do you do? Don’t start with “I’d enforce attendance”. Start with curiosity. Find out why. Sometimes it’s because the Daily Scrum has become a status report to management rather than a team coordination event, and that developer has correctly identified it as useless. Sometimes it’s a scheduling conflict. Sometimes it’s interpersonal. Diagnose before prescribing.
The team keeps overcommitting in sprint planning and missing goals. How do you address this? A few things could be happening. The team might be using story points but not having calibrated them well. There might be implicit pressure (from a product owner or stakeholder) that makes saying “no” feel risky. There might be hidden work that isn’t on the board. I’d start by asking the team in a retrospective to reflect on where their estimates go wrong, without assigning blame. Velocity-based planning (using historical averages rather than optimistic guesses) usually helps once the team is willing to engage with it honestly.
Mid-sprint, a stakeholder wants to add a high-priority item to the current sprint. What happens? Protect the sprint goal. The sprint goal exists precisely for situations like this. If the new item genuinely can’t wait, the options are to swap it for something of similar size (with the development team’s agreement), to negotiate with the stakeholder about what they’re willing to deprioritize, or, in extreme cases, to cancel and re-plan the sprint. Canceling is rare in my experience. Swapping is usually the path forward.
Questions about metrics and measurement
Interviewers increasingly ask about how you measure team health. If your answer is just “velocity”, you’ll land below the bar at most companies.
What metrics do you track for team health? Velocity matters but it’s a lagging indicator. I find cycle time (how long a story takes from “in progress” to “done”) more useful for spotting bottlenecks. Sprint goal achievement rate tells you whether the team is planning realistically. And qualitative signals from retrospectives, specifically whether people surface real problems or just go through the motions, are often more telling than any number.
According to the 2024 Stack Overflow Developer Survey, roughly 63% of professional developers work in organizations using agile methods, but satisfaction with their agile practices varies widely. That gap between “we do Scrum” and “we do Scrum well” is usually visible in retrospective quality first.
Scaling questions for senior roles
If you’re interviewing for a senior Scrum Master or Agile Coach position, expect questions about scaling frameworks.
What’s the difference between SAFe and LeSS? SAFe (Scaled Agile Framework) is prescriptive and adds significant ceremony, planning intervals, and roles. It’s popular in large enterprises that want a documented methodology they can adopt without rethinking too much. LeSS (Large-Scale Scrum) takes the opposite approach: it keeps most of Scrum intact and adds as little as possible. LeSS requires more organizational change because it tends to challenge existing management structures. I’ve seen SAFe work reasonably well in organizations with strong top-down buy-in. I’ve seen it become theater in organizations that adopted it without changing their incentive structures. (LeSS can fail for the same reasons, just differently.)
Have you worked with multiple teams on the same product? If yes, the interviewer wants specifics: how did you coordinate dependencies, what happened to the retrospectives, who owned cross-team impediments. If no, be honest about it and describe how you’d approach it. “I haven’t, but here’s how I’d think through it” is a real answer.
Questions to ask the interviewer
Near the end, you’ll get a chance to ask questions. Most candidates ask generic things (“what’s the team culture like?”). Here are some that actually reveal useful information:
- “What does the team’s relationship with the product owner look like today?” (This tells you whether the PO is present and engaged or a bottleneck.)
- “When was the last time a retrospective action item actually changed something?” (This tells you whether retrospectives are real or performative.)
- “How does leadership respond when the team says no to a scope addition?” (This tells you whether Scrum is supported from the top or just tolerated.)
The answers to those three questions will tell you more about whether the role is a good fit than anything else in the interview.
One thing I think a lot of prep guides get wrong
They treat Scrum Master interviews as a knowledge test. What interviewers at good companies are actually evaluating is your judgment and your instinct to ask questions before acting. The best Scrum Masters I’ve seen are professionally curious, not procedurally correct. If your prep is all memorization, that will come through.
Practice explaining the reasoning behind your past decisions, not just the decisions themselves. That’s where the interesting part of the conversation lives.