44 Scrum Master Interview Questions, Grouped by What They Actually Test

Courage, focus, commitment, respect, and openness. Candidates who've actually used these values on a real team give specific answers instead of generic ones: "focus meant we had a team agreement that nobody took on ad-hoc requests mid-sprint without routing them through the Product Owner first, and it took about two months to hold that line consistently."

Generic answers, "we value respect and communication," tell an interviewer nothing they didn't already assume. Specific answers show the value actually shaped a real decision at some point.

Fifteen minutes, timeboxed, regardless of team size. A Daily Scrum that consistently runs 25 or 30 minutes usually means it's turned into a problem-solving session instead of a synchronization point. That's not automatically bad work. It's just the wrong meeting for it.

The fix is rarely "enforce the timer harder." It's redirecting problem-solving conversations to a smaller follow-up right after, with just the people who actually need to be in it, so the full team isn't sitting through a debugging session that only concerns two people.

A status demo shows what got built. A Sprint Review inspects the increment against the Sprint Goal and actively adjusts the Product Backlog based on stakeholder feedback in the room. The difference shows up in what happens after: a status demo ends with applause. A real Sprint Review often ends with the Product Backlog looking different than it did an hour earlier.

If a team's Sprint Reviews never change the backlog, that's worth naming directly in an interview rather than describing the ceremony as if it's working. It usually means stakeholders are watching passively instead of actually engaging with what they're seeing.

A shared, team-owned standard for what "complete" actually means, tests written and passing, code reviewed, deployed to staging, whatever the team has agreed to. The Scrum Team owns it collectively, not the Scrum Master alone and not just the developers.

The follow-up worth being ready for: what happens when a story is "done" by the team's own definition but a stakeholder still isn't satisfied. That's usually a sign the Definition of Done itself needs revisiting, not a sign that "done" is a flexible word.

The Product Backlog is the full, ordered list of everything that might ever be worth building, owned by the Product Owner. The Sprint Backlog is the subset pulled into the current sprint plus the plan for delivering it, owned by the Developers. One is a long-term list with a Product Goal attached. The other is a short-term commitment with a Sprint Goal attached.

Ask what specifically feels wasteful before defending the ceremony. Often the real complaint is that it's turned into a status report to the Scrum Master or manager rather than a team synchronization point, in which case the fix is changing how it's run, not convincing the person the ceremony matters in theory.

Occasionally the complaint is legitimate: a team with tight pairing and constant messaging genuinely needs less formal sync than a team that barely talks otherwise. Dismissing the feedback outright is worse than taking it seriously and adjusting the format.

Be specific about the difference between using a board someone else set up and actually configuring workflow states, automation rules, and custom fields yourself. "I've configured Jira workflows including a custom blocked state with automated notifications" tells an interviewer something real. "I've used Jira" doesn't distinguish you from anyone who's ever had a corporate email address.

A visible impediment log, a dedicated Jira board, a shared doc, even a physical board in the team room, with an owner, a date raised, and a status for each one. The specific tool matters less than the habit of writing it down the moment it surfaces rather than trusting memory across a two-week sprint with a dozen other things competing for attention.

A log also does something a mental list can't: it makes patterns visible over time, the same category of impediment recurring across three sprints is a much stronger case for organizational escalation than one person's recollection that "this keeps happening."

"What's the biggest impediment the team I'd be supporting is currently facing?" tends to get a more candid answer than "what's a typical day like," since it's harder to give a rehearsed, glowing response to a question that specific.

How honestly the interviewer answers tells you almost as much as what they say. Someone who names a real, specific problem is showing you the job as it actually is. Someone who deflects into generalities is worth noticing too, ideally before you accept an offer rather than after.

It flips the usual management model. Instead of directing the team, the Scrum Master's job is to remove whatever is slowing them down and let them figure out the how. That sounds soft, but in practice it means doing the unglamorous work nobody else wants to touch: chasing down a broken CI notification instead of telling a developer to fix it themselves, sitting quietly in the back of planning instead of running it, or spending an afternoon negotiating with a stakeholder so the team can keep two uninterrupted days to finish a feature.

