Scrum Master Interview Questions

A team was missing sprint goals consistently because they over-committed and had a vague definition of done. I facilitated a working session to right-size capacity, introduced WIP limits, and tightened the DoD with their input. Over three sprints their goal completion rose from around 60% to over 90%, and the change stuck because they owned it.

Two senior engineers disagreed sharply on architecture and it was stalling the sprint. I didn't take sides; I created a structured spike with clear criteria so the decision was evidence-based, and facilitated a focused discussion. They aligned on the data, and I coached them afterward on disagreeing without blocking the team.

A director kept adding scope mid-sprint, which was destroying focus. I showed the data on how interruptions hurt cycle time, proposed a fast-track lane for genuine emergencies, and held the sprint commitment otherwise. The director accepted the model, and predictability improved because the team stopped context-switching.

Defects kept slipping into production. In a retro I used a root-cause format rather than the usual went-well list, and the team identified missing test coverage and rushed reviews. They committed to a review checklist and pairing on risky changes. Over the next quarter production defects dropped about 40%.

The team was blocked for days waiting on another team's API. I mapped the dependency, set up a recurring cross-team sync, and negotiated a contract-first approach so my team could build against a mock. The blocker cleared and we built that dependency management into how we plan, cutting future wait time.

A team saw Scrum ceremonies as overhead. Instead of enforcing, I asked what was painful and tied each practice to relieving that pain — standups to surface blockers, retros to fix their own complaints. As they saw concrete benefits, buy-in grew organically, and they started suggesting improvements themselves rather than resisting.

I'd resist jumping to conclusions and look at the data first — were stories larger, was there unplanned work, attrition, or environment issues? I'd raise it in retro as a question, not an accusation, to get the team's perspective. Then I'd separate signal from noise; velocity naturally fluctuates, so I'd act only on a real systemic cause like a recurring blocker or chronic over-commitment.

I'd protect the team by making refinement a real, recurring event ahead of planning and coaching the PO on the value of ready backlog items. I'd quantify the cost — stalled sprints, rework — so it's a shared problem, not a complaint. If needed, I'd enforce a definition of ready as an entry gate so unrefined stories don't enter the sprint.

I'd map the dependencies explicitly and bring both Scrum Masters and POs into a regular sync, ideally adopting a scaled-agile cadence like PI planning to align roadmaps. I'd push for contract-first interfaces and mocks so teams can progress in parallel, and track cross-team risks visibly. The goal is to make dependencies planned and visible rather than discovered at release time.

I'd push back, because velocity is a team forecasting tool and weaponizing it for individual reviews destroys collaboration and invites gaming. I'd explain the dysfunction it creates and offer healthier signals of team health and outcome delivery instead. Protecting psychological safety is core to the role, so I'd advocate firmly while proposing a constructive alternative.