Stakeholders and choosing a Scrum Master

Most project trouble that looks like a technical problem started as a people problem: someone with an interest nobody asked about, or a facilitator who never had the time. Two small questions, asked early, prevent a good share of it. Who is this for, and who is going to help the team work well?

Who counts as a stakeholder

The Scrum Guide mentions stakeholders without defining them, which is fair. They are the people who have an interest in the product and can say something about it that the team does not already know. The Guide gives them three clear places in Scrum. They attend the Sprint Review, where the team presents its results and progress toward the Product Goal is discussed. They influence the Product Backlog, but only by convincing the Product Owner, who may represent the needs of many of them. And the Scrum Master facilitates stakeholder collaboration as requested or needed.

The SBOK® Guide gives the term more structure. It uses business stakeholders as a collective term for customers, users and sponsors who frequently interface with the core team and influence the project throughout. It is for them, it says, that the project produces its benefits. It also draws a wider circle: stakeholders in general are everyone affected by the project, inside or outside the organisation, including vendors and internal groups. In its Identify Scrum Master and Business Stakeholder(s) process, the business stakeholders are identified early, and their role in the project is settled.

A practical way to hold both: customers buy or choose the product, users use it, sponsors fund it and own the outcome, and a long tail of other groups, such as support staff or regulators, are affected by it. The same person can be more than one.

Why name them early

Naming stakeholders is not a bureaucratic step. It answers three questions the team will need answered:

1. Whose problems are we solving? The vision and the backlog need real people behind them.
2. Who can say yes or no? A request from someone with no authority over the outcome weighs differently from one from the sponsor.
3. Who should be at the Sprint Review? An empty review, or one full of the wrong people, produces no useful feedback.

A simple, common-practice aid is a two-way sort, which is ours and not either source's. List the people, then place each by how much they can affect the project and how much they care about it. Those with high influence and high interest need regular involvement. Those with high influence and low interest need keeping informed so they are not surprised. Those with low influence and high interest need a way to be heard, and the rest need little.

Keeping stakeholders useful

Stakeholders help most when they are close to the work and honest about what they want. The Agile Manifesto principle that business people and developers must work together daily throughout the project is the aspiration. The Sprint Review is the formal minimum.

Things that help:

• Give them a single route. Requests go to the Product Owner. The Guide says those who want to change the backlog do so by convincing the Product Owner, and a Product Owner who is bypassed cannot order anything.
• Show them working product, not reports. The Scrum Guide describes the review as a working session.
• Tell them what changed and why. When the order of the backlog moves, the Product Owner explains it. Surprises erode trust faster than disagreements.
• Say what they cannot have. A clear "not this release" is kinder than silence.

Choosing a Scrum Master

The Scrum Guide does not say how a Scrum Master is chosen. It says what they are accountable for: establishing Scrum and the team's effectiveness. How a person comes to hold that accountability is left to the organisation.

The SBOK says more. It treats the choice as an early process, normally the Product Owner's responsibility, often with help from HR, and names four selection criteria when there is flexibility.

• Problem-solving skills. The SBOK calls this one of the primary criteria, because the role involves removing impediments.
• Availability. The Scrum Master has to be present for the planning, Daily Scrum and Sprint meetings.
• Commitment. Enough to ensure the team has a good working environment.
• A supporting leadership style. Leadership that serves and does not direct.

It also advises confirming a candidate's availability and commitment before selection, and notes that in some projects the role is preassigned.

Read next to the Scrum Guide's description of the role, the four criteria are a reasonable shortlist, and a fifth belongs beside them: the ability to coach without taking over. A Scrum Master who solves every problem personally has missed the point. Our post on the Scrum Master role covers what the work looks like.

When people are far apart

The SBOK notes that, ideally, the Scrum Master, team members and business stakeholders are colocated so that they communicate frequently and easily. When they are not, it says additional resources may be needed to help communication, to understand cultural differences, to synchronise work and to share knowledge. That cost is real and often left out of plans.

For stakeholders, distance changes how involvement works. A Sprint Review on a video call needs a clearer agenda and more deliberate invitations to speak. Asynchronous updates, such as a short written note after each Sprint with a link to the working product, keep people in time zones that cannot attend informed. The Scrum Guide does not address distribution, but its principle of transparency is the same: the people who need to see the work should be able to, in a form they can use.

Common mistakes

• Making the Scrum Master a part-timer on several teams. The role needs time in every event and between them. A person split three ways has none of it.
• Choosing by seniority. A senior person who cannot let a team decide for itself is a poor fit, however capable.
• Treating the project manager as the Scrum Master by default. The skills overlap a little and the accountabilities do not. See Scrum Master vs project manager.
• Forgetting that stakeholders change. A new sponsor or a reorganisation changes who matters. Revisit the list when it does.
• Inviting everyone to everything. The Sprint Review needs the stakeholders who can decide something. A hall full of observers produces noise.
• Naming no one as the voice of a group. If "the customers" have no representative, the Product Owner ends up guessing.

How to practise it

In the simulator, the Scrum Master has been engaged from the start of the project, so the second step confirms the roles and the sign-off matrix with the Sponsor and the Product Owner, and you decide whether to confirm them or ask for changes.