Working with stakeholders and customers

Who represents stakeholders, and who may talk to them

Before anybody can be represented, something has to settle who counts. Scrum defines a product as a vehicle to deliver value with a clear boundary, known stakeholders and well-defined users or customers, and it can be a service or something more abstract as readily as a piece of software. The line is drawn around value and the people served, which is why a funding line does not draw it and neither does team count: several Scrum Teams may work on one product, sharing one Product Goal, one Product Backlog and one Product Owner. Two systems with separate customers and no common boundary cannot honestly be handed a single Product Goal, because the objective could then be neither fulfilled nor abandoned as one thing.

A product has more people with an interest in it than any team can serve one conversation at a time, so Scrum concentrates those interests into a single accountable view of value. The Scrum Guide says it plainly: "The Product Owner may represent the needs of many stakeholders in the Product Backlog." Representation is the mechanism, and the Product Backlog is where the representation is visible — many voices in, one ordering out, in an artefact everybody can inspect and argue with.

That is a statement about who decides, not about who is allowed to speak. Scrum makes the whole Scrum Team responsible for all product-related activities, and the first item on the list it gives is stakeholder collaboration. A team that refuses to talk to the people it builds for has cut itself off from the evidence its own empiricism runs on, and it has done so in the name of a rule Scrum never wrote.

So a stakeholder stopping a Developer in the corridor on day four is doing something ordinary. Two questions hide in the request and the exam wants them pulled apart. May we talk about it — always yes. Does it get built, and when — that is a change to what the product does, so it goes to the Product Owner and into the Product Backlog, and any renegotiation of this Sprint's scope happens with them.

The distractors here are the arrangements a sensible organisation actually builds. A standing call between one director and two Developers so she can stay close to the build is a second, invisible ordering of the work running alongside the real one. A Scrum Master who takes on stakeholder communication has put product decisions in the wrong accountability. A stakeholder representative appointed onto the team is a fourth accountability Scrum does not have, and it splits ownership of value across two people. And a Scrum Master who stops stakeholders approaching Developers has built precisely the barrier the role exists to remove.

The Sprint Review, and the event stakeholders do not attend

The Sprint Review is the event Scrum builds around stakeholders. The Scrum Team presents the results of its work to key stakeholders and progress toward the Product Goal is discussed; then the team and the stakeholders review what was accomplished and what has changed in their environment, and on that basis the attendees work out what to do next. The Product Backlog may be adjusted there and then to meet new opportunities. The whole Scrum Team presents, because the whole team is accountable for the Increment — not the Product Owner alone as spokesperson, not the Scrum Master narrating on the team's behalf, and not the Developers demonstrating and withdrawing before the part of the event that produces anything. A Scrum Master's accountability at any event is that it happens, stays positive and productive and holds its timebox, which is a different job from doing the talking.

It fails in two opposite directions and the exam scenarios use both. One is the broadcast: a clean walkthrough of every finished item with stakeholder questions held to the last ten minutes, which yields applause and an unchanged Product Backlog. The other is the gate: an acceptance sheet for attending stakeholders to sign. Scrum has no acceptance, sign-off or approval step anywhere in it, and it does not need one here — the Definition of Done already settled whether the work is finished, and a signature converts an inspection into permission. The Guide names the failure mode itself: "The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation." The test to carry into the exam room is whether anything about the plan could have moved. If not, it was not a Sprint Review.

Collaborating on what to do next is not the same as deciding it, and this is the strongest distractor on the whole lesson. A room of legitimate opinions — a stakeholder who wants an integration, Developers who price it at a week, a head of sales who says it goes to the top — produces input. Whether it enters the Product Backlog and where it sits is one accountability, exercised in the open at the Review rather than privately afterwards. The Developers who will be doing the work are the ones responsible for the sizing, so their week is the authoritative number and still not a decision: sizing is not ordering. Nor does seniority acquire the Product Backlog — Scrum's requirement runs the other way, obliging the organisation to respect the Product Owner's decisions.

The Sprint Retrospective is the other half of the answer, because it is where stakeholders do not go. It is the Scrum Team inspecting how the last Sprint went with regard to individuals, interactions, processes, tools and its Definition of Done — the team's inspection of itself, and candour is the first thing an audience costs. Transparency is about the artefacts being visible, not about every event being open, so a stakeholder with ideas about how the team could work faster is not owed a seat. Note two details the exam likes: the Product Owner has no gatekeeping role over attendance, and the one event Scrum names an invitation provision for is Sprint Planning, where the Scrum Team may invite other people to give advice. The Scrum Master stays in the Retrospective, being a member of the team and accountable for its effectiveness.

Two routes in, and the urgency that runs into the Sprint Goal

A stakeholder who wants something built has exactly two routes, and both end at the same person. He can try to convince the Product Owner, which is the mechanism Scrum names and a real one — a Product Owner who never reorders in the face of evidence is not doing the job either. Or he can make the case at the Sprint Review, with the Increment and the changed environment in front of everyone. Influence in Scrum is the strength of the argument, not seniority and not access to a friendly Developer.