It doesn't mean being passive. A servant leader still calls out a problem directly, still pushes back on a Product Owner who's about to overload the sprint, and still holds the team accountable to its own commitments. The difference is the lever you pull. You're not issuing instructions from a position of authority, you're using trust, facilitation, and removing friction to get the same outcome. If a Scrum Master can't point to concrete things they did last sprint to make someone else's job easier, they're probably running the role as a project manager with a different title.

The Product Owner owns the what and the why. They decide what goes into the backlog, in what order, based on value to the business and to users, and they're the one who accepts or rejects finished work. The Scrum Master owns the how the team works: facilitating events, coaching the team on process, and clearing blockers. Neither one manages the other, and neither one tells developers how to build something technically.

Where it gets messy is mid-sprint. A PO wants to swap in an urgent item, the Scrum Master's job is to protect the sprint boundary and make the tradeoff visible, but the final call on priority still belongs to the PO, not the Scrum Master. In smaller companies these roles blur constantly, especially when the PO also has formal authority over the team's headcount or reviews. That's when a Scrum Master really earns their keep, because a PO with positional power can quietly override the whole point of having a protected, self-managing team.

Refinement, sometimes still called grooming, is the ongoing work of taking backlog items and adding enough detail, acceptance criteria, and rough sizing that they're actually ready to be pulled into a sprint. It's not in the Scrum Guide as a formal event because it's meant to be a continuous activity, not a fixed ceremony with a set day and time. Teams decide their own cadence, some do a standing weekly session, others refine a little at the end of every daily scrum.

A typical session is time-boxed, often around 5 to 10 percent of the sprint's capacity, and the PO brings candidate items while the team asks questions, splits anything too large, and flags unknowns that need a spike first. Skip this step consistently and Sprint Planning turns into a two-hour argument where the team is discovering scope and unknowns for the first time, which is the single most common reason planning sessions run long.

A user story is usually written as "As a [user], I want [goal], so that [benefit]," but the format matters less than what it represents: a placeholder for a conversation, not a finished spec. The real detail lives in the acceptance criteria and the discussion that happens during refinement, not in the one-liner itself.

INVEST is a quick gut check teams run before pulling a story into a sprint: Independent, Negotiable, Valuable, Estimable, Small, and Testable. A story that fails Independent because it depends on two other unfinished stories is a common trap, the team pulls it in, works on it in parallel, and then nothing can actually be marked done until the last dependent piece lands, which quietly wrecks the sprint's flow even though every individual task looked fine on the board.

Scrum organizes work into fixed-length timeboxes with defined roles and events: Sprint Planning, Daily Scrum, Review, Retrospective. Kanban has none of that structure by default, it's a continuous flow model where items get pulled as capacity opens up, and the main control mechanism is a work-in-progress limit rather than a sprint boundary.

Scrum's rhythm of commit, build, and review fits teams that need a predictable release cadence and a regular checkpoint with stakeholders. Kanban fits teams whose work is interrupt-driven and unpredictable, support queues, platform on-call, incident response, where committing to a two-week batch of work doesn't make sense. Plenty of teams end up running a hybrid, often called Scrumban: they keep the daily standup and a shared backlog but drop the sprint boundary and manage flow with WIP limits instead. A Scrum Master can absolutely carry the role over to a Kanban team, the title just becomes more about flow facilitation than sprint facilitation.

Definition of Ready is a short checklist applied before a story enters a sprint: acceptance criteria written, dependencies identified, and the story small enough to realistically finish within the sprint. Definition of Done is applied at the other end, after the work: code merged, tests passing, deployed to the right environment, documented if needed. One gates entry, the other gates exit.

