Are members of the scrum team also stakeholders?

I might have said the same thing in the past. There is some ambiguity in how the term stakeholder is used. The loose definition of a stakeholder is “anyone who can influence the outcome of the project.” In that sense, team members could be seen as stakeholders, and there may be some benefit in treating them as such, which might be what the Agile Coach was alluding to. You sometimes hear this broader interpretation in informal conversations.

However, in formal frameworks — whether adaptive (Scrum) or predictive (PMBOK/PMP) — team members are not considered stakeholders in the formal sense. In predictive projects, team members typically do not go on the Stakeholder Register, as advised in the PMBOK. The Scrum Guide specifically refers to stakeholders as being external to the Scrum Team and represented by the Product Owner.

That said, in a broader context — such as internal projects where the team are also users — they might reasonably be considered stakeholders in a looser sense, due to their investment in the outcome. But within Scrum and most formal frameworks I know, team members are not regarded as stakeholders. Still, it’s important to value input from the team just as we value stakeholder input.

It depends on the context.

The term "stakeholder" has definitions such as "individual or organization having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations" (ISO/IEC/IEEE 15288 and ISO/IEC/IEEE 12207) or "individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio" (PMBOK Guide - 7th Edition). Using these definitions, the members of the Scrum Team are stakeholders in the work.

However, in the Scrum Guide, the word "stakeholder" is used in various contexts, such as "Scrum Team and its stakeholders" or "between stakeholders and Scrum Teams". These uses imply stakeholders other than the Scrum Team, whether they are internal or external to the developing organization.

However, there are two uses of "stakeholder" that are interesting:

The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.

and

The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.

In these contexts, I can see the Scrum Team (including the developers of the Scrum Team) being included as a stakeholder. The Scrum Team may have work in the Product Backlog that can help make their lives easier, such as Product Backlog Items that focus on paying down technical debt. Adding these to the backlog and ordering them would require convincing the Product Owner. Suppose you consider these two sentences to include the Scrum Team. In that case, you open the door to negotiation and collaboration between the Product Owner and the Developers in how to best order technical work among work valuable for other stakeholders, perhaps even entire Sprints dedicated to improving the ability of the Scrum Team to deliver future Sprint Goals better, while still expressing the work and the goals in a way that is accessible to all stakeholders.

Personally, I would think of a "stakeholder" as being anyone who is impacted by the Product. That would include members of the Scrum Team, whose livelihoods may depend upon it, and by extension even their families. It might be important to take all of these people's interests into account when making product decisions. I could see myself advocating that position as an agile coach.

The definition of a stakeholder in the Scrum Glossary is however more specific:

Stakeholder: a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review.

Hence maybe a different word is needed to describe others who are impacted.

As everyone above explained it is not exactly clear and open to interpretation.  I have used the term "stakeholder" in many ways.  For example, using @Thomas' example of technical debt, the developers are the ones that know best why it is valuable to the product.  Based upon your past posts, it could be said that your architects could satisfy that need but then they seem to be part of the developers so it is kind of a wash. 

@Ian's suggestion is something that I hadn't considered but the developers do have a vested interest in the product.  In that same vein, so would the Scrum Master and yourself, the Product Owner.  If you think about it per @Ian's suggestion, even your competitors would be stakeholders because they are also impacted by your product. How many times have you looked at a competitors product to see what is missing from yours?  If that isn't valuable feedback I don't know what is. 

@Pierre's suggestion is something I've dealt with in a way.  I once had a team of developers that were responsible for the maintenance of a product that was used internally as well as sold externally.  In that case they were users of the product and what I considered a stakeholder.  

I tend to think of stakeholders as anyone with a vested interest in the product and it's success.  Any input that I can get from anyone which is applicable and valuable to the product is something I need. 

The correct answer is:In formal Scrum practice, members of the Scrum Team (Product Owner, Scrum Master, and Developers) are not considered stakeholders. Stakeholders are typically external to the Scrum Team and include users, customers, and business sponsors. However, in broader project management or informal contexts, the term “stakeholder” can include anyone affected by or interested in the project’s outcome — including team members. While Scrum Team members influence outcomes and may advocate for certain work (like reducing technical debt), they are contributors, not stakeholders, according to the Scrum Guide. Clear role distinction ensures proper accountability and focus within the framework.