Scrum master interview questions, with worked answers

How to use these questions

Practise each short answer aloud, then attach a story of your own: the team, the problem, what you did, and what happened next, including what did not work. Many interviews include a role play or a short facilitation, such as running five minutes of a retrospective with the panel, so practise doing as well as explaining.

What a scrum master is expected to know

• The Scrum Guide: the three accountabilities, the five events, the three artefacts and the commitment behind each, and the values of ScrumKnow the Scrum Guide well enough to explain the reason behind each event, and to adapt without losing it..
• Flow: KanbanVisualise the work, limit work in progress and manage flow; often used next to Scrum or instead of sprints. practices and the measures of flow, and when they suit a team better than sprints.
• Facilitation and coaching: events that people find useful, questions that open a conversationAsk good questions, listen, and say hard things kindly; most of the job is conversation. and handling conflict.
• The organisation around the team: stakeholders, managers, budgets, and scaling across many teams.
• Tools: a board in JiraSet up boards, workflows and simple reports in Jira so they show the work, without the tool running the team. or Azure DevOps, team pages in Confluence and a whiteboard such as Miro for remote workshops.

The Scrum Guide and the role

What does the 2020 Scrum Guide ask of a scrum master?

What they check: that you know the current Guide and see the role as accountable for effectiveness, not as a meeting organiser.

Short answer: "The 2020 Scrum Guide makes the scrum master accountable for the Scrum Team's effectiveness. The scrum master serves the developers, the product owner and the organisation: coaching self-management, helping the product owner with the product goal and the backlog, removing impediments and helping the organisation adopt Scrum. The Guide calls scrum masters true leaders who serve the team and the organisation."

The full answer: The 2020 edition replaced the old term servant leader with that wording, replaced roles with three accountabilities (product owner, scrum master, developers) and added the product goal as the commitment of the product backlog. In daily work the role is mostly invisible when it works: the team plans, inspects and adapts on its own, and the scrum master turns attention to the next obstacle, often outside the team.

A weak answer: "I organise the meetings and update the board." Follow-up: "What does self-managing mean?" The team decides who does what, when and how, within the sprint goal.

Walk through the Scrum events. Which one would you never let a team skip, and why?

What they check: that you know the purpose of each event, not only its name.

Short answer: "The sprint holds the other four. Sprint planning sets the sprint goal and the plan; the daily scrum checks progress toward the goal and adapts the plan; the sprint review inspects the increment with stakeholders and adapts the backlog; the retrospective improves how the team works. I would not let a team skip the retrospective, because it is how everything else gets better."

The full answer: Each event is a chance to inspect and adapt, and each has a time box: up to eight hours of planning for a one-month sprint, fifteen minutes for the daily scrum, four hours of review and three of retrospective, shorter for shorter sprints. An increment is a usable piece of the product that meets the definition of done. Teams that skip the review lose feedback; teams that skip the retrospective repeat their problems.

A weak answer: "The daily standup is the most important, so the manager knows the status." Follow-up: "The team says the events take too much time." Look at which events feel useless and why, and fix their purpose before shortening them.

Events that work

The daily scrum has become a status report to the manager. What do you do?

What they check: facilitation and the courage to change a habit with the people involved.

Short answer: "I remind everyone what the daily scrum is for: the developers check progress toward the sprint goal and adapt their plan. I talk with the manager first, privately, and offer another way to see progress, such as the board or the review. Then I help the team run it around the goal and the board, not person by person."

The full answer: Status reporting makes people defend themselves instead of helping each other. Walking the board from right to left, from almost done to not started, keeps the focus on finishing work. If the manager still needs information, find out what decision it serves and give it another way. Keep the daily scrum to fifteen minutes and move problem solving to after it.

A weak answer: "I ask the manager to stop coming." Follow-up: "The manager refuses." Ask them to observe silently for two weeks, and show what the team gains.

How do you run a retrospective that actually leads to change?

What they check: that retrospectives in your teams produce improvements, not complaints.

Short answer: "I vary the format so people stay engaged, make it safe to speak, look at facts from the sprint, and end with one or two concrete actions with an owner. The next retrospective starts by checking those actions. Fewer actions, finished, beat a long list."

The full answer: A useful shape is: set the stage, gather data, find causes, decide what to do, and close. Bring data where you can, such as cycle times or the number of times work was blocked. Watch who does not speak and give them other ways, such as writing first. Put the improvement on the product backlog or the sprint backlog so it gets done, and celebrate when it works.

A weak answer: "We use the same three questions every time." Follow-up: "The team is silent in retrospectives." Find out why, often one to one; it may be trust, a dominant voice or actions that never happened.

The product backlog and the definition of done

The product backlog is not ready for sprint planning, again. How do you help the product owner?

What they check: that you support the product owner without taking the backlog over.

