A stakeholder is anyone whose input the product depends on or whose interests it serves, which is a wider group than the people who pay for the work. Users, the people who support the product, the ones whose job changes when it ships and the parts of the organisation carrying its risk are all stakeholders, and several of them will never ask for a meeting.
The Guide does not define the word, which leaves the Product Owner to work out who matters and to keep revisiting the answer. The loudest stakeholder and the most affected stakeholder are often different people.
Where input enters
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 rather than a weaker substitute for authority.
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. Seniority changes how carefully the conversation is handled and 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. It is not a demonstration and not a sign off gate, and the Increment may well have been released already.
What the event produces is a revised Product Backlog and a shared sense of the next most valuable thing to do. A review where stakeholders watch a screen for an hour and say nothing 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.
Understanding, not 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. What the Product Owner needs from the conversation is 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
The Product Owner represents the needs of many stakeholders in a single Product Backlog, and that is why the accountability sits with one person rather than a committee. Every position in the order is a decision that somebody else's request came second, and only one ordered list makes those decisions visible enough to argue with.
Representation is not transcription. A Product Owner who forwards each request into the backlog unchanged has assembled a queue rather than a product, and the strategy has quietly been handed to whoever writes the most emails.
When the stakeholder you need stops coming
Absence is the failure this concept is really about, because nothing in the process raises a flag when it happens. 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 and neither is fixed by insisting on attendance.
Where 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. What must not happen is the product proceeding on assumptions about a group nobody has spoken to.