Two words carry most of the practice. Communication is proactive, meaning it goes out on a rhythm rather than in answer to a question, and it runs from strategy through execution rather than covering delivery alone.
Neither is difficult. Both are skipped under pressure, and skipping them is what produces a stakeholder who has started asking for weekly detail.
Proactive means on a schedule
Communication that happens in response to a question has already failed twice. It reached only the person who asked, and it arrived after they had begun to worry.
A rhythm fixes both. A short written update on a fixed cadence, published whether or not there is news, means nobody has to ask and everybody gets the same version. It also removes the incentive to escalate, because escalation stops being the fastest route to information.
The discipline is to keep publishing when the news is dull. An update that appears only when something interesting happens becomes a signal in itself.
From strategy through execution
The span is deliberate. Stakeholders who only see execution updates get progress with no context and evaluate it against whatever they assume the goal is.
Three layers, on different cadences, cover it.
Why this direction. The market evidence and the decision it supports. Repeated periodically, because people forget and because new people arrive.
What is committed and when. The release plan, with what changed since last time.
What is in flight and what has landed. Short, specific, and including what was dropped and why.
Different stakeholders, different framing
A support director wants to know what will change in their queue and when to train for it. A sales lead wants to know what can be said to a customer today. An executive wants the outcome against the plan and the two risks that could change it. A development team wants the market context that explains why the order is what it is.
The facts underneath are the same. Sending everyone the same document means most of them have to extract their own answer, and most of them will not.
Development as a stakeholder audience
The people building the product are an audience for market knowledge rather than only a recipient of requirements. A team that knows who the user is and what the problem costs them will make better decisions in the hundred places nobody wrote a requirement for, and raising that knowledge does as much for a team as trust and safety do.
Where each syllabus puts it
Pragmatic Institute names this Stakeholder Communications and places it in the Planning category next to Requirements and Use Scenarios, as one of the three framework activities examined in the Build course.
Scrum has no equivalent activity, because the framework locates the work in an event. The Sprint Review is where the Scrum Team and stakeholders inspect the Increment together and decide what to do next, and the Product Owner is accountable for the stakeholder relationship around it. Everything above still applies, and in Scrum it is how a Product Owner keeps the Sprint Review useful rather than a separate practice bolted alongside it.
When something goes wrong
Early, specific and with options. What has changed, what it affects, what the choices are, and what you recommend. Stakeholders forgive slippage that arrives with a decision to make. They remember slippage that arrives as a completed fact.