Short answer: "I find out why: no time, unclear product goal, or stories too big to plan. Then I help with the cause: a regular refinement session with the developers, techniques to split stories, and a clear product goal to order the backlog against. The product owner stays accountable for the order."

The full answer: Refinement is ongoing work, often about a tenth of the team's time, to make the top of the product backlog clear and small enough to plan. A product owner overloaded with meetings may need help from management, which is the scrum master's work with the organisation. Coach the product owner on writing outcomes and acceptance criteria; never write the backlog for them.

A weak answer: "I write the stories myself so we can start." Follow-up: "The product owner is rarely available." Make the cost visible to the sponsor and agree a minimum presence.

What is a definition of done, and who owns it?

What they check: that you see the definition of done as a quality commitment, not a checklist on the wall.

Short answer: "The definition of done is the shared description of the quality an increment must meet: tested, reviewed, documented and integrated, for example. If the organisation has a standard, the team follows it at least; otherwise the Scrum Team creates its own. Work that does not meet it is not shown in the review and goes back to the backlog."

The full answer: A strong definition of done removes hidden work, such as testing or security checks left for later. Teams raise it over time, for example by adding automated release through CI/CDKnow why automated builds, tests and releases let a team deliver a usable increment every sprint., so that each increment could go to users. When several teams work on one product, they share one definition of done.

A weak answer: "Done means the developer has finished coding." Follow-up: "Testing always spills into the next sprint." Bring testing into the sprint and the definition of done, and plan less work until it fits.

Velocity, Kanban and flow

What is velocity for, and what goes wrong when managers compare it between teams?

What they check: that you use measures to help the team, and protect them from misuse.

Short answer: "Velocity is the amount of work, usually in story points, a team finishes in a sprint. It helps that team plan the next sprints. It means nothing between teams, because each team sizes differently; comparing it makes teams inflate their estimates and stops honest planning."

The full answer: Velocity is not in the Scrum Guide; it is a habit many teams use. If management wants to see progress, offer outcomes instead: sprint goals met, value delivered, lead time to users. Read the dataRead flow data, such as cycle time and work in progress, to start a useful conversation, not to judge people. for questions to ask the team, never for rankings of people.

A weak answer: "Higher velocity means a better team." Follow-up: "Velocity dropped by half." Ask the team: sick leave, harder work, more support, or estimates that finally became honest.

When would you use Kanban rather than sprints, and which flow measures do you watch?

What they check: that you know Kanban as its own way of working, not as Scrum without sprints.

Short answer: "Kanban suits work that arrives unpredictably, such as support or operations. I watch work in progress, how many items are started and not finished; cycle time, how long an item takes from start to done; throughput, how many items finish per week; and the age of open items. Limiting work in progress is what makes flow improve."

The full answer: Many Scrum teams use Kanban practices inside their sprints, and Scrum.org publishes a guide for exactly that. Little's law ties the measures together: more work in progress means longer cycle times. A cumulative flow chart shows where work waits. Start by making the work visible on the board, agree limits per column, and discuss the oldest items daily.

A weak answer: "Kanban is for teams that cannot plan." Follow-up: "The team ignores the limits." Ask what happens when a limit is hit; it is a signal to help finish work, not to start more.

Impediments, conflict and stakeholders

How do you deal with an impediment the team cannot remove itself?

What they check: that you work on the organisation, not only inside the team.

Short answer: "I make it visible, with its cost: how long work waits, how often. Then I go to the person who can change it, with a proposal, not just a complaint. I track it to the end and tell the team where it stands. Impediments the team can solve, I coach them to solve."

The full answer: Typical impediments outside the team are slow approvals, shared environments, missing access and other teams' dependencies. Keep a visible impediment list, group them by cause, and bring patterns to management. Some take months; leading without authorityLead without authority: coach, facilitate and change the system around the team. means building allies and showing results small step by small step.

A weak answer: "I escalate everything to the manager." Follow-up: "The impediment is the manager." Talk to them first, privately, with facts and an offer to help.

Two developers disagree openly in every refinement. How do you handle the conflict?

What they check: that you can help people through conflict without taking sides.

Short answer: "I talk to each of them alone first, to understand what is behind it. Then I help the team agree working agreements on how they decide, and in refinement I facilitate the disagreement on the facts: options, criteria, a small experiment. Some conflict is healthy; personal attacks are not."

The full answer: Conflict often has a cause in the system: unclear ownership, pressure, or different views of quality. Name what you see without blame, and give the quieter team members a voice so two people do not decide for all. If it turns personal and does not change, involve their line manager, because performance and behaviour are a line manager's job.

A weak answer: "I let the senior one decide." Follow-up: "One of them threatens to leave." Listen, take it seriously and include the line manager.

A stakeholder goes around the product owner and asks developers for work directly. What do you do?

What they check: that you protect focus and the product owner's accountability, with tact.

