The team has missed its Sprint Goal four sprints in a row. What do you do as Scrum Master?

Four misses is a signal, and it is not yet a diagnosis

The first thing to say out loud is that you do not know what is wrong yet, and that a run of four is far more useful than a single miss because it rules out bad luck. One missed goal is noise. Four consecutive misses means something in the way this team plans, is interrupted, or defines completion is stable and repeatable, which is good news: stable causes can be found.

The second thing to say is that a missed Sprint Goal is data, not failure. In Scrum the Sprint Goal is a commitment to an outcome, and the team is expected to adjust the Sprint Backlog as it learns, negotiating scope with the Product Owner while holding the goal. A team that hits its goal every single sprint is usually not a high performer; it is a team that has learned to set goals it has already achieved. Interviewers are watching for whether you reach for a fix or reach for the cause first, and the candidate who opens with "I would reduce what they commit to" has failed the question in the first sentence.

The questions to answer before changing anything

There are five plausible causes, and they call for entirely different responses. Work through them with the data you already have — the sprint backlogs, the boards, the carry-over, the Sprint Review outcomes — before you put anything to the team.

What you check	If it is true	What it implies
Who wrote the goal	The goal arrives in Sprint Planning already written, by the PO or a manager	It is a target, not a commitment; the team never owned it
Work entering mid-sprint	Items appear on the board after day one, or people are pulled to support	The plan was sound and then was overwritten
Definition of Done	Items are called done with testing, review, or deployment outstanding	The team is not missing the goal, it is discovering the miss late
Cross-team dependencies	Completion waits on another team, a vendor, or an approval	The constraint is outside the team's control entirely
Velocity as a target	Someone reports velocity upward, or it appears in objectives	The team is inflating commitment to protect a number

The fifth is the one candidates miss, and it is worth naming explicitly. The moment velocity is reported as a performance measure rather than used as a forecasting input, the team's rational response is to commit to more and to inflate estimates, which produces exactly the pattern in front of you. Goodhart's law arrives quietly, and by the time it shows up as missed goals nobody remembers that a metric became a target.

Note also what a fourth possibility does to the framing: if completion genuinely waits on an external approval, no amount of better planning inside the team will move the outcome, and continuing to coach the team about estimation would be both useless and insulting.

Using the retrospective without turning it into an inquest

The retrospective is the right forum, but a retrospective that opens with "why did we miss again" produces defensiveness and self-justification, and you will learn nothing. Change the unit of analysis from the team to the sprint. Put the four sprints side by side as a timeline, and ask the team to mark on it every point where the plan changed: work added, people borrowed, an item that sat waiting, a dependency that arrived late.

The question that works is about the work, not the people: "at what moment in each of these sprints did we know the goal was in trouble?" If the answer is day nine of a ten-day sprint, the problem is late integration or deferred done rather than over-commitment, and the team will see that themselves once the timeline is on the wall. If the answer is day two of every sprint, the plan was never viable.

A worked phrasing for opening it: "We have four sprints of the same outcome, so I am fairly confident this is something about how we work rather than how hard anyone tried. I would like to map what happened rather than explain it." That sentence does a specific job — it pre-empts the blame reading before anyone has to defend themselves.

When the impediment is not yours to remove

Some of the causes above resolve inside the team. Deferred done, weak refinement, and a vague goal are all things the team can change next sprint. Two of them are not. A goal that is handed down by someone outside the team, and a dependency on a team or approval you have no authority over, are systemic impediments, and your job stops being facilitation and starts being escalation.

Escalate with the evidence assembled, to the person who can actually change the constraint, and frame it as a delivery consequence rather than a complaint: four sprints, this many items blocked waiting on that team, this much work carried, and here is what it costs. Tell the team you are raising it, and tell them what happened afterwards, because an impediment that disappears into management without a reply teaches the team that raising things is pointless.

Be honest about the limit of your authority too. If the goal keeps being set for the team by a stakeholder, you can coach, you can make the cost visible, and you can escalate, but you cannot make the organisation hand the decision back. Saying that plainly in an interview reads as maturity rather than weakness.

What you change, and in what order

Change one thing, and choose the one your investigation pointed at. If the goal was imposed, the change is that Sprint Planning does not end until the team has written the goal in its own words. If work is arriving mid-sprint, the change is that it goes through the Product Owner as an explicit trade against something already in the sprint, so the cost is visible rather than absorbed. If done is being deferred, tighten the Definition of Done and pull integration earlier. If velocity became a target, the conversation is with the manager reading the number, not with the team.

Then let one sprint run and see whether the outcome moves. Changing five things at once means the next result tells you nothing, which is how teams end up with elaborate process and no idea which part of it helps.

A team missing its Sprint Goal repeatedly is telling you something reliable about the system it works in, and the Scrum Master's value is in finding out what before prescribing anything. Reducing the commitment is the one response that reliably hides the cause while appearing to fix the symptom.