Scrum Master Interview Questions

"I started as a tester on a team that was always in a rush at the end of every sprint. I kept asking why we only found problems on the last two days, and I ended up running our retrospectives because nobody else wanted to. We changed a few habits, like testing stories as soon as they were ready, and the last-minute panic mostly went away. That was the moment I realised I liked fixing how a team works more than fixing individual bugs. I moved into the Scrum Master role on that team about two years ago. What keeps me here is watching a team get calmer and more predictable. Next I want to get better at coaching product owners and working with teams that depend on each other."

"From the job post and a talk one of your engineering leads gave, I understand you have several teams working on one shared platform and you moved to Scrum in the last couple of years. That tells me the interesting problems are probably between teams, like dependencies and shared releases, rather than inside one team. That's the part of my last role I enjoyed most. I helped three teams line up their planning so one team wasn't always waiting on another. I also noticed you release often, which I like, because it means the sprint review can show real user feedback and not just a demo. I'd want to learn early how your teams feel about Scrum today, because that decides where I'd start."

"The biggest one is that people don't change because the Scrum Guide says so. On my first team I explained why the daily scrum should be about the sprint goal, and nothing changed. What worked was asking the team what they wanted from those fifteen minutes and letting them redesign it. Once it was their idea, they kept it. The course also didn't prepare me for how much of the job happens outside the events, like a quiet chat with a manager who keeps adding work, or helping a new product owner say no. So now I spend less time teaching rules and more time asking questions and making problems visible, then letting the team decide."

"At my last company the team kept saying code reviews took too long. That had come up in three retros in a row, and each time we wrote 'review faster' and nothing happened. So in the fourth one I asked them to look at the data first. We pulled the last month of reviews and saw most of the wait was on large pull requests. The team agreed on one experiment: keep pull requests small and pick up any review within half a day. One developer volunteered to own it. We put the experiment on the sprint backlog so it was visible every day, and we checked it at the start of the next retro. Waiting time for reviews dropped a lot, and the team kept the habit."

"I'd start by reminding the team what the daily scrum is for: fifteen minutes for the developers to look at progress toward the sprint goal and adjust their plan for the next day. It's not a report to anyone. Then I'd try a different format, like walking the board from right to left and asking what's stuck, so the talk is about the work, not about each person. Detailed problem-solving moves to straight after, with only the people who need to be there. I'd also talk privately to the manager. Usually they just want to know how things are going, so I'd offer a clear board they can check anytime or a short update from me. That removes the reason for the long meeting."

"I'd first try to find out why, and the best way is a few quiet one-to-one chats. Usually it's one of three things. People don't feel safe saying what's wrong, the retros have become repetitive, or past actions never happened so it feels pointless. If it's safety, I might start with an anonymous input round and check who's in the room, since a manager's presence can change things. If it's repetition, I'd bring real data, like how the sprint actually went, or focus on one theme instead of the usual three columns. If it's no follow-through, I'd go back over the last few actions and get one of them done. Once people see a retro change something, they start talking again."

"Most of the work happens before the event. I make sure refinement has left the top of the backlog clear and sized, and that the product owner comes with a proposal for why this sprint matters. In the session we start with that why and turn it into a sprint goal the whole team agrees with, something like 'customers can reset their password without calling support'. Then the developers pick items that serve that goal, using their recent pace and their real capacity, so holidays and support duty are counted. Finally they break the first few days of work into smaller tasks. I watch for two things: a goal that's just 'finish these tickets', and a plan that ignores what happened last sprint."

"In my last role, every change to our test environment needed a ticket to a separate infrastructure team, and the wait was often three or four days. My team would finish a story and then sit waiting. I started by tracking how many stories were blocked and for how long, so I had facts instead of frustration. Then I met the infrastructure lead, not to complain but to understand their side. It turned out they had the same few people handling every team's requests by hand. Together we agreed that my team could manage its own test environment through a script they reviewed once. The waits disappeared for us, and they later offered the same setup to other teams."

