Interview Prep · Scrum Master
Scrum Master Interview Questions & Answers 2026
Real Scrum Master interview questions with expert model answers. Covering Agile fundamentals, Scrum framework, sprint ceremonies, stakeholder scenarios, and behavioural questions — the exact areas interviewers probe.
Agile & Scrum Fundamentals
Core Agile and Scrum Questions
These foundational questions appear in almost every Scrum Master interview. You should be able to answer them fluently without hesitation.
-
A Project Manager owns the project plan, budget, and delivery accountability in traditional/waterfall environments. A Scrum Master is a servant-leader in an Agile/Scrum team — they facilitate ceremonies, remove impediments, and coach the team without owning the delivery directly. The Product Owner owns the backlog and prioritisation; the Scrum Master owns the process and team health. In practice, the boundaries can blur in hybrid environments, but the distinction is important to articulate clearly in interviews.
-
The three pillars of empiricism in Scrum are: Transparency — making the work and process visible to everyone; Inspection — regularly examining progress toward the sprint goal and the product increment; and Adaptation — adjusting the plan, process, or product when inspection reveals problems. These three pillars underpin every Scrum event and artifact.
-
The five Scrum values are: Commitment (the team commits to the sprint goal), Courage (team members do the right thing even when it is difficult), Focus (everyone focuses on the sprint work), Openness (transparency about work and challenges), and Respect (team members respect each other's skills and perspectives). A Scrum Master models and reinforces these values daily.
-
The Definition of Done (DoD) is a shared understanding of what must be true for a product increment to be considered complete. It typically includes criteria like: code reviewed, unit tested, integration tested, documentation updated, and deployed to staging. The DoD prevents "done but not really done" situations, ensures consistency across the team, and gives the Product Owner and stakeholders confidence in what they are receiving at the end of each sprint.
-
The Sprint Retrospective is the team's opportunity to inspect how the last sprint went — in terms of people, relationships, process, and tools — and create a plan for improvement. To make it effective: create a psychologically safe environment where team members feel comfortable raising issues; use structured facilitation techniques (Start/Stop/Continue, 4Ls, Sailboat); ensure every retro produces at least one actionable improvement item; and most importantly, follow up on previous retro actions at the next retro. A retro without follow-up is just venting.
Scenario-Based Questions
Situational & Behavioural Scrum Master Questions
These scenario questions test whether you can actually apply Scrum principles to real situations — the most common reason candidates fail SM interviews.
-
First, I would investigate the root cause using retrospective data and individual conversations. Common causes are: stories are too large and not sufficiently broken down during refinement; the team is accepting too much work relative to actual capacity; there are external dependencies or blockers the team cannot resolve; or the team is being pulled into unplanned work mid-sprint. Once the root cause is identified, the response is targeted: tighter refinement sessions, capacity calibration, impediment escalation, or stakeholder management. I would measure the impact of each change over 2–3 sprints.
-
I bring both parties to a common understanding by facilitating a structured conversation focused on the product goal rather than individual positions. Typically these conflicts arise from misaligned expectations about effort, quality, or feasibility. I help the PO understand technical constraints without getting into technical debates, and help the team understand business priorities without feeling overloaded. Refinement sessions where the PO and team discuss stories together — before sprint planning — often prevent these conflicts from arising in the first place.
-
This is a common and important impediment. My immediate response is to meet with the stakeholder privately and explain — without blame — that all requests need to go through the Product Owner for backlog prioritisation. I also brief the PO so they can manage the relationship. If the behaviour continues, I escalate to the appropriate level with the PO's support. I also coach the development team to politely redirect any direct requests to the PO. The Scrum Master's role here is to protect the team's focus and the process, not to be confrontational.
-
I use facilitation techniques to ensure equal airtime: round-robin participation, a visual timer, or a talking token. After the stand-up, I might speak privately with the individual — framing it as helping the whole team, not calling them out. If the issue continues, I raise it in the retrospective as a team-level process discussion. The goal is always to address the pattern without damaging the individual's confidence or the team's dynamics.
-
Overcommitment usually signals one of two problems: optimistic estimation or external pressure. I address it by building a disciplined capacity planning exercise into sprint planning — accounting for holidays, meetings, and non-sprint work — and anchoring commitment to historical velocity rather than aspirational targets. If overcommitment is driven by stakeholder pressure on the PO, I work with the PO to manage those expectations before planning rather than letting pressure flow into the sprint board.
Advanced Questions
Backlog, Metrics, and Agile Scaling Questions
-
Velocity: average story points completed per sprint — used for capacity planning, not as a performance KPI. Sprint Burndown: shows whether the team is on track to complete sprint commitments. Release Burnup: shows progress toward the release goal over multiple sprints. Lead Time / Cycle Time: how long work takes from start to done — useful for identifying bottlenecks. Sprint Goal Achievement Rate: percentage of sprints where the team met the sprint goal — a strong health indicator. The key is to use metrics to spark conversations, not to evaluate individuals.
-
SAFe (Scaled Agile Framework) is a set of practices for applying Lean-Agile principles across large organisations with multiple teams. At the team level, SAFe teams still work in Scrum sprints. The key addition is the Agile Release Train (ART) — multiple teams aligned to a shared programme increment (PI) and synchronised through PI Planning events. In a SAFe environment, Scrum Masters also participate in Scrum of Scrums to coordinate cross-team dependencies. If you have not worked in SAFe, it is fine to say so — but demonstrate that you understand the concept and are familiar with why organisations use it.
-
A good user story follows the format: "As a [user type], I want [goal] so that [reason/benefit]." It meets the INVEST criteria: Independent (can be developed without depending on other stories), Negotiable (details can be discussed), Valuable (delivers value to the user or business), Estimable (the team can estimate it), Small (fits within one sprint), and Testable (acceptance criteria are clear and verifiable). Acceptance criteria should be written in the "Given/When/Then" format to remove ambiguity.