The point of a DoR is to stop the team from pulling in half-formed work that turns into a scramble mid-sprint. The common mistake is making it so strict that refinement takes almost as long as building the feature would, at which point it's defeating its own purpose. It should be a lightweight guardrail the team can check in thirty seconds, not a full specification document.

A project manager owns the plan and the timeline. A Scrum Master owns the process and the team's ability to improve that process, which is a different job even when the day-to-day tasks look similar from the outside. A project manager asks "are we on schedule?" A Scrum Master asks "why are we consistently not on schedule, and what needs to change?" One is directive. The other is diagnostic.

The weak answer defines both roles in isolation, a dictionary-style comparison that never actually distinguishes them in practice. The stronger answer names the accountability gap directly and gives one concrete example of a decision each role would make differently given the same situation.

Sprint Planning sets the Sprint Goal and pulls in the work meant to achieve it. The Daily Scrum is a 15-minute synchronization point so the team can adjust its plan for the day, not a status update where each person recites yesterday's tasks. The Sprint itself is the container event holding all the others. Sprint Review inspects the increment with stakeholders and adjusts the Product Backlog based on what was learned. Sprint Retrospective inspects the team's own process and commits to at least one real change for the next sprint.

Most candidates can list all five. Fewer can explain the purpose behind each one, and describing the Daily Scrum as "everyone says what they did yesterday" is a quiet signal that a candidate has been running it wrong for a while.

Transparency, inspection, and adaptation, straight from the Scrum Guide. Transparency means the process and the work are visible enough that inspection is actually meaningful, a Sprint Backlog nobody updates isn't transparent even if it technically exists somewhere. Inspection happens at the Sprint Review and informally throughout the sprint. Adaptation is what the Sprint Retrospective exists to produce, at least one concrete change the team commits to trying.

The connection candidates miss most often: without real transparency, inspection just produces false confidence, and without genuine inspection, adaptation is just guessing. The three pillars aren't independent checkboxes. Each one depends on the one before it actually working.

Sprint Planning exists to produce a Sprint Goal the whole team can commit to, then figure out the work that achieves it. Teams that skip straight to "what tickets are we pulling in" end up with a pile of tasks and no shared answer to why the sprint matters. When priorities shift mid-sprint, and they always do, a team with a real Sprint Goal can ask whether the change still serves the goal. A team without one just reacts to whoever's loudest that day.

A team that consistently over-commits during planning is usually solving the wrong problem by cutting the meeting shorter. The actual fix is almost always slower, more honest capacity conversations, not a faster planning ritual.

A specific, owned action item that the team actually revisits next sprint. A bad retrospective produces a list of complaints that evaporates the moment everyone leaves the room. The difference isn't the format, Start-Stop-Continue works fine, so does a Mad-Sad-Glad board, it's whether anything from the last retro gets checked at the start of the next one.

A useful habit candidates rarely mention unprompted: opening every retrospective by reviewing the action item from the previous one. It takes ninety seconds and it's the single easiest way to keep a retro from becoming theater.

A Sprint Goal is a single, coherent objective the Sprint Backlog is meant to serve, not a list of unrelated tickets that happened to fit into two weeks. Sprints without one tend to underperform because when priorities shift mid-sprint, and they always do, there's no shared reference point to test the change against. Everything becomes negotiable, all the time.

A concrete example helps more than a definition here: "ship the ability for a customer to export their own data" is a Sprint Goal. "Finish these 14 tickets" is a task list wearing a Sprint Goal's clothes.

Not unilaterally, and pretending otherwise in an interview is a red flag. The Scrum Master's real move is making the tradeoff visible: if new scope comes in, something else comes out, or the Sprint Goal itself is at risk, and that's a conversation the Product Owner needs to have with the team and with whoever's asking for the change.

What a Scrum Master can and should stop is scope changes that bypass the Product Owner entirely, someone walking straight up to a developer and asking for "just one small thing." That's a process violation, not a legitimate scope negotiation, and it's worth answering the question with that distinction explicit.

