Barely anyone from the business comes to your Sprint Review, and when they do it is a demo with no feedback. How do you fix it?

A review is a working session, and a demo is not one

The Sprint Review exists so the Scrum Team and the stakeholders inspect what was produced, discuss progress towards the Product Goal, and decide together what to do next — and the output that proves it happened is a changed Product Backlog. The 2020 Scrum Guide is explicit that it should not be limited to a presentation, and that single line is the diagnosis for most of these situations.

Once you see the event that way, empty chairs stop being a discipline problem. A stakeholder who attends a presentation gets information they could have had from a written update, delivered more slowly and at a fixed time. Nothing is being asked of them and nothing they say changes anything, so declining is a rational use of their afternoon. Non-attendance is feedback about the meeting, not disrespect for the team, and treating it as the latter is how a Scrum Master ends up sending increasingly firm calendar invitations for a year.

Check the increment before you blame the diary

The first question is not about attendance. It is whether there is anything to react to. Three failures of the increment make a genuine review impossible, and any of them means the format is not your problem.

If the increment is not actually usable — a service with no interface, a change behind a flag nobody can turn on, work that is complete except for the part that makes it visible — then there is nothing for a stakeholder to have an opinion about, and the team is reduced to describing what they did. If the increment cannot be touched, because the demonstration happens in a shared environment with fake data and a rehearsed path, stakeholders see a performance and correctly discount it. And if the increment is a set of unrelated fragments from three different initiatives, there is no coherent thing to discuss and no stakeholder for whom the whole meeting is relevant.

The test worth applying is whether a stakeholder could drive it themselves for two minutes. If they could, they will have opinions whether you ask for them or not. If they could not, fix that before fixing the meeting, and be prepared to say so in an interview, because it is the answer that shows you understand the event depends on the artefact rather than the other way round.

Invite fewer people, better chosen

The instinct when nobody comes is to widen the invitation, which makes it worse. Twenty people in a room, most of whom have no stake in this Sprint's work, guarantees that nobody speaks and that the two who matter cannot get a word in. Cut the list to the people who can act on what they see, and be specific about who those are for this particular Sprint's work rather than maintaining a standing list.

Who is in the room	What you get
A broadcast invite to the department	Silence, and attendance that decays over a quarter
The people who can change the Backlog's order	Argument about what to do next, which is the point
Somebody who represents the actual users	Objections nobody inside the team would have raised
Managers attending to check up on the team	Careful presentation and no honest discussion of what did not work
Nobody outside the team at all	A status meeting held for its own sake

Then ask individually rather than by invitation. Going to the two people whose decisions depend on this work and telling them what you need from them, with a specific question you want their answer to, produces attendance that a calendar entry never will. It also tells you quickly whether they think the work matters, which is information you want even when it is unwelcome.

Make silence unavailable

"Any feedback?" at the end of a demonstration produces polite noises, because it is an open question at the point of lowest energy in the meeting. Replace it with questions that require a decision or a comparison, and ask them at the moment the thing is on screen rather than at the end.

Phrasing that gets nothing	Phrasing that gets something
"So that is the new search. Any thoughts?"	"Would your team use this instead of the spreadsheet tomorrow? If not, what stops you?"
"Any questions before we move on?"	"We guessed at the default here. Show me what you would have picked."
"Does that all look good?"	"Given what you have just seen, is the reporting work still next, or does something else jump ahead?"
"We finished eight items this Sprint."	"Two of the eight did not land. Here is what that means for the date."

The other half is letting stakeholders use the software rather than watching somebody else use it. Hands on keyboard for five minutes generates more feedback than half an hour of narration, and it also surfaces the assumptions the team did not know it had made.

One caution: honest inspection includes what did not get finished and what did not work. A review that only ever shows successes trains stakeholders to treat it as marketing, and once they have made that classification they stop coming even when the content improves.

When the review is the wrong forum

The strongest version of this answer includes a case for not fixing it. There are products where the Sprint Review as commonly practised is a poor mechanism, and pretending otherwise wastes everybody's fortnight.

If your users are ten thousand strangers, the feedback that matters is behavioural — what they do with the release — and the useful adaptation is to instrument the increment and bring the data to the review rather than to find a proxy stakeholder to nod at a demonstration. If the work is a platform consumed by other engineering teams, the meaningful review is those teams integrating against it, and a scheduled meeting is a weak substitute for a consumer who has upgraded. And if you release continuously and stakeholders see changes as they land, a fortnightly gathering to show them things they saw a week ago is genuinely redundant; what is not redundant is the conversation about what to do next, which is the part worth keeping.

In each of those cases the honest recommendation is to keep the inspect-and-adapt conversation and change its form, and to say plainly which part of the event you are dropping and why. That is a different answer from letting the review quietly become a fifteen-minute formality, which is what happens when nobody makes the decision.

Whose problem this is

Finally, be careful about ownership. Connecting the team to the people who care about the product is the Product Owner's accountability, and a Scrum Master who takes over stakeholder engagement has solved this quarter and created a dependency. The useful position is to make the failure visible — how many stakeholders attended over the last six Sprints, how many Backlog items changed as a result, how long since anybody outside the team asked for something different — and to hand the Product Owner a problem they can see rather than an opinion they can decline.