"I joined a team that had missed its goal five sprints running, and management's view was that they needed to work harder. I looked at the board history first. Two things stood out. About a third of each sprint was going to unplanned support work, and most stories were too big to finish inside a sprint, so they carried over. In the retro I shared those findings and asked the team what they thought. We agreed to plan with the support load in mind, reserving capacity for it, and to split any story the team couldn't finish in a few days. The product owner also helped by bringing smaller slices to refinement. Within three sprints the team was hitting its goal most of the time, and the pressure from above eased once the numbers were visible."

"First I'd stop the team from switching straight away and bring the stakeholder and the product owner together, because priorities belong to the product owner. I'd ask a few questions: what exactly is needed, by when, and what happens if it waits until the next sprint, which may only be a week away. If it can wait, it goes to the top of the backlog. If it truly can't, the product owner and developers look at whether something can come out of the sprint without endangering the sprint goal. If the new request makes the goal pointless, the product owner can cancel the sprint, but that's rare. Either way, I'd make the cost visible, so everyone sees what was traded away."

"First, I'd hope we saw this before day three, because the daily scrum should show the goal slipping early. But right now the developers and the product owner should sit down and decide what's most valuable to finish, so we deliver as much of the goal as we can with real, done work. What I wouldn't allow is extending the sprint or cutting corners on the Definition of Done to make it look finished. Unfinished items go back to the product backlog and the product owner reorders them. In the sprint review we're honest with stakeholders about what didn't make it and why. Then in the retrospective we look at the cause, whether it was too much taken on, unplanned work, or a surprise, and pick one thing to change."

"We had a very experienced developer who answered every question in planning before anyone else could think. The juniors had stopped speaking up, and estimates were really just his estimates. First I changed how we ran things: silent estimation where everyone reveals at once, and in retros a few minutes of silent writing before anyone talks. That helped straight away. Then I spoke to him privately. I didn't tell him to talk less. I told him the juniors looked up to him, and that his biggest impact now would be helping them think things through. He liked that framing and started asking questions instead of giving answers. A few sprints later the juniors were leading some of the planning discussions."

"Early on I introduced a whole set of changes at once to a team that was new to Scrum: story points, a new board, a definition of done and a different retro format, all in one sprint. I thought I was being efficient. The team felt overloaded, and within a few weeks they'd quietly gone back to their old habits for most of it. When I asked them about it, one developer said it felt like rules being handed down. That stuck with me. Now I introduce one change at a time, ideally one the team has chosen, and we check whether it helped before adding the next. It's slower on paper but the changes actually last."

"I'd take them for a coffee and ask what's wasteful, because they might be right. Maybe planning runs two hours longer than it needs to, or the review is a demo nobody outside the team attends. I'd take the specific points back to the team and fix what we can, such as tighter timeboxes or a review with real users. At the same time, I'd explain what the team loses when they're missing: their knowledge in planning, and their view in the retro. Then I'd let the team discuss it in a retro and set their own working agreement about the events. Most people come back when the events improve and the team asks them to, not when the Scrum Master insists."

"I start with myself. When I get something wrong, like a badly run planning session, I say so in the retro and what I'll change. That makes it normal. In discussions I keep the focus on how the work happened, not who did it, so a missed deadline becomes 'what made this hard to see coming' rather than 'who dropped it'. I thank people when they raise bad news early, because that's exactly the behaviour we want. And I protect the team from outside blame. If a manager uses the sprint review to criticise someone publicly, I'll talk to that manager afterwards. It takes months to build and one bad moment to lose, so I'm consistent about it."

"The clearest sign would be that the team needs me less for the basics. They'd run their own daily scrum and even facilitate some retros, and they'd raise and remove most impediments themselves. I'd expect delivery to be more predictable, meeting the sprint goal most of the time, with fewer surprises in the review. The product owner should feel more confident saying no and explaining priorities. And I'd hope at least one problem outside the team, like a slow approval process, had been fixed for good. I'd also just ask the team and the product owner directly what I've helped with and what I haven't. If they can name specific things, that's a good sign. If I'm still running everything, I haven't done my job."

