Top Scrum Master Interview Questions & Answers (2026)
17 questions Scrum Master interviewers actually ask, with the strong answer, the weak one, and the follow-up that comes next.
- Scrum MasterRole
- $79K-$167KTypical US pay
- 3-4 roundsInterview loop
- Often requiredCert in hiring
- UsuallyHands-on test
Table of Contents
Scrum Masters are hired by software companies, banks, insurers, government agencies and consultancies that run product teams. Many employers now fold delivery lead or agile coaching duties into the role, so interviewers dig for evidence that you improve how teams work, not just that you book and run meetings. Expect scenario questions, a facilitation or role-play exercise, and conversations with Developers and a Product Owner who will judge whether they would want you on their team.
PSM I shows you know the Scrum Guide precisely, and recruiters often list it, or Scrum Alliance's CSM, as a requirement. Interviewers take the theory as a given. What they test is whether you can coach without commanding, support a struggling Product Owner, influence managers, and describe your impact as outcomes rather than ceremonies held.
What the Scrum Master interview loop looks like
Most Scrum Master hiring runs 4 rounds. Each one is testing something different, so prepare for each separately.
The 17 questions, with answers
Each card shows the question as it is usually asked, what the interviewer is really checking, a strong answer, the weak answer they hear most often, and the follow-up that comes next. Say the strong answers in your own words — a memorised script sounds memorised.
- Basic · 4
- Core · 5
- Advanced · 3
- Scenario · 3
- Behavioural · 2
In your own words, what is a Scrum Master accountable for?
What they are testing: Whether you know the 2020 Scrum Guide wording and see the role as more than meeting facilitation
The Scrum Guide says the Scrum Master is accountable for establishing Scrum as defined in the Guide and for the Scrum Team's effectiveness. In practice I serve in three directions. For the team, I coach self-management and cross-functionality, help them create high-value Increments that meet the Definition of Done, and get impediments removed. For the Product Owner, I help with defining an effective Product Goal and managing the Product Backlog. For the organization, I help people understand empirical product development and remove barriers between stakeholders and the team. Facilitation is part of it, but the real aim is a team that keeps improving even when I'm not in the room.
What are the three Scrum artifacts, and what commitment goes with each one?
What they are testing: Precise 2020 Guide knowledge: Product Goal, Sprint Goal and Definition of Done
The Product Backlog, the Sprint Backlog and the Increment, and each has a commitment that adds focus and transparency. The Product Backlog's commitment is the Product Goal, the long-term objective the Scrum Team plans against. The Sprint Backlog's commitment is the Sprint Goal, the single objective for the Sprint, which gives the Developers flexibility in exactly how they reach it. The Increment's commitment is the Definition of Done, the formal description of the quality an Increment must meet; an item that doesn't meet it can't be released or even presented at the Sprint Review, and it returns to the Product Backlog. Teams that lose their Sprint Goal tend to drift into a task list, so I lean on these a lot.
Who is the Daily Scrum for, what is it for, and what's your role in it?
What they are testing: Whether you know the Daily Scrum belongs to the Developers
The Daily Scrum is a 15-minute event for the Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as needed, planning the next day of work. The Developers own it and can use whatever structure works for them; the old three questions aren't in the 2020 Guide at all. If the Product Owner or Scrum Master are actively working on Sprint Backlog items, they take part as Developers. My job is to make sure it happens, stays within the timebox and stays focused on the goal, mostly by coaching rather than chairing it. I avoid turning it into a status report to me, because that quietly takes ownership away from the team.
What is the Definition of Done, and who creates it?
What they are testing: Understanding of quality, transparency and organizational standards
It's the formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets it, an Increment is born. If the organization has a Definition of Done as a standard, all Scrum Teams follow it as a minimum; if not, the Scrum Team creates one appropriate for the product. When several Scrum Teams work on the same product, they share one Definition of Done. In practice I help the team make it concrete, for example code reviewed, automated tests passing, security checks run, deployed to a production-like environment, and strengthen it over time as their engineering practices mature.
How do you coach a team toward self-management when managers keep assigning tasks directly to individuals?
What they are testing: Whether you can coach the organization, not just the team
I'd start by understanding why managers do it. Usually it's a visibility or trust problem: they can't see progress, so they reach in. I'd talk with them one to one, explain how Scrum gives them transparency through the Product Backlog and the Sprint Review, and invite them to the Review to see the working Increment. I'd ask them to route new work through the Product Owner instead of to individuals. With the team, I'd coach the Developers to own the Sprint Backlog and to redirect side requests politely to the Product Owner. I'd also make the cost visible, for example how many Sprint Goals slipped because of those requests.
What makes a good Sprint Goal, and how would you help a team that writes theirs as a list of tickets?
What they are testing: Understanding the Sprint Goal as a source of coherence and flexibility
A good Sprint Goal is one objective that explains why the Sprint is valuable, in a sentence stakeholders understand, for example 'customers can pay by card in the mobile checkout'. It connects to the Product Goal and leaves the Developers flexibility in which work gets them there. A list of tickets does none of that: when one ticket slips, nobody knows what matters most. In Sprint Planning I'd coach the Product Owner to propose how the product could increase in value this Sprint, so the whole Scrum Team can shape a goal together. Then we'd select items that serve it, and use the Daily Scrum to inspect progress toward the goal rather than ticket counts.
How would you run a retrospective for a team that says 'nothing ever changes, so why bother'?
What they are testing: Facilitation skill and making improvements actually stick
That cynicism usually means past actions were too big, had no owner or were never revisited. I'd open the next retrospective by reviewing what happened to previous actions, and admit it if I let them drop. Then I'd change the format to break the routine, bring data such as cycle time or carry-over to ground the discussion, and push for one or two small improvements, each with an owner and a clear sign of success. The Guide says the most impactful improvements should be addressed as soon as possible and may even be added to the next Sprint Backlog, so I'd make sure that happens. Next time, we start by checking whether it worked.
How do you forecast when a set of features will be delivered without promising dates the team can't keep?
What they are testing: Empirical forecasting and honest communication with stakeholders
I use the team's actual history rather than hopes. If we track throughput, a simple Monte Carlo simulation over the last ten or so Sprints gives a range with a confidence level, for example an 85 percent chance of landing within five to seven Sprints. Burn-up charts help stakeholders see scope growing as well as work completing. The Scrum Guide calls these practices useful but says they don't replace empiricism, so we re-forecast every Sprint as we learn. The Product Owner owns the conversation with stakeholders; I help them present ranges and trade-offs instead of a single date that gets treated as a promise.
What do you do when the Product Owner is rarely available and the team is guessing what to build?
What they are testing: Supporting the Product Owner without taking over the accountability
I'd talk to the Product Owner first to understand what's pulling them away, often too many products or a manager who doesn't see it as a real job. I'd make the impact concrete, for example rework or items rejected at the Sprint Review. Then we'd agree minimum touchpoints: Sprint Planning, the Sprint Review, a regular refinement slot and a quick way for Developers to ask questions. The Product Owner can delegate backlog work but remains accountable, so I might help them set that up with someone on the team. If the cause is structural, I'd raise it with whoever sponsors the product, because an absent Product Owner is an organizational impediment.
Five teams are building one product. What stays the same in Scrum, and what would you add?
What they are testing: One Product Backlog, one Product Owner, shared Done and continuous integration
The Scrum Guide's rules still hold: one product has one Product Backlog and one Product Owner, and teams working on it share a single Definition of Done and produce an integrated Increment. What gets hard is dependencies and integration. Scrum.org's Nexus framework adds cross-team refinement to surface dependencies early, Nexus-level Sprint Planning and Daily Scrum focused on integration, and a Nexus Integration Team accountable for an integrated Increment every Sprint. Before adding a framework, though, I'd try to reduce dependencies through how teams are formed, ideally around customer-facing features, and push for automation so integration happens continuously rather than at the end.
What metrics would you use to show your teams are improving, and which would you refuse to use?
What they are testing: Outcome-oriented measurement and awareness of metrics that get gamed
I'd look at outcomes and flow. Outcomes: customer usage or satisfaction for what we release, and progress toward the Product Goal, which the Product Owner owns. Flow: cycle time, throughput, release frequency and how much work carries over between Sprints. Quality: escaped defects and time to restore service when something breaks. Team health matters too, through short regular surveys. I'd refuse to compare velocity between teams or set it as a target, because story points are relative to each team and inflate as soon as people are judged on them. Any metric should be visible to the team and used to inspect and adapt, not to rank people.
Midway through a Sprint, a market change makes the Sprint Goal obsolete. What happens, and who decides?
What they are testing: Precise knowledge of Sprint cancellation and adapting scope
Only the Product Owner has the authority to cancel a Sprint, and the Guide says that can happen if the Sprint Goal becomes obsolete. Before cancelling, I'd want the Scrum Team to check whether the goal really is obsolete, or whether scope can simply be clarified and renegotiated with the Product Owner as they learn, which the Guide allows as long as the Sprint Goal isn't endangered. Cancellation is disruptive and means replanning, so it shouldn't be casual. If the Sprint is cancelled, I'd help the team move quickly into a new Sprint Planning, and later use a retrospective to ask whether shorter Sprints would help us respond to change faster.
A senior Developer dominates refinement, and the others have stopped speaking. What do you do?
What they are testing: Facilitating team dynamics while respecting the individual
I'd talk to the senior Developer privately first, acknowledge their expertise, and share what I've observed without blame: newer people go quiet when they speak first. I'd ask for their help growing the others, for example by asking questions instead of giving answers. In the sessions I'd change the structure: silent writing before discussion, techniques where everyone reveals estimates at once, or pairing a junior with the senior on a tricky item. I'd watch whether more voices appear over a couple of Sprints, and if not, raise team dynamics in a retrospective, framed as how we work together rather than about one person.
Your team has carried over about 40 percent of its Sprint Backlog for three Sprints in a row. How do you approach it?
What they are testing: Root-cause thinking rather than just 'take on less'
I'd bring the data to the team and let them explore it, rather than handing them my diagnosis. Common causes are items too big to finish in a Sprint, unplanned work arriving mid-Sprint, dependencies on other teams, too much work started at once, or a Definition of Done that needs something the team can't do itself. We'd look at a few carried items in detail to see where they stalled. The fix depends on the cause: slicing items smaller in refinement, limiting work in progress, making unplanned work visible and agreeing with the Product Owner how to handle it, or tackling the dependency. Pulling in less work may help, but it treats a symptom.
Your team wants to stop holding Sprint Reviews because stakeholders never show up. How do you respond?
What they are testing: Understanding the Sprint Review's purpose and fixing stakeholder engagement
I'd agree the current Review isn't working, but dropping it removes the main point where stakeholders inspect the Increment and the Product Backlog gets adapted. So I'd work on the cause with the Product Owner. Who actually needs to be there, and do they know why? Is it a slide-heavy status meeting instead of a session with the real product? I'd help the Product Owner invite specific people for specific items, keep it hands-on, and ask stakeholders directly what would make it worth their time. The Guide describes the Sprint Review as a working session, not a presentation, and making it one is usually the turning point.
Tell me about an impediment you removed that the team couldn't remove themselves.
What they are testing: Organizational influence and whether you measure the impact
This is a template for your own story. Situation: the team, the product and the impediment, for example a two-week wait for test environments from another department. Task: why it was beyond the team's control and what it cost, ideally in numbers such as days lost per Sprint. Action: who you talked to, how you made the cost visible, what you proposed, and how you kept the team informed. Avoid making yourself a lone hero. Result: the measurable change, such as provisioning dropping to one day, and what the team did with the time saved. Close with what it taught you about working with the wider organization.
Tell me about a time you disagreed with your Product Owner or manager about how the team should work.
What they are testing: Influence and respect rather than rule-quoting
This is a template to fill with your own example. Situation: what the disagreement was, for example a manager wanting fixed-scope commitments every Sprint, or a Product Owner wanting to skip refinement. Task: what was at stake for the team and the product. Action: how you understood their concern first, the evidence you brought, how you proposed a time-boxed experiment instead of arguing principles, and how you kept the relationship intact. Result: what changed, with a measure if possible, or what you learned if you didn't get your way. Interviewers want to hear influence and respect, not that you were right.
Get the theory airtight before the interview
Interviewers build follow-ups on the fundamentals. ExamCert AI has exam-style PSM I questions with an explanation for every option, so the basics stay automatic when the questions get harder.
Practise on ExamCert AIPSM I practice questionsThe practical task
Expect some version of this. Companies vary the details, not the shape.
The panel plays a Scrum Team after a bad Sprint: the Sprint Goal was missed, a production incident consumed three days, and two Developers blame each other for a late handoff. The Product Owner is visibly frustrated. You have 10 minutes to plan and 25 minutes to facilitate their Sprint Retrospective, then 5 minutes to explain your choices to the panel.
- Open with the purpose and timebox, and set a safe tone: we are examining the system, not blaming people.
- Gather data first, such as a quick timeline of the Sprint, so facts come before opinions.
- Use a structure that brings every voice in, such as silent writing, and gently manage anyone dominating.
- Guide the team toward root causes like unplanned work and handoffs, away from the two individuals.
- Close with one or two improvements, each with an owner and a check-in, and agree how you'll know they worked.
- In the debrief, explain your choices and what you would follow up privately after the session.
Hire vs no-hire:Hires stay neutral, draw out quiet people and finish with small owned actions. No-hires run a generic format, take sides in the blame, or end with a long list of actions nobody owns.
Questions to ask them
"Do you have any questions for us?" is still being scored. Four that land well for a Scrum Master role:
Mistakes that sink candidates
What the PSM I does and does not prove
What the PSM I gets you
Scrum Master postings usually ask for a Scrum certification, and PSM I and Scrum Alliance's CSM are the two names recruiters recognize most. PSM I has a reputation for rigour because it needs an 85 percent score on a timed 80-question assessment, with no mandatory course. It clears HR filters and shows you know the Scrum Guide precisely, which matters when experienced agile practitioners sit on the panel.
What it does not prove
Passing PSM I proves knowledge, not the ability to change how people work. Interviews test what it can't: facilitating a tense room, coaching a Product Owner, influencing managers who doubt Scrum, and showing measurable improvement. Many panels also probe technical literacy, such as testing, continuous integration and release practices, because a Scrum Master who can't follow engineering conversations struggles to spot real impediments.
Pay:The range is Indeed's reported US Scrum Master base salary (job postings over 36 months, updated October 2026), with an average near $115,000. BLS does not track Scrum Masters as a separate occupation. Industry, number of teams, extra scope such as agile coaching, and location move pay most.
Still sitting the PSM I?
Pass it first time and walk into the interview with the credential on your CV. ExamCert AI has exam-style PSM I questions with an explanation for every option.
Practise on ExamCert AIPSM I practice questionsFAQ
Is PSM I or CSM better for Scrum Master interviews?
Recruiters generally accept either. CSM requires a course with a Scrum Alliance trainer, while PSM I is an assessment you can take without a class and is known for its strict pass mark. Interviewers rarely care much which one you hold. They care whether you can apply Scrum to messy real situations, so put your effort into strong examples rather than collecting both.
Do Scrum Masters need technical skills?
You don't need to write code, but you should understand how software is built and released: version control, automated testing, continuous integration and deployment, environments and technical debt. That lets you follow Developer conversations, spot impediments such as slow builds or manual releases, and help the team strengthen its Definition of Done. Panels that include Developers often probe this early.
How do I answer if my last company did Scrum badly?
Be honest and show what you did about it. Interviewers know many organizations run a diluted version of Scrum. Describe the gap, such as no real Product Owner or Sprints that never produced a usable Increment, what you changed or tried to change, and what you learned. Avoid criticizing your employer; frame it as constraints you worked within and improvements you drove.
Should I mention Kanban or scaling frameworks in a Scrum Master interview?
If the company uses them, yes. Many organizations run Scrum inside a scaling framework or alongside Kanban practices. Show you understand what Scrum itself requires and how other practices can complement it, for example using flow metrics like cycle time within Scrum. Avoid presenting any single framework as the answer to everything; interviewers are looking for judgment about context.
How do I show impact as a Scrum Master when the team does the work?
Pick changes you initiated and their measurable result, such as release frequency rising from monthly to weekly after you helped the team automate deployments, or carry-over falling after slicing workshops. Be precise about your contribution and credit the team. Include softer outcomes too, like a Product Owner who now runs effective Sprint Reviews. Concrete before-and-after examples beat any list of events.
Sources
Figures on this page come from Scrum.org and the other primary sources below:
- Scrum.org - Professional Scrum Master I (PSM I) Certification
- The 2020 Scrum Guide (Schwaber and Sutherland)
- Indeed - Scrum Master salaries in the United States
- Scrum.org - The Nexus Guide
Checked November 4, 2026. Fees, outlines and eligibility rules change — confirm with Scrum.org before you book.