Learn the illegitimate routes just as carefully, because they are what the scenarios describe. Asking the Developers to include it in the current Sprint has a true premise — the Developers do select the Sprint's items — and skips the decision, since they select from an ordered Product Backlog in conversation with the Product Owner. Raising it at the Retrospective is wrong twice over: that event changes how the team works rather than what the product does, and it is not a stakeholder forum. Escalating to a sponsor and pulling rank are the same wrong answer in different clothes.

Then there is the urgent case, day seven of a fortnight, a customer threatening to escalate unless a regulatory report ships this Sprint. Scope may be clarified and renegotiated with the Product Owner as more is learned — that is how a team responds to what it discovers — but during the Sprint no change is made that would endanger the Sprint Goal. That is the boundary the negotiation stops at, and the test is the Goal rather than the volume of work. Which is what makes the equal-size swap so convincing: exchanging one selected item for another is not forbidden in itself — the Developers adjust their selection all Sprint — but the items being dropped here are the ones carrying the Goal, so a trade that balances the load perfectly is still the change the rule refuses. If the report genuinely costs the Goal it belongs in the Product Backlog. There is one escape hatch: if the change has made the Sprint Goal obsolete rather than merely inconvenient, the Product Owner may cancel the Sprint, and nobody else may.

Underneath all of it sits a visibility obligation the exam asks about directly. Scrum tells the organisation to respect the Product Owner's decisions and then says where those decisions can be found — in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review. That pairing is the price of the authority. Scrum's artefacts are built to maximise transparency of key information precisely so that everyone inspecting them has the same basis for adaptation, and stakeholders are among those inspecting; a Product Backlog only the Developers can decode has failed at the job it exists for. Nor is this a complaint about workload — a Product Owner may do the backlog work himself or delegate it and remains accountable either way. What cannot be delegated is the visibility. A Product Owner who makes his calls in hallway conversations and leaves the backlog unordered for six weeks is asking to be trusted about decisions nobody can examine, and stakeholders respond exactly as you would expect, by going round him to the Developers. The fix is the artefact, not a weekly priority meeting to record the decisions somewhere else.

The Scrum Master's two stakeholder jobs, and what a stakeholder is owed

The Scrum Master serves three constituencies and stakeholders appear in two of the lists. To the organisation, one of the named services is removing barriers between stakeholders and Scrum Teams. Note which list Scrum files it under: not the services to the team, because the barrier is usually outside the team, built by people acting reasonably. A programme office that requires every question to be filed on a form it triages monthly is not a background constraint the team must live with — it is the impediment, and the Product Owner ordering a backlog from second-hand summaries is the damage. Coaching her to write better items from the summaries improves the quality of second-hand information. Taking over the form moves the gate rather than removing it, and makes the Scrum Master the new filter. Winning an exemption by escalation changes nothing anyone understands.

To the Product Owner, the named service is "Facilitating stakeholder collaboration as requested or needed." Both halves of that phrase are tested. As requested covers the Product Owner who asks for three departments to be got into one room and the session run; as needed means a Scrum Master may raise the idea when nobody has asked. The objection that a Scrum Master facilitates only the Scrum events mistakes a floor for a ceiling, and the neutrality argument — attend but do not facilitate — is invented. What the service never becomes is deciding the order or carrying messages between the parties. The Scrum Master builds the room; the Product Owner decides in it.

What a stakeholder is owed each Sprint starts with the Sprint Goal. The Product Owner proposes how the product could increase its value, and the whole Scrum Team then collaborates to define a Sprint Goal that, in the Guide's words, "communicates why the Sprint is valuable to stakeholders". The audience is named in the sentence, which is why a Goal that reads as a list of ticket numbers has failed at its job — a stakeholder who has never seen the Product Backlog should be able to read it and judge it. Note the two misreadings of the same sentence: stakeholders are who the Goal must make sense to, not who writes it, and the Goal is the single objective the selected items serve rather than the list of items itself, which is exactly why the selected items can be renegotiated with the Product Owner mid-Sprint without the Goal moving. The other half of what is owed is the loop closing: Scrum describes the Scrum Team and its stakeholders inspecting the results and adjusting for the next Sprint.

A demand for a mid-Sprint status meeting is nearly always a transparency failure wearing a calendar invitation. Scrum forbids no meetings — the Developers often meet during the day to re-plan, and the team talks to stakeholders whenever it is useful. What the events are there for is regularity, and the effect of running them properly is to minimise the need for meetings Scrum has not defined — a framework that banned such meetings would have had no reason to put it that way. Stakeholders who could see an ordered Product Backlog and a genuinely usable Increment rarely want a fortnightly progress call, and such a call inspects nothing and adapts nothing, so it can never stand in for the Sprint Review. Fix the artefact first.