"I'd have a conversation with them" is the answer interviewers hear from candidates who haven't actually done this. The better starting point is figuring out whether the issue is capacity, a skill gap, a confidence problem, or something personal, since each one needs a completely different response. If it's a team-wide velocity calibration issue, the whole team over-committing, addressing one person is the wrong intervention entirely.

Name what you'd actually do in week one: a private, one-on-one conversation focused on understanding rather than feedback. Then name what you'd do if nothing changed after that. Interviewers want both halves of the answer, not just the opening move.

This question is really asking whether a candidate knows the difference between symptoms and root causes. Teams that repeat the same retro items sprint after sprint usually have a systemic problem the team can't fix on its own, an organizational impediment, a dependency on another team, a technical debt situation that needs management buy-in. A new retro format helps with engagement but rarely fixes a root cause sitting outside the team's control.

A good answer also admits some uncertainty here: you might try three different retro formats over six weeks and still not move the needle if the actual blocker is organizational. Saying that directly, instead of promising a clean fix, tends to land better than it sounds like it should.

This tests whether a candidate will actually protect the process or just describe protecting it. Calling the stakeholder out in front of the team creates a political problem without solving the structural one. The better move redirects in the moment, "let's capture that in the Product Backlog and the Product Owner can prioritize it for next sprint," then follows up with the stakeholder privately to explain why assigning tasks outside the backlog undermines the team's ability to commit to anything.

If the stakeholder outranks the Product Owner and the PO isn't backing you up, that's a genuinely harder problem, and naming it as harder rather than pretending it has a clean answer usually reads as more credible to an interviewer, not less.

Name the pattern to the two dominant voices directly, privately if possible, not as a public callout mid-meeting. Then change the facilitation format itself: round-robin input, written silent brainstorming before discussion, or explicitly asking the quieter engineers by name what they think before opening the floor. The goal isn't punishing the loud two. It's making sure the meeting actually surfaces the whole team's thinking, not just whoever's most comfortable speaking up first.

A candidate who says "I'd just let the conversation happen naturally" is describing an absence of facilitation, not facilitation. Interviewers notice the difference.

Start with the team's actual historical velocity, not their optimistic estimate of what they can do this time. Bring the last three or four sprints' completed points or throughput into the room and use it as the anchor for the conversation, rather than letting the team re-estimate capacity from scratch based on how motivated everyone feels that morning.

The harder part of the fix is cultural: some teams over-commit because saying "we can't fit that in" feels like admitting weakness to a Product Owner or manager in the room. Naming that dynamic explicitly, and making the historical data do the arguing instead of any one person, tends to work better than pure willpower.

Silence usually means either psychological safety is low or the question was too open-ended to answer cold. Switch to a more specific, lower-stakes prompt, "what's one thing that took longer than it should have this sprint," or use an anonymous written round before discussing anything out loud. Asking people to write first and talk second consistently surfaces more than asking them to speak up cold in front of the group.

If silence is a pattern across multiple retros, that's a signal worth naming to leadership rather than something a better icebreaker fixes on its own.

Distinguish between a Product Owner refining the backlog, fine, expected, and one actually disrupting the current sprint's committed work, a problem. For the second case, make the cost visible rather than just absorbing it: if we add this now, something specific gets pushed out, or the Sprint Goal itself is at risk. Most Product Owners aren't trying to sabotage the sprint. They often don't see the downstream cost until someone shows it to them plainly.

If the pattern continues after that conversation happens more than once, it's a coaching conversation about Product Owner practices, which is a legitimate part of the Scrum Master role even though it can feel uncomfortable to have with someone senior to you.

There's rarely a meeting time that's genuinely convenient for all three zones, and pretending otherwise doesn't help. Some teams rotate the inconvenient slot fairly across zones sprint by sprint. Others split into a synchronous core sync for overlapping hours plus an async written update, a shared doc or chat thread, for whoever's outside the window that day.

