Scrum Master interview questions

Tell me about yourself.

What a good answer covers

• A shape, not a life story: the teams they serve now, what those teams build, why this role.
• How many teams and for how long — scrum master CVs are vague about this and interviewers notice.
• Under two minutes, ending pointed at the job.

Why do you want to be a scrum master?

What a good answer covers

• Something about teams and how they work, not about disliking the technical work they came from.
• Specific: a moment a team changed and they were part of why.
• Connected to this employer — their product, their scale, their stage of maturity.
• Under a minute.

What does a scrum master actually do?

What a good answer covers

• Accountable for the team's effectiveness, not for the delivery of the work — that distinction is the question.
• Three directions: serving the team, the product owner and the wider organisation. A candidate who only names the first has half the role.
• Removing impediments, coaching, and changing what the organisation does to the team.
• Said without reciting the Scrum Guide. An answer that is only quotation reads as someone who has read it rather than done it.

How is a scrum master different from a project manager?

What a good answer covers

• A PM owns scope, schedule and budget; a scrum master owns none of them and influences all three.
• Authority: the scrum master does not assign work or manage people, which is exactly why the job is hard.
• Said generously. Interviewers hire in organisations that still have PMs, and a candidate who is sniffy about them will not last.
• Honesty about hybrid reality — plenty of UK roles are advertised as scrum master and are partly PM, and saying so is a strength.

How do you know whether you are doing a good job?

Senior. Marked against your own answer in the app.

What are the three accountabilities in Scrum, and what is each one for?

What a good answer covers

• Product owner, scrum master, developers — accountabilities, not roles, since the 2020 Scrum Guide.
• PO owns the product backlog and maximising value; developers own how the work gets done and the increment; scrum master owns effectiveness.
• That 'developers' means everyone building it, testers and designers included — a routine misreading.
• Where they overlap in practice and how the candidate handles it.

Walk me through the Scrum events and what each is for.

What a good answer covers

• Sprint planning, daily scrum, sprint review, retrospective — and the sprint itself as the container.
• The purpose of each, not the duration. Someone who leads with timeboxes is describing a timetable.
• Daily scrum is for the developers to re-plan their day, not a status report to the scrum master.
• Review is with stakeholders and is about the product; retrospective is the team and is about how they work.

What is the difference between the definition of done and acceptance criteria?

What a good answer covers

• Definition of done applies to every item and is the team's quality bar; acceptance criteria are specific to one item.
• Done is a commitment to the increment; acceptance criteria describe behaviour.
• A team with no definition of done ships things that are nearly finished, and the candidate should be able to say what that cost them.
• Who owns each — the team owns done, the PO writes acceptance criteria with the team.

When would you use Kanban instead of Scrum?

What a good answer covers

• Work that arrives unpredictably and cannot wait for a sprint boundary — support, operations, BAU.
• Continuous flow with WIP limits rather than a fixed commitment.
• That a team can use Scrum with flow metrics, and that the two are not enemies.
• A candidate who says Scrum is always right has answered badly. So has one who has never used Scrum properly.

Your manager wants to compare two teams' velocity. How do you respond?

What a good answer covers

• Velocity is not comparable between teams — estimates are relative to that team and to nothing else.
• What comparing them causes: point inflation, and estimates that stop being useful for planning, which is the actual loss.
• Offer what the manager actually wants instead: throughput, cycle time, predictability, delivered value.
• Handled as a conversation rather than a refusal. This question is testing whether they can push back upwards without being difficult.

Which metrics do you find genuinely useful?

What a good answer covers

• Flow: cycle time, throughput, work in progress, ageing work items.
• Predictability over raw speed — a team whose forecasts hold is worth more than a fast one nobody can plan around.
• Quality signals: escaped defects, rework, how often done means done.
• Team health, and that it is measured by asking rather than by a dashboard.
• Scepticism about any single number, including the ones they like.

Give me an example of an impediment you removed.

What a good answer covers

• A specific one, with what was actually blocking and who was involved.
• Ideally organisational rather than technical — a slow approval, a dependency on another team, an environment nobody owned.
• What they did, not who they told. Escalating is sometimes right, and by itself it is not removal.
• Whether it stayed removed.

