Key stakeholders

This is somewhat context sensitive.

The Scrum Guide does say this:

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.

To me, this means that stakeholder identification falls to everyone on the Scrum Team - the Product Owner, the Scrum Master, and the Developers. Anyone can point out someone (a person or group) that they believe is a stakeholder and decide, as a team, how to appropriately engage with that stakeholder.

However, in the specific context of the Sprint Review, I would suggest that the Product Owner is responsible for inviting the right key stakeholders, perhaps based on the work done in the Sprint and likely upcoming work. I believe that the Sprint Review is the responsibility of the Product Owner, so making sure the right people are there and engaged is their responsibility, with some support (as requested from the Scrum Master).

@Micheal D: The question is a bit ambiguous . For example, by stakeholders, is the question directed from the business  standpoint or customer standpoint? In addition to @Thomas Owen's feedback, I believe senior leadership should be apart of stakeholder identification from the strategic planning angle.

According to you who should identify the key stakeholders : the PO or the whole scrum team ?

Try thinking of it the other way round. How would stakeholders in a given Product identify the Product Owner they would best trust to represent their interests on a team so value is maximized?

Hi,

My question was at the beginning of any scrum team.

I am not sure senior management (CEO, CFO, CTO, CMO) should be always key stakeholders in the sense of Scrum. Even if they are key, generally speaking. It should depend of the size, organisation of the company and of the Scrum team purpose.

Scrum  glossary (stakeholder) : a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery.

I understand a key stakeholder has to be somehow close to the product

@Ian : what do you mean ?

I'd suggest that a product might reasonably be identified first, for which there will be stakeholders; the best Product Owner may then be identified to represent their interests.

There are established mapping techniques which qualify stakeholders in terms of impact and influence, and which are often used to navigate certain stage gates in traditional projects. Scrum on the other hand is based on emergence and bottom-up intelligence. Where there is doubt about who key stakeholders are, the matter would be resolved by experiment.

For example there may be a customer pivot in which an hypothesis about stakeholders is tested via a new MVP. A more appropriate Product Owner may then be identified who can better represent these newly validated interests and command stakeholder trust.

Yes, there may be also some situations with less significant changes than a customer pivot.

Maybe any member of the current team (regardless of the way it was top-down or bottom-up created), can suggest new potential stakeholder (eg legal department, international sales,...). The PO should decide whether such a stakeholder is really key or not at this given time and should identify the right person in the given department.

Which would make the PO in charge "of identifying key stakeholder" and not the whole team (it is not my preliminary thought on this matter).

What if that "key stakeholder" is another application that is getting information from your product via a published API?  Would the Product Owner be "in charge" of identifying those key stakeholders? Would the Product Owner be the right person to "identify the right person from the given department" in this case or might the Developers be better suited to do so? 

My opinion has always been that the Product Owner is responsible for the business facing aspects of the Product.  The Developers are responsible for the technical aspects.  If a stakeholder is business facing, the Product Owner is their point of contact.  But if the stakeholder is of a technical nature, the Developers are the point of contact. 

Hi Daniel,

Please note a stakeholder is a person not an application.

Connection to another application may not be only a technical question.

.

Yes, stakeholders are human beings (at least until we discover intelligent life on some other planets)  There are developers that maintain the other application.  So wouldn't they be a stakeholder in my case? What if that application is external to your organization?  Again, there would be some human interested in what your application delivers.  

What I was trying to convey is that not all stakeholders have a vested interest from a business or user perspective.  Sometimes a stakeholder is a consumer of the output from your product for the purpose of using it in their product.  In those cases, there could be a Product Owner at the other company that could be the stakeholder.  But there would also be developers at that company and they may also be stakeholders.  

As I said, my opinion is that there are two sides to a product and the stakeholders could be identified from either part.  What I didn't say, but tried to imply, is that having people that speak the same "language" is usually most effective.  Technical minded stakeholders should be identified by and interface with other technical minded people (i.e. Developer to Developer).  While business minded people would be most effective paired and identified by the Product Owner.