Questions to Ask in a Scrum Master Interview
For scrum master and agile coach candidates at the point where the hiring manager, product owner or team asks whether you have anything to ask them. The 49 questions are grouped the way that decision usually unfolds: the role and the teams you would serve, how agile is really practiced, the product owners and managers around the seat, your reach when something blocks a team, how success is judged, and four for the last minutes. Under every question is a note on how a healthy answer differs from a worrying one for a scrum master, often with the follow-up to use.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Role and teams
How many teams would I be serving, and are they all working on the same product?
Why ask it
One or two teams leaves room to coach, and four or five usually means running events back to back and little else. Teams on separate products also bring separate product owners and backlogs, so the count alone can undersell the load. If the answer is 'it depends', ask how many the last scrum master had.
Why did the last scrum master leave, or is this the first time the teams have had one?
Why ask it
If they went on to coach more teams, the role leads somewhere here. If they went back to development or left within the year, ask what wore them down, since it has probably not gone away. For a first scrum master, ask whose idea the role was and whether the teams had a say in it.
How long has each team been doing Scrum, and how mature would you say each one is?
Why ask it
The answer decides whether the job is teaching the basics, coaching a settled team or shaking loose one that is going through the motions. An interviewer who can tell the teams apart has been watching them. 'They are all pretty agile' usually means nobody has looked closely, so ask what the strongest team does that the weakest does not.
What problem are you hoping a scrum master will solve for these teams?
Why ask it
Listen for something you could picture: stories that spill over every sprint, retrospectives that produce nothing, a reorganization, a framework rollout. That problem is your real brief, and if you meet the team it is worth hearing whether they would name the same one. 'The framework says every team needs one' is a thinner reason and leaves you to guess what anyone hopes will change.
What would a typical week look like for the scrum master on these teams?
Why ask it
The events are the fixed part, so pay attention to what fills the rest. Time spent watching how a team works and talking with people one to one is a coaching week. Booking rooms, chasing ticket updates and building status slides is a coordinator's week, and it is fair to ask whether that is the intention or just how the job has drifted.
Is this a full-time scrum master role, or is it combined with another job such as developer, analyst or project manager?
Why ask it
Split seats are common, and they change the job more than the title shows. Ask what share of the week each half gets and which one wins when they collide. A scrum master who also owns the delivery plan will be pulled toward the plan.
Who has been facilitating the events while the seat has been empty?
Why ask it
Whoever it is, a developer, the product owner or a manager, has habits the team is now used to. If a manager has been running the retrospectives, expect the team to have been careful about what they say in them. Ask whether that person wants to keep any part of it, so you do not open by taking something away from them.
Are the teams stable, or do people move between them as projects start and finish?
Why ask it
Coaching builds on a group that stays together long enough to change its habits. Where people are reassigned every few months, much of your work restarts each time. How long one team's current line-up has been together is the number to get.
Are the teams in one place, remote, or spread across time zones, and how do the events run because of it?
Why ask it
This is what facilitation will mean day to day: a room with a wall, or a video call with a shared board. With several time zones, ask what time the daily scrum happens and who is up early or late for it. Hybrid often takes the most care, with half the team in the room and half on a screen.
What do the teams build, and how technical do you expect the scrum master to be?
Why ask it
Some employers want a facilitator who can follow the conversation. Others want a former engineer who can spot a weak build pipeline. Neither is wrong, but a gap between what they expect and what you bring is better found now than in your third week.
Agile in practice
Which parts of Scrum do the teams follow closely, and which have been changed or dropped?
Why ask it
Every organization adapts something, so listen for whether each change was a decision or a drift. 'We stopped holding sprint reviews because stakeholders are busy' is the kind of detail that shows where the work would start. Keep your tone curious, because the same question asked as an inspection gets a defensive answer.
Do you use a scaling framework such as SAFe, LeSS or Scrum@Scale, and how closely do you follow it?
Why ask it
A scaling framework usually adds to a scrum master's calendar: planning events across many teams, extra sync meetings, sometimes a role above the team. Ask what it puts into an ordinary week here and who you would answer to inside it. If your experience is with single teams, say so and ask what training comes with the role.
How long are the sprints, and does a sprint usually end with something that could be released?
Why ask it
Length is the easy half. The second half shows whether a sprint produces finished work or is a two-week slice of a longer plan. When testing or release happens in a later phase, the follow-up is who owns that phase and whether the team wants to bring it inside the sprint.
Who attends the daily scrum, and who does most of the talking?
Why ask it
Developers talking to each other about the sprint goal means the event is doing its job. Each person reporting in turn to a manager, or to the scrum master, means it has become a status meeting. Changing that is delicate work, because someone senior probably likes it the way it is.
What came out of the last retrospective, and has it been acted on?
Why ask it
A concrete action that someone followed through is about as good a sign as an interview can give you. 'I am not sure, I do not attend' is a fair answer from a manager, and often a healthy one. Retrospectives that were dropped, or that produce the same list each time, are likely where your work begins.
Do the teams have a definition of done, and does work that is called finished actually meet it?
Why ask it
Ask what is on it. Testing, review and deployment on the list mean 'done' can be trusted. A list that stops at 'code complete' means unfinished work is collecting somewhere out of sight, and no written definition at all is a simple early project for you.
When urgent work turns up in the middle of a sprint, what happens to it?
Why ask it
You are listening for a route: it goes to the product owner, something comes out to make room, the team agrees. The worrying version is that it simply gets added, usually by whoever asked loudest. How often it happened last sprint tells you whether it is the exception or the routine.
Are the teams working toward fixed dates and fixed scope, and who made those commitments?
Why ask it
Fixed dates are ordinary. Fixed dates and fixed scope together, promised by someone who never asked the team, leave a scrum master little to work with. A reassuring answer includes what was dropped the last time a date had to be met.
Who outside the team sees velocity, and what do they do with the number?
Why ask it
Velocity is a planning aid for the team that produces it. Once it is compared across teams or set as a target, estimates tend to grow to fit, and you would be the one asked why the number dipped. The healthy answer is that leadership looks at what shipped and leaves the points to the team.
Which tool holds the backlog and the board, and who is expected to keep it tidy?
Why ask it
Jira, Azure DevOps or a wall of cards matters less than who does the upkeep. If the scrum master moves the tickets and builds the burndown chart for a steering meeting, the board has become yours and not the team's. Check too whether a team can change its own workflow or whether that is set centrally.
Where did the move to agile come from: leadership, the teams themselves, or an outside consultancy?
Why ask it
Where it started tells you who will back you when a change gets uncomfortable. An adoption the teams asked for has energy but may lack cover from above, and one ordered from the top has cover but may be resented. It also helps to know how long it has been going and whether anyone senior still owns it.
People
Does each team have its own product owner, and how many hours a week do they spend with the team?
Why ask it
A product owner who shares the team's week can answer questions as they come up. One spread across four teams, or a senior manager holding the title, leaves developers guessing and the scrum master filling the gap. If the product owner is on your panel, ask them directly how their time is split.
How do the product owner and the scrum master divide the work today: who runs refinement, and who writes the stories?
Why ask it
The textbook split and the local one are rarely the same, and the local one is what you would inherit. If the last scrum master wrote stories and ordered the backlog, the product owner may expect that to continue. Decide before the interview whether you would take that on for a while or want to hand it back.
How much say does the product owner have over the backlog, and who can overrule them?
Why ask it
The team needs one voice on priority. When a steering group or a sales director reorders things over the product owner's head, priorities move mid-sprint and you spend your time absorbing it. Ask for the last time the product owner turned something down and it stuck.
Who would I report to, and what do they think a scrum master is for?
Why ask it
Reporting into an agile practice, into engineering or into a project office each pulls the role a different way. A boss who sees a coach will judge you on how the team changes, and one who sees a coordinator will judge you on dates. If that person is on the panel, have them describe a scrum master they rated highly.
Do the developers have line managers, and how do those managers work with the scrum master?
Why ask it
Line managers usually hold reviews, pay and promotion, so when their message differs from yours the team will follow theirs. A good answer describes regular contact and an agreed split: the manager handles people matters and stays out of the sprint. Managers who assign tasks or sit in retrospectives are not a deal-breaker, as long as that is open to discussion.
Is there a project manager or delivery manager working alongside the teams, and where does that job end and the scrum master's begin?
Why ask it
The two can sit together well when one looks outward at budgets and dates and the other at how the team works. Trouble starts when both think they run the sprint. A quick test is to ask who chairs sprint planning today.
Do stakeholders come to sprint reviews, and what do they do there?
Why ask it
Stakeholders who turn up and react to working software are giving the team what the review exists for. An empty room, or slides presented to people who nod, means feedback arrives late and by other routes. Changing that takes someone senior on your side, so find out who that would be.
How do the developers themselves feel about Scrum and about having a scrum master?
Why ask it
A team that asked for the help is a different assignment from one that sees the events as overhead imposed on it. Skepticism is workable, and often earned by a bad experience with a previous process or person. Learn what that experience was so you do not repeat it in your first month.
Are there other scrum masters or agile coaches here, and how often do you get together?
Why ask it
A group of scrum masters gives you somewhere to take a problem you cannot discuss with your own team, and an impediment that several of them raise together carries more weight. Ask what the group last got changed, which says more than how often it meets. If you would be the only one, ask who you could think out loud with.
Impediments
What is the biggest impediment the teams face right now, and how long has it been there?
Why ask it
A named blocker, such as a shared test environment or a monthly release window, shows the interviewer knows what the teams' days are like. Its age is the useful part: something that has stood for two years has outlasted other people's attempts, so ask what was tried. 'Nothing major' more often means impediments are not being raised than that there are none.
When a scrum master raises a problem the team cannot fix by itself, who takes it and what usually happens?
Why ask it
The answer should have a person in it and a story with an ending: what was raised, who picked it up, how long it took. If the path is 'take it to your manager' and nobody can recall a result, the role carries responsibility without reach.
What could I change in how a team works without asking anyone, and what would need sign-off?
Why ask it
Try it with examples: sprint length, the format of the retrospective, the columns on the board, who attends the daily scrum. Where much of that needs approval, the approver is in effect part of every team's process and someone you would need to know well. Freedom inside the team with firm rules outside it is a common and workable answer.
If a retrospective action needs time or money, where does that come from?
Why ask it
Many improvements cost something: a day to fix the build, a license, an hour from someone outside the team. A team that can put its own improvement work into the sprint, or a manager with a small budget for it, can make a retrospective count. If every action has to compete with features in the backlog and usually loses, you know why the retrospectives have gone flat.
How much do the teams rely on other teams, vendors or shared specialists to finish a piece of work?
Why ask it
Waiting on someone else is a common reason a sprint ends with work unfinished. A team that needs a database group, a security review and an outside supplier for most stories cannot finish on its own schedule however well it works. Find out who coordinates those hand-offs today and whether that would become your job.
If a manager or stakeholder goes around the product owner and hands work straight to a developer, what would you expect me to do?
Why ask it
Their answer shows whether you would be backed in a conversation with someone senior. 'Talk to them, and I will support you' is what you hope to hear. 'That is just how things work here' at least shows you the limit of the role before you take it.
Would I be expected to coach people outside the teams, such as managers, stakeholders and leadership?
Why ask it
Scrum describes a role that reaches into the wider organization, while many employers mean the team and nothing beyond it. Either can suit you if it matches what you want from the job. Where the answer is yes, check whether those managers know they are to be coached.
Success
How is a scrum master's performance judged here, and by whom?
Why ask it
Good answers describe the team: more finished each sprint, fewer surprises, people speaking up, a product owner who trusts the forecast. Weak ones describe you being busy, such as events held and reports sent. When the reviewer is not close to the teams, ask where their picture of your work would come from.
Is the scrum master held accountable for delivery dates or for the team's velocity?
Why ask it
It is blunt, and the answer changes the job, so ask it plainly. Being answerable for dates makes you a project manager under another title, which may or may not suit you. If the answer is yes, the next question is what authority over scope and staffing comes with it.
When a team does not finish what it planned for a sprint, who asks about it, and what happens next?
Why ask it
On a healthy team the question comes up in its own retrospective and the next plan is smaller or better prepared. If a manager wants an explanation, or wants it from you, misses start to be hidden: stories split on the last day, estimates padded. Ask about the most recent time, not the policy.
What would you want to be different about the teams after my first 90 days?
Why ask it
Something observable, like sprint goals that are met or a review that stakeholders attend, points to a realistic employer. If they expect a transformed team in three months, say what you think is achievable in that time. How they take a candidate setting a limit is a preview of working for them.
Think of a scrum master who did well here. What did they change?
Why ask it
A real person and a real change show what the organization rewards. Notice whether the praise is for a team that grew or for someone who kept the reports in order. If nobody comes to mind, the role may be too new here, or too little noticed, to have a model yet.
If a team reached the point where it needed me much less, what would happen to my role?
Why ask it
A scrum master who does the job well makes a team more independent, and you want an employer who counts that as success. Good answers mention moving to a newer team, taking on more teams or coaching at a wider level. Hesitation matters most when the post is a contract or tied to a single project.
What have scrum masters here gone on to do?
Why ask it
Agile coach, release train engineer, product owner and people manager are the usual directions, and which of them exist depends on how the organization is built. Ask about one person who made a move and how long they had been a scrum master first. Where the role is new or filled by contractors, ask what a second year in the seat would look like.
Is there a budget and time for training, certifications or conferences?
Why ask it
Scrum certificates come from several bodies and some have to be renewed, so name the one you hold or plan to take and ask whether fees and renewals are covered there. The time matters as much as the money, since a budget nobody has a free week to spend is not worth much. If they use a scaling framework, ask whether its own certificate is expected and who pays for that.
Closing
Could I sit in on a sprint event or meet the team before I decide?
Why ask it
Half an hour at a daily scrum or a sprint review shows you how the people on the team talk to each other, which nobody can describe for you accurately. How they behave with a visitor in the room is information too. If it cannot be arranged, ask for a short call with one developer and the product owner instead.
What would the developers say is the most frustrating thing about how work reaches them?
Why ask it
It asks the interviewer to take the team's side for a moment, and how easily they manage it says a lot about how closely they listen. Late changes, unclear stories and too many things in progress are the usual replies. Put the same question to the team if you meet them and compare.
Having heard my answers, where do you think I would struggle with these teams?
Why ask it
For this role the doubt is often a non-technical background, no experience at scale, or having worked in only one framework. Give one example that speaks to it and leave it there. The panel also sees how you take feedback, which is a fair part of what they are hiring.
What are the next steps, and is there a practical round, such as facilitating a session, that I should prepare for?
Why ask it
Some employers ask scrum master candidates to run a mock retrospective or talk through a case, and others decide on conversation alone, so ask what this process includes. For an exercise, find out who plays the team and how long you get. Ask as well whether the developers or the product owner have a say in the choice: a team that helped pick its scrum master tends to start out more open to being coached.
How to use your questions in a scrum master interview
Practical guidance for the conversation itself
Before the interview
Decide which version of the job you want
The title is given to a team coach, to a facilitator who books the events and keeps the board, and to a delivery lead who answers for dates. Decide beforehand which of those you would take and on what terms: plenty of scrum masters will own dates if scope is theirs to negotiate, or share the seat with development work on a team they like. Then pick the four or five questions whose answers would move you across that line and ask those first. The others are there for later rounds and for the team.
Know who on the panel can answer what
Scrum master panels often mix roles, and each knows a different part. The hiring manager can say why the seat was created, who it reports to and what a good year in it looks like. A product owner knows the backlog. Developers know what the events feel like and whether the last retrospective changed anything. The recruiter is the one to ask about the timetable, and about pay, contract length and working pattern, which differ by employer and place: ask how each is handled there. One question earns asking twice: put how the product owner and scrum master divide the work to the manager and to the product owner, and compare the two accounts.
Start from what the posting already says
If the posting names SAFe, Jira or a certificate, asking whether they use it wastes a turn. Ask the next question down: how closely the framework is followed, who keeps the board, whether the certificate is paid for. Look at the employer's other open roles as well. Several scrum master and coach postings at once can mean a rollout is under way, and that is worth raising, because it changes what your first year would be.
In the room
Your questions are a sample of your work
Much of a scrum master's craft is asking an open question and then listening, and the panel is watching for it. 'Do you hold retrospectives?' gets a yes. 'What came out of the last one?' gets a story. After the answer, give back one sentence of what you heard before moving on. It checks your understanding, and it is what you would be doing with their team.
If time is short, ask for one sprint
Ask the interviewer to tell you about one team's most recent sprint from planning to retrospective: what was planned, what arrived in the middle, what was finished, who came to the review. A single account covers sprint length, interruptions, the definition of done and the product owner's part, which is most of Agile in practice. The place where the telling goes vague, often the review or the retrospective, is where your next question belongs.
Speak to the developers directly
When developers are on the panel, put a question to them and not through the manager: what they would want a scrum master to take off their hands, or what they hope you would leave alone. Notice whether they answer freely or glance at the manager first. That glance says more about how safe it is to speak up than any question about culture would.
Ask how it came about
You will hear things the Scrum Guide would not recognize: a daily scrum run by a manager, sprints with no review, velocity on a leadership dashboard. Each has a history, and 'How did that come about?' gets you the history. A correction would get you nothing, and it would show the panel how you might treat the team on your first day.
Reading the answers
Weigh three answers together
How many teams, whether you answer for delivery dates, and whether anyone acts when a scrum master escalates: those three shape the job more than anything else on the list. One awkward answer among them is ordinary. Four teams, accountability for dates and an escalation path nobody can illustrate add up to a job that would be hard for anyone to do well, and that is easier to see before an offer than after.
Separate team problems from organization problems
Flat retrospectives, stories that spill over and vague backlog items are team-level problems, and they are what a scrum master is hired for. Scope and dates fixed elsewhere, managers who assign tasks and escalations that go nowhere sit above the team. Those can change too, but only when someone senior wants them to. For each one you heard, check whether anyone named that person.
Notice what they count
Through the whole conversation, listen for what the interviewers measure. Talk of story points completed, events held and hours logged points to a role judged on activity. Talk of what users received, how long work takes to finish and whether teams raise problems points to one judged on how the teams change.
Mistakes to avoid
Asking in slogans
Questions about 'psychological safety', 'servant leadership' or 'an agile mindset' get slogans back, because few employers would say no to any of them. Ask about an occasion: the last sprint goal that was missed, or the last time a developer disagreed with a manager in a retrospective. What happened next is the culture.
Refereeing the panel
Sometimes two interviewers answer the same question differently, often about who owns refinement or who the scrum master answers to. Do not settle it for them or pick a side. Say you would be glad to hear more about that once you had started, and make a note: it may well be where the work begins.
Skipping the two awkward questions
Why the last scrum master left, and whether you would be held to delivery dates, are easy to leave out because they feel impolite. Both are ordinary things for someone weighing a job to ask, and they are the two most likely to tell you something you could not learn another way. Ask them plainly and early enough that there is time for a full answer.