What matters more than the exact mechanism is that the team agreed on it together rather than the Scrum Master picking a time that happens to be convenient for whoever's loudest in planning.

Watch what happens in a retro or planning session you deliberately hang back from. A team that's ready keeps the conversation moving, holds itself to timeboxes, and produces real action items without a facilitator prompting every step. A team that isn't ready goes quiet or drifts the moment nobody's actively running the meeting.

This is one area where I think the standard Agile coaching advice, always be working yourself out of a job, undersells how much ongoing facilitation some teams genuinely need long-term, particularly teams with high turnover or a lot of junior engineers. Self-facilitation is a real goal. It's not always the right goal for every team at every point.

Velocity is a planning input, not a performance metric, and interviewers at companies with mature Agile practices tend to get visibly irritated by candidates who lead with it anyway. Stronger signals: Sprint Goal achievement rate, did the team hit the goal, not just close some tickets, impediment age, how long blockers sit before resolution, and qualitative signal pulled from retrospectives about morale or psychological safety. No single number here tells the whole story, which is exactly why it takes a combination.

Velocity measures story points completed per sprint, an estimate-based number. Throughput measures the raw count of items completed, regardless of size. Velocity misleads when point inflation creeps in, the same work "growing" from 3 points to 5 over time without getting any harder. Throughput misleads when item sizes vary wildly, ten small bug fixes looks identical to ten major features on a pure count basis.

Neither number means much without the context of what actually shipped and whether it mattered. Reporting either one in isolation to leadership without that context is how "productivity" conversations go sideways.

Explain, clearly and without being defensive about it, that velocity is a relative, team-specific number calibrated against that team's own estimation habits. Team A's "5" and Team B's "5" aren't the same amount of work, since each team calibrated its own point scale independently. Comparing them directly is comparing two different units that happen to share a label.

A useful reframe: if leadership genuinely wants to compare output, look at outcomes delivered against business goals, not story points, which were never designed to be a cross-team ranking tool in the first place.

A cumulative flow diagram stacks the count of items in each workflow state, to do, in progress, done, over time, and a widening band for any given state signals work piling up there faster than it's clearing. It's the diagram to pull up when someone asks why everything feels slower lately but nobody can point to a specific cause. A widening "in progress" band with a flat "done" line usually means too much work is started at once relative to what's actually finishing.

A Scrum of Scrums coordinates dependencies and cross-team impediments across multiple Scrum teams working on a shared product, usually a short, focused sync among representatives rather than a full team meeting. It solves the specific problem of one team's blocker being invisible to the team that could actually unblock it.

It doesn't solve a poorly defined product architecture that creates too many cross-team dependencies in the first place. Scrum of Scrums manages the symptom well. The underlying coupling problem usually needs an architectural conversation, not a better coordination meeting.

Here's an opinion that could be wrong: story points are oversold relative to how much teams argue about calibrating them precisely. The actual goal is a rough, relative sizing signal good enough to plan a sprint, not a scientifically rigorous unit, and teams that spend 40 minutes in every planning session litigating whether something's a 3 or a 5 have usually lost sight of that.

T-shirt sizing, or even a simple small, medium, large, needs breaking down, often gets a team most of the planning value with a fraction of the debate. Whether that tradeoff is right depends on how much precision the team's actual roadmap conversations genuinely need, and reasonable teams land differently on it.

Start with curiosity rather than persuasion. People resist processes for real reasons, a bad past experience with Scrum implemented poorly somewhere else, genuine skepticism about whether ceremonies add value for their specific kind of work, or a mismatch between their natural working style and the cadence Scrum imposes. Understanding the resistance is more useful than arguing against it from the first conversation.

There's a limit, though. If the resistance actively undermines the Sprint Goal or creates real dysfunction for the rest of the team, that's when the line manager gets involved. Scrum Masters don't have disciplinary authority, but naming when a situation has moved past facilitation into management territory is part of the job, not an admission of failure.