The team is blocked by another team that will not prioritise their request. What do you do?

What a good answer covers

• Go and talk to the other team first — usually the request never reached anyone who could act on it.
• Understand their priorities before arguing; they are not refusing, they are doing something else.
• Make the cost visible: what this blocks, what it delays, in terms the other side's manager cares about.
• Escalation with a proposal rather than a complaint, and only after the direct route.
• Reduce the dependency where possible — a stub, a workaround, a different sequence.

Your product owner is never available and the backlog is a mess. How do you handle it?

What a good answer covers

• Find out why: usually they hold another full-time job and this was added to it.
• Make the impact concrete — what the team builds wrong or builds twice without them.
• Practical help before criticism: refinement they can prepare for in less time, decisions batched, a stand-in for small calls.
• Escalation to whoever gave the PO the job, framed as capacity rather than as a complaint about a colleague.
• Not doing the PO's job for them permanently, and being able to say why that fails.

A stakeholder keeps going directly to developers with requests mid-sprint. What do you do?

What a good answer covers

• Understand what they need and why the normal route is not working for them — the behaviour is a symptom.
• Protect the sprint without making the team the enemy: the answer routes through the PO, and the candidate should say so.
• A faster path for genuinely urgent things, so the rule is followable.
• Coaching the developers to redirect rather than policing the stakeholder forever.
• Whether it changed, which is the only measure of whether they handled it.

Two developers on your team are in open conflict. What do you do?

What a good answer covers

• Separately first, to understand both — not a joint meeting as the opening move.
• Whether it is personal or structural. A lot of team conflict is two people held accountable for the same thing.
• Facilitating a conversation rather than adjudicating one.
• Knowing when it stops being theirs to handle and becomes a line manager's or HR's.
• Not pretending it resolved neatly if it did not.

Retrospectives have gone quiet and nobody raises anything. What is going on and what do you do?

What a good answer covers

• Usually one of three things: nothing changed last time, it is not safe to speak, or the format has gone stale.
• Check whether previous actions were actually done — this is the most common cause and the easiest to fix.
• Change the format, and ask people individually before the session.
• Safety: whether a manager attends, and whether the candidate has noticed that it matters.
• A retrospective that produces one action that gets done beats one that produces ten that do not.

You join a team that says it does Scrum but the sprints are really just two-week deadlines. Where do you start?

Senior. Marked against your own answer in the app.

What does servant leadership mean to you in practice?

What a good answer covers

• Concrete behaviour rather than the phrase: what they did last week that the team did not have to.
• Leading without authority — influence, asking rather than telling, letting the team decide things the candidate would have decided differently.
• That it is not being passive or being the team's secretary, which is the failure mode at both ends.
• An example where they let a team make a decision they disagreed with, and what happened.

It is the last day of the sprint and the work will not be finished. What do you do?

What a good answer covers

• Nothing dramatic on the last day — the conversation should have happened when it became visible, and the candidate should say when that was.
• Unfinished work goes back to the backlog and is re-estimated; it is not 'carried over' as if it were half done.
• The sprint is not extended. This is the point interviewers listen for.
• The sprint goal: whether it was met even if not every item finished, which is often the real answer.
• Retrospective picks up why, without blame.

How does your team estimate, and what do you do when they are consistently wrong?

What a good answer covers

• Relative estimation — story points, t-shirts — and why relative beats hours for forecasting.
• Consistently wrong usually means items are too big, or unknowns are being estimated as if they were known.
• Smaller slices, spikes for the genuinely unknown, and looking at actual cycle time rather than arguing about points.
• Estimates are for planning, not for performance management, and the candidate should protect that.
• Willingness to drop estimation entirely where flow metrics do the job better.

What experience do you have of scaling Scrum across multiple teams?

Senior. Marked against your own answer in the app.

Which Scrum certifications do you hold?

What a good answer covers

• The straight answer: PSM I/II from Scrum.org, CSM or A-CSM from Scrum Alliance, SAFe SM, or none.
• The difference matters to some interviewers — PSM has an exam and no mandatory course; CSM requires attending one.
• Never claim a level not held; both registries are public and searchable in seconds.
• If uncertified, what they have instead — teams served, years, outcomes — without apology.