When is Scrum the wrong choice for a team, and what would you use instead?

What a Sprint actually assumes

Answering this by listing contexts is a weak answer, because the list is memorised and the interviewer cannot tell whether you understand it. Start from the mechanism instead. The Sprint is a fixed-length container, one month or less, and everything Scrum does depends on three assumptions holding inside it.

The first is that a useful amount of the next fortnight's work can be foreseen at the start of it. The second is that the plan can be held stable for that fortnight, because the Sprint Goal is a commitment and mid-Sprint churn dissolves it. The third is that the work can be shaped into a single coherent objective worth committing to, since a Sprint whose goal is "finish these nine unrelated items" has a container with nothing in it to inspect progress against.

Where all three hold, Scrum's cost buys you something specific: a rhythm that forces a decision about what matters, a stable window in which a team can concentrate, and a regular point at which stakeholders see working software and change their minds cheaply. Where one of them fails, you are paying that cost and getting the ceremonies without the benefit, which is what most complaints about Scrum are actually describing.

The contexts where the assumptions fail

Four cases are worth being able to name, each traced back to which assumption breaks.

Interrupt-driven work breaks stability. A team whose job is production support, incident response or a shared service queue cannot hold a plan for two weeks, because the work arrives unpredictably and correctly takes priority. Such a team spends every Sprint Planning forecasting work it will not do and every Sprint Review explaining why, and the Sprint becomes a fortnightly apology.

Single-large-item work breaks foreseeability. A team spending three months on one research problem, one migration or one algorithm has nothing to plan into two-week increments except progress updates, and no releasable increment at the end of each. You can force a Sprint shape onto it, and what you get is invented interim milestones that measure nothing.

Externally gated work breaks the value of the cadence. Where delivery depends on a regulator's submission window, a hardware manufacturing date or a partner's quarterly release, the fortnightly rhythm no longer connects to feedback, because nothing is learned from a Sprint whose output cannot reach anyone for four months. Scrum's inspection loop still has value internally, but the Sprint Review has lost its counterpart.

Highly heterogeneous flow breaks the goal. A team taking on items whose sizes differ by an order of magnitude will always have Sprints where one item consumes everything and Sprints where twelve items land, and no coherent Sprint Goal fits both. Sometimes the honest fix is splitting the work better rather than changing the framework, and you should say so — but where the variety is inherent, such as a platform team serving twenty consumers, it is a real mismatch.

Kanban is a different discipline, not a relaxation

The failure mode in this answer is proposing Kanban as Scrum with the meetings deleted. That is how teams end up with no cadence, no limits and no improvement mechanism, and it is worse than the Scrum they left.

A flow-based approach substitutes its own disciplines, and they are harder to hold rather than easier. You make the workflow visible including the waiting states, you limit work in progress explicitly and honour the limit, you manage flow by attending to where items queue, you make the policies for moving between states explicit, and you keep deliberate feedback loops even though there is no Sprint boundary to hang them on. Limiting work in progress is the load-bearing one, and it is the discipline most teams abandon first, which is why so many boards labelled Kanban are simply a list of everything everyone is doing.

What Scrum gives you	What you must replace it with
A Sprint boundary that forces prioritisation	Explicit work-in-progress limits and a pull policy
A Sprint Goal to focus on	A class-of-service or a stated policy for what jumps the queue
A forecast from the Sprint Backlog	Cycle-time percentiles and throughput-based forecasting
A Review that produces stakeholder feedback	A scheduled review or a data-driven equivalent, chosen deliberately
A Retrospective at a fixed point	A cadence for improvement that survives having no natural boundary

Read that table in both directions. Every row is a thing the Sprint was doing for you, and dropping the Sprint without installing the right-hand column is where teams lose two quarters.

What you keep either way

Almost everything valuable in Scrum other than the Sprint container transfers. You keep a single person accountable for the order of the work, because two prioritisers is a dysfunction under any process. You keep one Definition of Done, because releasability is not a function of cadence. You keep a regular retrospective, deliberately scheduled since nothing else will trigger it. You keep the working agreements and the daily coordination, though a flow-based team is better served by walking the board than by taking turns.

For the interrupt-driven case specifically, a common and honest answer is a hybrid: run flow for the reactive stream with a work-in-progress limit and a service-level expectation, protect a share of capacity for planned work, and keep a fortnightly review and retrospective as fixed points. That is a defensible design rather than a compromise, provided you can say which discipline is doing which job.

Distinguishing a bad fit from an escape

Teams also ask to leave Scrum because the discipline is uncomfortable, and the two situations look identical from the outside. The tells are usually in what they complain about. A team with a genuine mismatch complains that the plan is invalidated by events outside its control and can show you the interruptions. A team avoiding the discipline complains about the meetings, about being asked for estimates, or about being held to a commitment, and cannot produce evidence that the plan was disrupted rather than simply not followed.

The diagnostic question is whether they will accept the alternative's obligations. Offer flow with a hard work-in-progress limit, published cycle-time percentiles and a fortnightly retrospective. A team with a real mismatch takes that gladly, because it removes a ritual that was not helping while keeping the accountability. A team looking for an exit objects to the limit, and the objection tells you the problem was never the framework.

Then judge the change on outcomes rather than on adoption. After eight weeks, look at whether the cycle-time distribution has tightened, whether the proportion of items finished versus started has improved, whether stakeholders are getting feedback at least as often as before, and whether the team has completed any improvement it identified. If those are flat and only the meeting invitations have changed, the switch has cost you the framework and bought nothing.