When organizing the sprint review we must know who should be there in order for our scrum to work. The team of course should present the product increment so without them there will be no review. Also, we must know who will listen, observe the presentation and give relevant feedback – the stakeholders. Who is this really?

The key stakeholders in agile are those who have a business interest in the product and knowledge about the domain. The key stakeholders either fund the whole venture and are empowered to decide about the product or to delegate this responsibility to another person. A stakeholder knows the needs of the users and the priorities in delivering features. Stakeholders along with the scrum team are the most important people on sprint review because they can provide necessary feedback about the product increment. 

So stakeholders are decision-makers because of their knowledge about the user needs and because they invested in the solution.

Most often it won’t be all in one person.

Who are they exactly?

It depends on the business model in terms of client and user relations. You can have a client who is also a user – gives feedback and takes responsibility for decisions. You can have a client who doesn’t know a thing about what the user wants but is still funding the project and have the responsibility for the product’s shape.

Key stakeholders should provide feedback that leads to delivering the most valuable product. Therefore they are either users themselves or they are so close to users that they understand exactly what are their needs.

Key stakeholders should take responsibility for their decisions or delegate this responsibility to people who also have domain knowledge.

If data obtained from the users do not point directly to the solution to a given problem someone still has to make the decision. Usually, this kind of decision is escalated to someone who holds the cash.

Regardless of the business model, there will most often be an internal stakeholder like a product manager. If the PM doesn’t have the domain expertise, even obtained from external stakeholders – he or she is still funding the work of the scrum team.

Let’s explore different business models to see who could be the key stakeholders.

Own solution – internal users

When our firm has its own product and the users are within the organization the key stakeholder is a representative of those users (User SH), and a person who pays for the work (SH).

For example, the sales manager needs to have new features in their CRM.  Acquiring the requirements takes place directly from the users and/or the sales manager himself. In addition, the manager responsible for the product development is a stakeholder for the scrum team.

Key stakeholders in this example are:
Internal:
– Chosen user’s representative 
– Manager of  the users interested in the solution
– Manager of the product development

Own solution – external users

Our firm develops its own solution but it is delivered to external users.

In this case, we have options:

• The external user representative (User SH) should attend the sprint review as a stakeholder,
• An internal person (SH) should be the voice of the users
• An internal manager funding the product

In the second case, the internal person should be focused on knowing the users and their needs.

That knowledge is acquired by collaborating with users directly and indirectly through surveys, and analytics.

Key stakeholders in this example are:
External:
– User’s representative

Internal:
– Manager of  the team or product (in SAFE Product Manager)
– Business owner (in SAFE)

Client’s solution for its own internal users

In this model, our client is a corporation that wants a solution for its internal needs.

Users are within the corporation which is the source of all requirements and our software firm is the outsourced executive.

Options for external stakeholders:

• Users representative (User SH)
• Business delegate in charge of and funding the project (CSH)
• Users representative and a business delegate form a team of key stakeholders (User SH + CSH)

In the third case, it is crucial to establish who is empowered to make decisions. We have to know it from day one because the most important decisions about the product will be based on what the stakeholders say.

If there is a disagreement between the stakeholders and the scrum team doesn’t know who to listen to then it is a huge impediment that should be dealt with immediately on the business level.

It is a situation a change agent like scrum master should focus on to ensure healthy, undisturbed development.

In this model, there is also an internal stakeholder – the product manager. PM is funding the work of the scrum team and can also be the source of the domain knowledge.

The Product Owner and other scrum team members can obtain requirements and feedback:

• Directly from external stakeholders
• Indirectly through the product manager

Preferably direct communication should take place, but even if it does the product manager plays a crucial role in contract negotiation, scope definition, budget, and more.
The product manager is by definition a key internal stakeholder – even if the product owner does all the work and is still able to keep up with the product backlog – the PM is still funding the scrum team.

The form of collaboration depends on how often do external stakeholders want to be involved in sprint reviews?
Do they want it every sprint?
Will they attend the system demo?

The software firm must conclude with the corporate client their involvement in the development process. The closer they are – the more valuable product they will get.

Key stakeholders in this example are:
External:
– User’s representative
– Clients’ business delegate
– A team of users and business delegates 

Internal:
– Manager of the team or the product (in SAFE Product Manager)
– Business owner (in SAFE)

Client’s solution for external users

The fourth model is an external corporate client who has (or wants to have) a solution for external clients.

Two options:

• The corporate client is part of the users’ industry
• The corporate client is an investor and doesn’t know much about the users’ domain

In case 1 the client is part of the industry so there is a big probability that the corporation has someone with competencies to be in charge of the project (CSH). That would be someone who knows the domain well, is in touch with the users, and can communicate their needs to the software firm. Corporate stakeholder has the ability to give requirements and give feedback and is funding the venture.
Still, collaboration with end-users is advised to have direct feedback during product development.

In case 2 the client is an investor with a budget and a business goal to achieve. CSH is the key stakeholder only because of the funding.
If there is no expertise in the users’ domain in the corporation then the key stakeholders should also be the users’ representative (User SH). After all, they are the ones with knowledge about their needs. They can give valuable feedback during the development in order to make the best possible product.

Conclusion

Identifying key stakeholders in agile is crucial for inspection and adaptation of the product development.

The scrum master must know who the key stakeholders are in order to invite them to the sprint review. More about sprint review preparation here.

Who they are – as shown above, depends on what is the client and user relation to our software firm.

There is always someone who pays for the product and wants to collect a certain revenue. The investor needs to decide who will be the source of the requirements at the beginning and all the way through the development process.

Stakeholders must collaborate at sprint reviews and other workshops with the scrum team in order to produce the most value possible – that’s what agile and scrum are all about.