Short answer: "I thank the developers for raising it and speak with the stakeholder: their need is real, and the way to get it done is through the product owner and the product backlog. I invite them to the sprint review, where they can see progress and influence the backlog."

The full answer: Side requests often mean the stakeholder does not trust the process yet. Make the backlog and the review useful to them, and help the product owner explain the order. Working with stakeholdersHelp the product owner work with stakeholders: reviews they attend, and requests that go through the backlog. is mostly the product owner's job; the scrum master coaches it and protects the sprint.

A weak answer: "I tell the stakeholder to go away." Follow-up: "It is the CEO." Same principle, faster: bring the product owner in at once and decide together whether the sprint goal must change.

How does your team estimate, and what do you say when management wants a fixed date?

What they check: honest forecasting instead of promises.

Short answer: "The developers estimate, with story points, t-shirt sizes or by counting items. For a date, I help the product owner forecast from real data, as a range with a likelihood, and update it every sprint. If the date is fixed, we fix it and talk about scope."

The full answer: Forecasts from throughput, such as how many items the team finishes per sprint, are often as good as detailed estimates and much cheaper. Show what is likely by the date and what is not, and let the product owner order the backlog so the most valuable work comes first. A date promised without the team is a wish.

A weak answer: "We add up the story points and promise the date." Follow-up: "The forecast shows the date will be missed." Say so early, with options: less scope, a later date, or removing an impediment.

Scaling, remote teams and delivery

How do several teams work on one product, and what do you know about SAFe?

What they check: that you know the common ways to scale and judge them without dogma.

Short answer: "Several teams on one product share one product backlog, one product goal and one definition of done, and they integrate their work often. SAFe, the Scaled Agile Framework, groups teams into an agile release train that plans together in PI planning, a big-room planning event at the start of each program increment of about eight to twelve weeks. LeSS and Nexus are lighter ways to scale."

The full answer: In SAFe, the release train engineer plays the scrum master's part for the whole train. The framework suits large organisations that need many teams to plan together; critics find it heavy. Whatever the framework, the hard parts are the same: dependencies between teams, a shared integration and a product owner group that agrees one order.

A weak answer: "Scaling means more meetings." Follow-up: "Two teams keep blocking each other." Make the dependency visible, plan it together, and ask whether the teams are cut along the product the right way.

How do you run Scrum with a remote team spread over time zones?

What they check: that you can keep events, trust and focus alive without a shared room.

Short answer: "I agree core hours that overlap for the events, keep cameras and short time boxes, and move much of the talk into writing. Remote workshops use a whiteboard such as Miro, and the board in Jira or Azure DevOps is the shared truth. I check in one to one more often, because problems stay hidden longer."

The full answer: Rotate meeting times so the same people do not always join at night. Record decisions on team pages in Confluence. Meet in person a few times a year if possible, for planning or a retrospective, because trust built face to face lasts.

A weak answer: "Remote works the same as on site." Follow-up: "Half the team never speaks in remote events." Use writing first, smaller groups and direct invitations.

The team finishes its stories, but nothing reaches users for months. What do you do?

What they check: that you care about value delivered, not stories closed.

Short answer: "I map the path from done to the user and find where work waits: manual testing, release approvals, a separate operations team. Then I work with the team and the organisation on the biggest wait, often automated tests and releases through CI/CD, and a definition of done that ends at the user."

The full answer: A sprint review without anything usable is a demo, not a review. Measure lead time from idea to user and make it visible. Some waits are rules, such as change approvals in regulated companies; the aim is to meet them faster, not to skip them.

A weak answer: "Releases are not the scrum master's business." Follow-up: "Operations release once a quarter." Invite them to a review, and start with one small automated release together.

Senior scrum master, agile coach and head of agile transformation

These questions come up for senior scrum master, agile coach, enterprise agile coach and head of agile transformation roles, where the work moves from one team to many teams and their leaders.

As an agile coach, how would you help a whole department adopt agile ways of working?

What they check: that you can change an organisation with its leaders, not by rollout of a framework.

Short answer: "I start with why: what the department wants to improve, such as time to market or quality, and how we will know. Then I start small with willing teams and leaders, show results, and spread what works. Leaders change too: how they set goals, fund work and measure success."

The full answer: A transformation is mostly about structures and habits outside the teams: budgets fixed per project, approvals, career paths, how managers spend their time. An enterprise agile coach works with the leadership team on those, and grows coaches and scrum masters who carry the change. Measure outcomes, not the number of teams that "do Scrum".

A weak answer: "I would train everyone in Scrum and roll it out in three months." Follow-up: "The leadership team says yes but changes nothing." Make the cost visible, start with one leader who wants it, and show the result to the others.

Your CV for these questions

An interviewer will take any line on your CV and ask what the team looked like before and after. Write lines that answer that, each under the job where it happened:

Scoring your CV against a real scrum master job tells you which team changes the ad cares about, and which of them your CV still leaves unproved.