"We had a new product owner who'd come from a business role. The backlog had over two hundred items, all marked high priority, and planning kept stalling because nobody knew what mattered most. I didn't reorder it for her. Instead we sat together for an hour a week. First we wrote a clear product goal, then used it to sort items into 'serves the goal' and 'doesn't'. The second group went into a separate list she could revisit later. I also showed her how to split a large item into slices users could see. After a month she was running refinement herself, and planning took half the time because the top of the backlog was clear."

"For this sprint, I'd get whatever time I can with the product owner before planning, even thirty minutes, to agree the most important items and a sprint goal. I wouldn't let the team pick their own priorities without them, because then nobody owns the value. Then I'd find out why they're absent. Often the product owner is doing this on top of another full-time job, or has several teams. I'd show them what it's costing, like stories reworked because questions went unanswered. Then we'd agree a few fixed slots each week for refinement and questions. If they simply don't have the time, I'd raise it with whoever assigned them, because a team without a working product owner can't really do Scrum."

"A delivery manager wanted to set a velocity target and raise it every quarter, tied to the team's reviews. I could see that would push the team to inflate estimates and the numbers would stop meaning anything. I asked for a one-to-one and started by asking what he actually needed. It turned out he was being asked for release dates by his own boss and had no reliable way to give them. So I offered something better: a forecast based on the team's recent range of velocity, updated every sprint, plus a release burn-up he could show upward. He got his dates, the team kept honest estimates, and the target idea was dropped. He later asked me to set up the same view for another team."

"I'd explain that velocity can't be compared across teams. Each team sets its own scale for story points, so one team's thirty might be another team's ninety for the same work. If teams feel judged on it, points quietly inflate and the number stops being useful even for planning. Then I'd ask what they're really trying to find out. If it's which team needs help, I'd suggest things that are comparable, like how often teams meet their sprint goals, how long work takes from start to finish, how many defects reach users, and what the teams themselves say is blocking them. I'd also offer to run a short health check with each team so leadership gets a real picture, not a ranking."

"Velocity is the amount of work, usually in story points, that one team fully completes in a sprint. For forecasting, I'd look at the last several sprints and take a range, say the slowest few and the fastest few. If the remaining items add up to a hundred points and the team does between twenty and twenty-five a sprint, that's roughly four to five sprints, and I'd share it as a range with that caveat. It becomes unreliable when the team changes, when the backlog items are not estimated yet or keep growing, when people give partial credit for unfinished stories, and when velocity becomes a target, because then points inflate. I update the forecast every sprint as we learn more."

"I like a small mix across a few areas. For delivery, how often the team meets its sprint goal, and cycle time, which is how long an item takes from when work starts until it's done. For quality, how many defects escape to users and how much work gets reopened. For the people, a short health check every few sprints where the team rates things like clarity, pace and trust. And for value, whatever tells us users are actually better off, which usually comes from the product owner. I share these with the team first, as prompts for the retrospective, not as a scorecard. The moment a metric becomes a target for judging people, it stops telling the truth."

"A Scrum Team has a product owner, a Scrum Master and the developers, with no sub-teams or hierarchy inside it. The product owner is accountable for maximising the value of the product, which mainly means owning and ordering the product backlog. The developers are accountable for turning backlog items into a usable increment each sprint, owning the sprint plan and meeting the Definition of Done. The Scrum Master is accountable for the team's effectiveness, by helping everyone understand and use Scrum well and by removing impediments. Clashes usually happen at the edges. A product owner tells developers how to build something, a Scrum Master starts assigning tasks, or developers change priorities on their own. Most of my coaching is keeping those lines clear."

