A stakeholder is anybody the product needs input from, or anybody whose interests it serves. That is a wider group than the people who pay for the work. Users count, so do the people who support the product, the ones whose job changes when it ships and the parts of the organisation carrying its risk. Several of them will never ask for a meeting, so nobody will hand the Product Owner the list.
The Guide does not define the word either, so the Product Owner has to work out who matters and keep revisiting the answer, because the loudest stakeholder and the most affected stakeholder are often different people.
How stakeholder input reaches the Product Backlog
Anyone may propose a Product Backlog item, and those wanting to change the Product Backlog do so by trying to convince the Product Owner. Persuasion is the mechanism the framework provides. A stakeholder with a good argument moves the order. A stakeholder without one leaves it where it was, whatever their job title.
The Product Owner decides what enters the backlog and in what order, and for that to work the organisation must respect the decision. This is the boundary that scenario questions probe most often, usually by giving the stakeholder seniority, a revenue argument or a deadline. When a director wants single sign on before the quarter ends, the Sprint Review is where they make that case. The Product Owner may still order a payments outage above it. Seniority changes how carefully the Product Owner handles the conversation, but it does not change who decides.
The Sprint Review is a working session
The Sprint Review is the scheduled point at which the Scrum Team and stakeholders inspect the Increment together, review what was accomplished, discuss what has changed in their environment and collaborate on what to do next. Nothing in that list is a demonstration or a sign off, and the Increment may well have been released already.
The event produces a revised Product Backlog and a shared sense of the next most valuable thing to do. If stakeholders watch a screen for an hour and say nothing, the review has produced no evidence, however good the Increment looked. The honest test of the event is whether the backlog changed as a result of it.
What a Scrum Master does with stakeholders
Keeping the event honest in that sense is the Scrum Master's work, and the Guide states the duty narrowly. All Scrum events have to take place, be positive and productive, and stay inside the timebox. If a Sprint Review slides into a sign off meeting or runs two hours past its limit, addressing that is the Scrum Master's job, while what is discussed inside the event stays with the Scrum Team and its stakeholders.
The duty of helping with stakeholder collaboration carries a qualifier that scenario questions press on. Help of that kind is owed as requested or needed, so a Scrum Master who convenes a stakeholder group without the Product Owner asking for it has stepped outside the service, even when the meeting goes well.
Removing barriers between stakeholders and Scrum Teams reaches further than that. A security review nobody can book is a barrier of exactly that kind, and so is an account manager forbidden to speak to Developers. Clearing either one means changing an arrangement nobody inside the team controls.
Collaboration aims at understanding and never at consensus
Collaboration here does not mean everybody agrees. Stakeholders want incompatible things, and a backlog that satisfies all of them is a backlog with no order in it. The Product Owner needs an understanding of what each person actually needs and why, which is frequently different from the solution they arrived asking for.
Chasing agreement produces two familiar failures. Either the order becomes a rotation in which every group gets its turn regardless of value, or decisions stall while people are talked round. Saying no with a reason attached protects the relationship better than saying yes and delivering late.
One backlog holds many people's needs
Somebody has to be in a position to say no. The Product Owner represents the needs of many stakeholders in a single Product Backlog, and that is why the accountability sits with one person. A committee can agree on a set of items, but it cannot produce a single order, because an order needs somebody to decide whose request comes second. Every position in the list is one of those decisions, and only one ordered list makes them visible enough to argue with.
Representing those needs is different from transcribing them. When a Product Owner forwards each request into the backlog unchanged, the backlog becomes a queue, and the strategy has quietly been handed to whoever writes the most emails.
When a stakeholder the team needs stops coming
The loudest stakeholder is the easier problem. The harder one is the stakeholder who stops coming, because nothing in Scrum reports an absence. A quiet Sprint Review looks like a smooth one.
The first move is to find out why. Attendance usually stops when the event costs a stakeholder more than it returns, either because nothing they care about has been shown for several Sprints or because their input has never visibly changed anything. Both causes are fixable, but neither is fixed by insisting on attendance.
If somebody genuinely cannot attend, their input still has to reach the Product Owner by some other route, and the Scrum Master serves the organisation by removing the barriers that make that hard. The product must not proceed on assumptions about a group nobody has spoken to.