Show that you can hold a position with evidence and change your mind with evidence, not that you folded immediately or dug in regardless of new information. Name the specific disagreement, what evidence you brought to the conversation, what actually happened, and whether, in hindsight, the outcome was right.

Pure deference is as much a red flag here as stubbornness. Interviewers aren't looking for someone who agrees with authority by default. They're looking for someone who can disagree constructively and still land somewhere useful afterward.

Name the actual source of the conflict specifically, a technical disagreement, a personality clash, competing priorities, since "there was tension on the team" tells an interviewer nothing they can evaluate. Walk through what you did concretely: separate conversations first, usually, before bringing both people together, and what the actual resolution looked like, not just that things got better eventually.

The strongest version of this answer also covers what changed afterward, a team agreement, a different meeting structure, some concrete artifact of the conflict that prevents the same pattern from repeating.

Bring specifics rather than arguing about tone or perception. A recent example where estimated effort and actual effort diverged, with a concrete reason attached, hidden complexity, an undocumented dependency, tends to shift a stakeholder's view faster than a general conversation about respecting the team's expertise.

If the pattern continues despite that, it's worth a direct conversation about what evidence would actually change the stakeholder's mind, since some skepticism is fair and some simply isn't going to move regardless of what you show them.

The word "no" should actually appear somewhere in this story, said plainly, not softened into "I helped everyone understand it wasn't quite feasible right now." A Scrum Master who can't say no clearly to scope pressure is a real risk signal for a hiring manager who's watched a sprint blow up for exactly that reason before.

The stronger half of the answer covers what you offered instead of a flat rejection, a smaller version of the request, a later timeline, a visible tradeoff that gave the room a real choice rather than just a no.

Be honest about the reaction rather than reframing it as a success story after the fact. Name what you said, how it landed, and what you did next, did you follow up, adjust your approach, or let it sit and revisit it later. "It didn't land well and here's what I changed about how I gave feedback afterward" is a more credible answer than pretending every piece of feedback you've ever given was received gracefully.

Framework, by the Scrum Guide's own description: a minimal set of roles, events, and artifacts meant to be adapted to context rather than followed as a rigid procedure. Whether that distinction matters in an interview is genuinely debatable. Some interviewers consider it pedantic. Others use it as a quick filter for whether a candidate has actually read the source material or just absorbed Scrum secondhand through a certification course.

A safe answer names the distinction accurately and moves past it quickly: "framework, and what that means practically is our team adapted the standard events for a specific reason." Dwelling on the terminology without connecting it to a real decision reads as reciting a definition rather than understanding one.

A Scrum Master doesn't make this call alone. The right move is escalating to find the Product Owner, and if that genuinely fails, escalating to whoever holds Product Owner authority in their absence. Scope changes don't get accepted into the sprint without that decision-maker's involvement, since bypassing them undermines the sprint commitment and sets a precedent that emergencies can route around the backlog whenever someone senior enough asks.

The answer that ends candidacies here: "I'd probably accept the request and let the team know priorities changed." That tells an interviewer you'll sacrifice the sprint's integrity the first time real pressure shows up.

Ceremony compliance and team health aren't the same thing, and this question tests whether a candidate knows that. Possible causes: mounting technical debt slowing everything down regardless of process, team member burnout that ceremonies don't surface directly, an unclear or shifting Product Goal making every sprint feel disconnected from the last, or attrition and onboarding overhead nobody's tracking as a real cost.

The honest answer admits you'd need more information before diagnosing it confidently, and naming two or three specific things you'd check first, a look at the cumulative flow diagram, a direct conversation about workload, recent team composition changes, is a stronger answer than picking one cause and asserting it with false confidence.

Optional for team-level roles, close to standard for senior Scrum Master or Agile Coach positions. What matters is naming real tradeoffs rather than reciting marketing language from either framework's documentation. SAFe adds coordination structure at scale, PI Planning, Release Trains, but introduces meaningful ceremony overhead that smaller organizations often underestimate going in. LeSS is lighter but harder to adopt inside organizations with entrenched functional hierarchies that don't want to give up their existing reporting structure.