"The sprint is the container for everything, a fixed length of one month or less. It starts with sprint planning, where the team agrees why the sprint matters, what they'll deliver and how. For a one-month sprint that's at most eight hours, and shorter sprints usually need less. Every day there's the daily scrum, fifteen minutes for the developers to check progress toward the sprint goal and adjust their plan. Near the end comes the sprint review, at most four hours for a month-long sprint, where the team and stakeholders look at what was built and adapt the backlog. Then the retrospective, at most three hours for a month-long sprint, where the team looks at how they worked and picks improvements. Each event is a planned moment to inspect and adapt."

"There are three artifacts, and each one has a commitment that keeps it focused. The product backlog is the ordered list of what is needed to improve the product, and its commitment is the product goal, the longer-term objective the team is working toward. The sprint backlog is the sprint goal plus the items chosen for the sprint and the developers' plan for delivering them. Its commitment is the sprint goal, which gives the sprint a single purpose and some flexibility on the details. The increment is the usable work that's been added, and its commitment is the Definition of Done, so nothing counts as part of the increment until it meets that quality bar. The commitments are what stop each artifact becoming just a list."

"It means I lead by helping others succeed, not by telling them what to do. The current Scrum Guide phrases it as a true leader who serves the team and the wider organisation. In practice that's coaching the team to manage itself, helping the product owner with the backlog, removing impediments, and working with the organisation so Scrum can actually work there. What it doesn't mean is being the team's assistant, booking every meeting and updating every ticket. If I do all that, the team never learns to own its own process. It also doesn't mean being a manager in disguise, assigning tasks or deciding estimates. A good test for me is whether the team would keep working well if I went on holiday for two weeks."

"The Definition of Done is one shared quality standard that applies to every item the team delivers. It might say code is reviewed, tests pass, it's deployed to a test environment and the user documentation is updated. Acceptance criteria are specific to one backlog item. They describe what that particular story has to do, like 'the user gets an email within a minute of resetting their password'. So acceptance criteria answer 'did we build the right thing for this story', and the Definition of Done answers 'is it built to our quality bar'. An item is only done when it meets both. If a story passes its acceptance criteria but hasn't been tested the way the Definition of Done requires, it isn't done. It can't be part of the increment or shown at the review, and if the sprint ends that way it goes back to the product backlog."

"Only the product owner has the authority to cancel a sprint, and it should only happen when the sprint goal becomes obsolete. For example, the company decides to drop the feature the sprint was building, or a change in regulation makes the planned work pointless. It's not a tool for a sprint that's going badly or a stakeholder who wants something else, because then you're just throwing away focus. When it does happen, any done work is reviewed and can still be released, the unfinished items go back to the product backlog, and the team plans a new sprint. Cancelling is costly for the team's morale and rhythm, so in my experience it's very rare. I've only seen it once."

"Scrum works in fixed-length sprints with a sprint goal, three accountabilities and a set of events. Kanban has no sprints and no required roles. Work flows through the board continuously, the team limits how much is in progress at each stage, and they manage flow using measures like cycle time and throughput. I'd suggest Kanban when work arrives unpredictably and has to be handled quickly, like a support or operations team, where planning two weeks ahead doesn't make sense because priorities change every day. For a team building a product toward a goal, Scrum's rhythm of planning, review and retro is usually worth it. It's also not either-or. Plenty of Scrum teams use Kanban practices, like limits on work in progress, inside their sprints."

"Scaling frameworks try to solve one problem: many teams working on the same product need to plan together, manage dependencies and integrate their work often. In SAFe, several agile teams form an Agile Release Train. Once every planning interval, usually eight to twelve weeks, the whole train meets for PI planning, often over two days, where teams agree objectives and map dependencies. A Release Train Engineer coaches and coordinates the whole train, a bit like a Scrum Master at train level, and the teams show their integrated work in a system demo. At team level the role is now called Scrum Master or Team Coach. It still coaches its own team and helps it take a real part in train planning. SAFe can help a large organisation line up, but it adds a lot of process, so lighter options like Nexus or LeSS are worth comparing first."