Scrum Master Interview Questions

Resistance to Scrum usually comes from one of three sources: past bad experiences with a poorly implemented framework, fear of transparency exposing individual performance, or a genuine mismatch between Scrum and the team's actual work type. My first step is to listen rather than defend the framework. I run one-on-ones to understand the specific objections and look for patterns. If the resistance is about past bad practice, I acknowledge it and distinguish what we will do differently. If it is about transparency, I help the team understand that Scrum ceremonies protect them from unplanned work and unrealistic expectations, not the reverse. If the work genuinely does not fit Scrum, I explore Kanban or a hybrid approach rather than forcing a framework on a team for whom it will not work. My job is to serve the team, not to enforce a methodology.

A retrospective that feels like a checkbox exercise usually means the team does not believe their feedback leads to change. My first move is to open the session by reviewing the action items from the previous retrospective and being honest about what happened to each one. If half of them were not followed through, I name that. Then I change the format: instead of the same "went well / could be improved" structure, I try a different technique, such as a timeline exercise, a happiness radar, or a "sailboat" retrospective. These shift the energy and prompt different conversations. I also reduce the number of action items to one or two, owned by specific people, with a definition of done. Teams disengage from retrospectives when they produce long lists that nobody acts on. Fewer commitments, fully kept, rebuild trust faster than comprehensive lists.

The core difference is authority and accountability. A project manager typically owns delivery: they hold the schedule, the budget, and the accountability for hitting milestones. A Scrum Master owns the process: they facilitate, coach, and remove impediments, but they do not own what gets built or when it ships. A project manager manages people toward a plan. A Scrum Master enables a team to manage itself. In practice, many organisations hire Scrum Masters but treat them as project managers, which is one of the most common causes of agile dysfunction. My role is to coach the team toward self-organisation, hold the ceremonies, and protect the team from external interference. If someone needs to be assigned tasks and monitored, either the team is not ready for Scrum or the organisation is not ready for agile.

The team I was working with was losing two to three hours per sprint to a manual environment promotion process managed by a separate infrastructure team. Every deployment required a ticket, a waiting period, and manual steps that only two people in the organisation knew how to perform. I first mapped the full impact across multiple teams and put a number on it: roughly 25 person-hours per sprint across three Scrum teams. I then brought that data to the engineering director and proposed a 30-day spike to automate the process. I brokered the collaboration between the dev team and the infrastructure team and kept both sides informed. The automation took four weeks to implement and reduced environment promotion time from 90 minutes to under five. The lesson I took was that impediments that look like small inconveniences are often systemic blockers in disguise.

Two senior developers on the team had an ongoing tension about code review standards. One advocated for thorough reviews with detailed comments; the other found the process slow and demoralising. The conflict was surfacing in stand-ups as passive disagreement and slowing down pull request throughput. I ran a brief structured exercise during a retrospective: both developers wrote down their definition of a good code review independently, then we compared them. Their core values were actually aligned, but they disagreed on time investment and comment style. We agreed on a working agreement: reviews would be completed within 24 hours and comments would distinguish between blocking issues and suggestions. Within two sprints, PR cycle time dropped by 30% and the interpersonal tension had largely resolved. Giving the disagreement a structured forum removed the need for it to play out in stand-ups.

The Product Owner I was working with had a backlog of over 200 items, many of them vague and unestimated. Sprint planning sessions regularly ran over time and ended with the team uncertain about what they had committed to. I ran a one-on-one with the PO and reframed the backlog as a communication tool, not a filing system. We agreed on a simple rule: the top 20 items must be sprint-ready, defined by a lightweight Definition of Ready (clear acceptance criteria, estimated, no unresolved dependencies). Everything else was in a "raw" state. I facilitated a two-hour backlog surgery session where we closed 60 items that had not been touched in six months and chunked five large epics into smaller stories. Sprint planning sessions shortened from 3 hours to 90 minutes within a month. The PO took ownership of the cadence after that.

I use a mix of quantitative and qualitative signals. On the quantitative side I track velocity trend (not the absolute number, but whether it is stable or volatile), sprint goal achievement rate, and the ratio of planned work to unplanned work each sprint. A team with high unplanned work usually has a protection problem, not a capacity problem. On the qualitative side I run a quarterly team health check using a lightweight radar: we rate ourselves on collaboration, clarity of goals, psychological safety, and process confidence. The scores are less important than the conversation they prompt. I also watch sprint reviews: if stakeholders are consistently surprised by what the team built, something has broken in the communication loop. Agile maturity is not a number. It is whether the team can identify its own problems and fix them without me prompting it.

The first thing I do is diagnose the cause rather than assume the team is underperforming. The most common reasons are: stories are too large and not broken down properly, velocity is overestimated because the team is optimistic at planning, there is too much unplanned work coming in mid-sprint, or the Definition of Done is inconsistently applied. I look at the last three to five sprints and categorise incomplete stories by root cause. If stories are too large, I run a story-splitting workshop. If the team is overcommitting, I introduce a buffer zone in planning and we commit to fewer stories. If mid-sprint interruptions are the issue, I work with stakeholders to create a formal channel for urgent requests that does not bypass the Scrum process. I never reduce the sprint length to make commitments easier. That treats the symptom.

Change resistance in teams is almost always about uncertainty and loss of competence. People who are expert in the current way of working are suddenly beginners again, which is uncomfortable. My approach is to make the transition gradual and to distinguish between learning time and delivery time so the team is not expected to deliver at full velocity while also learning a new stack or process. I set up pairing sessions between those who are more comfortable with the change and those who are less comfortable. I adjust sprint commitments downward during the transition period and communicate that adjustment to stakeholders proactively. I also hold a structured retrospective at the midpoint of the transition to check whether the approach is working. The worst outcome is a team that is struggling with a change in silence because they feel they should be performing at full capacity.