If you've only read about these frameworks, say so plainly. Interviewers can generally tell the difference between "I've read the SAFe documentation" and "I've actually run a PI Planning event," and claiming the second when you've only done the first tends to unravel under two or three follow-up questions.

This is the single most important behavioral question in most Scrum Master loops. Have one strong story ready, ideally an impediment that required cross-team coordination or organizational escalation, something harder than unblocking a broken CI pipeline on your own. The story needs a clear blocker, a specific action taken, not "I raised it," but who you escalated to, when, and what you asked for, and a resolution with a concrete outcome attached.

If you've never removed an impediment requiring escalation above your own team, that's worth reflecting on honestly before the interview. It suggests either your team hasn't faced real organizational friction yet, which is possible but somewhat unusual over a full year of delivery, or impediments simply weren't getting escalated when they should have been.

Interviewers expect a real answer, not a humble-brag disguised as a failure story. A credible answer names a specific decision or gap that contributed, what you didn't catch and why, and what changed afterward. Claiming every sprint has gone smoothly invites a skeptical follow-up, and rightly so.

"We committed to a Sprint Goal that depended on an external API team's timeline we never actually confirmed, and I should have flagged that dependency risk during planning" is a more useful answer than a story with no real cost attached to it anywhere.

Name the gap honestly rather than pretending a Scrum Master has performance-management authority they don't actually have. The real lever is a direct, specific conversation about the impact on the team and the Sprint Goal, followed by involving the line manager if the conversation alone doesn't change anything within a reasonable window, two or three sprints, not indefinitely.

What interviewers are checking here is whether a candidate understands the actual limits of the role. Overclaiming authority you don't have reads as either inexperience or wishful thinking, and either one is a worse answer than accurately describing the influence you do have.

This pattern almost always means the Definition of Done isn't rigorous enough, or it's not being enforced consistently even though everyone signs off on it. Sprint review demos tend to happen against a happy path in a dev or staging environment with clean test data, which tells you nothing about how the feature behaves against real production data, real load, or the edge cases users actually hit.

I'd start by pulling defect tickets from the last three or four releases and grouping them by root cause: missed edge case, environment mismatch, or a regression in an area nobody thought to retest. That usually points to one of two things. Either QA capacity got quietly cut under deadline pressure and nobody flagged it, or "done" in this team's DoD really means "code reviewed and merged" with no independent verification step at all, so developers are effectively grading their own homework.

The fix isn't a lecture about quality, it's tightening the DoD to explicitly require testing against production-like data and holding the line that a clean demo is not the same thing as done. Then track defect escape rate as an actual metric for a few sprints, not just velocity, to confirm the change is working rather than just feeling better.

This isn't something either team's own ceremonies can solve, because neither Scrum Master has authority over the other team's backlog. It needs a mechanism that sits above both teams. The first practical step is making both backlogs visible to each other before sprint planning happens, not during it, so dependencies get flagged and tagged explicitly instead of surfacing for the first time in a stand-up three days into the sprint. A lightweight Scrum of Scrums or a shared dependency board works fine for this, it doesn't need to be elaborate.

If it's the same two teams colliding sprint after sprint on the same files, that's a signal the code ownership boundary is wrong, not that the teams need better communication. The real fix is usually splitting out a small platform or API team that owns the shared surface with a stable contract, so the two feature teams stop touching each other's territory directly.

The part that actually stalls this is political: one Product Owner often won't yield priority because their roadmap looks more urgent to them. That's not something two Scrum Masters should be negotiating between themselves, since neither has the standing to overrule the other's PO. Escalate it to whoever owns cross-team prioritization, a program lead, a head of product, and get an explicit decision rather than letting it fester as an unresolved argument every sprint.